The Internet is based on packets:nodes on the Internet exchange packets in order to communicate. At the most primitive level, packets are just well-defined pulses travel- ing across a copper wire. With this in mind, it’s possible to manipulate packets as they’re exchanged or to craft custom packets. There are many reasons for working at this level; e.g., identifying operating systems and other software on the network, attacking other systems on the network (or verifying that their network stack is implemented correctly, which is often the same thing), or mapping out the structure of a network. This chapter introduces some tools that you can use to work with packets at this low level.
There are two basic groups of tools that an individual can use to generate custom packets on a computer network. The first group forces you to use the techniques hardcoded within the tools, which usually require less intimate knowledge of the technology and allow someone to start leveraging custom packets almost immedi- ately. However, with this group of tools, the user is confined to the techniques included with the tool and cannot tweak, modify, or add to this pool of included techniques. The second group of tools allows you to create your own techniques and add them to your toolbox. This group offers limitless flexibility and functionality, but requires more work on the part of the user. In this chapter, we will explore some tools from both groups, but concentrate primarily on the set of tools that offer the user more flexibility and the ability to build custom techniques for generating cus- tom packets.
6.1
Why Create Custom Packets?
Apacketis a unit of very ordered information that is grouped in a specific structure. In many ways, it shares attributes with a package from one of the more expensive “efficient” mail couriers such as Fed Ex. A package from one of these couriers con- tains information such as the location of origin, the time of pick up, the route way- points, the priority of the package, the package’s destination, the package’s weight,
and of course the package’s content that is intended to be delivered to the recipient. On the wire, regardless of what protocol it is, a packet contains the metadata neces- sary to transmit the packet correctly and the payload of the packet (i.e., the data that is to be delivered). All of this information is parsed and processed through auto- matic functions that adhere strictly to the published and established rules of the given protocol specifications. This is where part of the power of custom packet gen- eration can be realized:it does not matter where the packets originate from or how they were created; if the packets are on the wire and adhere to the specification, a machine will process the packets if it receives something it is expecting.
There are several reasons why someone would want to generate custom packets. One is to communicate with black box applications or devices. For example, on a net- work, there might be a proprietary application or device that communicates through a proprietary protocol. This device needs to be integrated into the regular network health check, and the company does not want to pay the money to purchase the pro- prietary network protocol libraries that are needed to get a meaningful reply out of it. Knowing how to create custom packets to establish a connection and communicate with this device is imperative. Another reason is to test the robustness of a devel- oped application. Rather than creating a full client to run unit tests against the appli- cation, generating raw packets on the wire that follow the protocol of the application may be perfectly acceptable and more efficient. People who are fond of fuzzing and penetration testers also recognize this feature, except they systematically alter cer- tain areas of a packet according to their desired rules. Because the packets are parsed and processed by computers, subtle differences in a packet (especially if it is not fully protocol-compliant) have brought attention to numerous network and security issues in the past.
A classic example of a custom packet that is very simple to demonstrate and under- stand is the infamous Ping of Death. The termPing of Deathrefers to the most popu- lar, and simplest, form of this celebrated Denial of Service attack, where the attacker uses an especially large custom packet transmitted through the Internet Control Management Protocol (ICMP) type 8 (RFC 792), otherwise known asecho requestor
ping. In this instance, the size of the crafted packet has to be larger than 65,535 bytes in length, and thus will cause the affected computer to crash instantly; one packet, one kill. Network protocols have to adhere to strict rules in order to function, and 65,535 bytes is the absolute maximum that a packet can be, as defined by the Inter- net Protocol RFC 791. If the maximum size is specified as 65,535, then how can an ICMP packet be sent that is larger than that? RFC 791 also specifies that a single packet can be broken into smaller packets, sent across the wire, and reassembled by the receiving operating system. This is called packet fragmentation, and the individ- ual fragmented packets also contain information that tells the receiving host how to order the information to assemble the packet, and then process the information. The underlying issue with the Ping of Death is not that an illegally sized packet is
receiving operating system puts the information back together again and tries to pro- cess the large packet. The developers who implemented the process of receiving the fragmented packets and assembling the larger original packet never accounted for the possibility that the resulting assembled packet could be larger than the legal packet size. Not accounting for this, and pushing the assembled packet into a finite sized buffer, resulted in a buffer overflow on the receiving operating system. The really interesting part of this ordeal is that in 1996, this issue affected Linux, BSD, MS Windows, Mac OS, routers, and other network-enabled devices. The operating systems have been fixed now, but this problem is a great example of how a crafted packet can exploit a situation that a developer, and a highly reviewed protocol speci- fication, did not specifically account for.