Subversive Technologies & Countermeasures
Packet crafting in it's simplest form is the art of stringing bits together to form a cohesive stream that together represent a packet. The order and structure of this stream is known as the protocol or language of the packet, and is required for communicating devices to be able to properly process and interpret this information. This processing and interpretation of the packet by a device is commonly referred to as traversing the stack and is a choke point where inconsistencies and poor implementations may be exploited. Although crafting packets to exploit a devices stack is feasible with the information provided here, it is beyond the scope of this article and will not be covered explicitly.
In order for a packet to reach it's destination it must have some sort of transmission medium for delivery. In this article the very popular Ethernet will be used for the examples due to the heavy market penetration of the physical medium and the wealth of knowledge available on it's operation. The protocols discussed in the examples will of course be Ethernet or 802.3, and the TCP/IP suite, also known as the language of the Internet.
[edit] Examples packets
Transferring information across a physical medium involves a conglomerate of hardware and software technologies that are beyond the scope of this article, however some basic network concepts should be reiterated to help supplement the information conveyed in the examples.
Each example packet provides a colorized hexadecimal byte stream detailing how the information is structured by the encapsulated protocols. All of these colored fields in the stream are linked to their corresponding header diagrams with a brief description of their value and relationship to the other fields in that header. Some relationships may extend across one or more encapsulated headers and will be noted in the field description that altering this data will require multiple field changes.
These examples only provide a limited amount of protocol and interaction information relevant to the scope of the packet. RFC papers are the purposed standards documents that should provide a more robust and detailed explanation of the protocol if one is not found in an example.
[edit] EthernetII IPv4 ICMP Echo Request
In this example an EthernetII frame is used to encapsulate the TCP/IP protocol suite and more specifically an ICMPv4 Echo request packet. A complete byte stream is provided with a brief discussion of some of the more relevant fields that should be altered in each of the encapsulated headers in order to create your own ICMP packet.
EthernetII IPv4 ICMP Echo Request packet byte stream
| EthernetII frame
|
| Preamble
7 bytes
| SFD
1 byte
| Destination Address
6 bytes
| Source Address
6 bytes
| Ether Type
2 bytes
|
| Frame Check Sequence
4 bytes
|
|
A bit stream theoretically should have evenly spaced time intervals between each bit. But in reality no two clocks are perfectly synced and imperfections in the physical transfer medium are some of the contributing factors to inconsistent bit rates. Enter the preamble, EthernetII frames use this field to synchronize node communication on a network and aid in tolerating these rate inconsistencies by giving the device time to detect the presence of a signal. The preamble for an EthernetII frame consist of 56 bits of alternating 1's and 0's and is not processed in the same manner as the rest of the EthernetII frame, therefore is not considered when calculating frame size, or Frame Sequence Check. Since the preamble is not processed in the same manner as the rest of the bit stream it will not be visible to packet capture tools, or modified by packet generators.
| 10101010101010101010101010101010101010101010101010101010
|
This field is ignored when crafting packets.
Start Frame Delimiter is an 8 bit field defined as 10101011 with the trailing two bits always set to 11 indicates the start of frame. The IEEE 802.3 redefinition of the EthernetII frame spilt the original preamble field from a single 64 bit field into a 56 bit preamble and 8 bit Start Frame Delimiter. The original trailing 8 bits of the preamble are now classified as the Start Frame Delimiter field.
This field is ignored when crafting packets.
Network devices have 48 bit (6 byte) identifiers known as a Media Access Control (MAC) address. This address is a unique identifier given by the manufacture of the device with the first 24 bits (3 bytes) of the MAC address identifying the manufacture. The remaining 24 bits (3 bytes) are assigned by the manufacture as the unique identifier according to their own internal numbering system. An EthernetII frame uses the Destination Address, and Source Address fields to route the frame at a hardware level or data link layer under the OSI model.
Altering the Destination Address or Source Address fields requires no extra calculations and can be done independently of each other since the Frame Sequence Check will more than likely be calculated for us by the packet injector. Under most circumstances in order for this packet to be routed properly the Destination Address must be altered to match the target device, and the Source Address altered to match the receiving network device. Depending on how many metrics are traversed, type of routing devices, device configuration, and topology of the network incorrect MAC address might be tolerated and the echo reply routed according to the Source Address contained in the Internet Protocol header.
| 01 02 03 04 05 06
| 06 05 04 03 02 01
|
Since this example is an ICMPv4 Echo Request packet the Ether Type must be set to 0800 in order to maintain processing continuity of the encapsulated headers.
IANA maintains a current list of accepted Ether Types.
The Data field of the EthernetII frame will contain any and all encapsulated protocol information and frame padding if necessary.
The Ether Type field in the EthernetII frame was set to 0800 and any device processing this packet will start interpreting the data beginning on the 15th byte in the bit stream as an Internet Protocol version 4 header. The device if properly designed should do some basic sanity checks to verify the header conforms to Internet Protocol standards, as well as situations that fall outside accepted norms.
The Internet Protocol header is more fragile then the EthernetII frame in that altering fields in the header or it's encapsulated data will require recalculations of one or more fields in order to maintain its integrity.
|
|
| 1 |
2 |
3 |
4 |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 |
08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Version |
IHL |
Type of Service |
Total Length |
| Identification |
Flags |
Fragment Offset |
| Time to Live |
Protocol |
Header Checksum |
| Source Address |
| Destination Address |
Options |
Padding |
|
Version and the IHL field are two separate 4 bit identifiers packed into a single byte. The first 4 bits identify the version of this packet as an IPv4 header while the trailing 4 bits are the length of the entire IPv4 header. Altering the Version bits would invalidate the current IPv4 header, all it's encapsulated data, and the EthernetII frame Ether Type field that was set to 0800 signaling devices to process an IPv4 header. The IHL quantifies the size of the IPv4 Header on 4 byte boundries with a minimum length of 20 bytes or maximum length of 60 bytes depending on Option count, type, and or Padding. Since there are no Options in this example altering the IHL would invalidate this packet by changing the start position of the encapsulated ICMPv4 header.
Type of Service is a per bit segmented field used to signal routing device of how this packet should be handled. Altering this field will more then likely have little impact on performance since it is largely ignored by most routing devices. ECN RFC-3168
The Total Length field is the length of the Data measured in bytes that includes the IPv4 header and any other encapsulated data up to a maximum 65,535 bytes. Addition or removal of data in the IPv4 header or any of the encapsulated protocols will require the Total Length field to be altered accordingly in order to maintain the packets integrity.
Typically the Identification field is used to identify one fragmented datagram from another. Even if the packet is initially sent unfragmented the field is given a value under the assumption that a routing device on the traversed network might need to fragment the packet in order for it to reach it's destination.
In this example this packet is not initially fragmented so the 3 bit Flags and 13 bit Fragment Offset fields must be set to 00 00 to maintain the packets integrity.
The Time To Live field will be generated by the device that initially created the packet and will sometimes be altered by a routing device dependant on it's configuration. This field may be altered in this example as long as it maintains a value sufficient to reach it's destination.
The Protocol field set to 01 signals an encapsulated ICMPv4 header will follow immediately after the end of the IPv4 header, altering this field will invalidate the encapsulated headers.
Recalculation of the Header Checksum will be necessary if any fields in the IPv4 header are altered.
Two fields that should be altered in this header from the example are the
Source Address and
Destination Address to ensure proper routing. These fields are the logical (IP) address of the target and sending devices that are mapped to the physical hardware address for transmission.
There are no Options and or Padding in this example Internet Protocol version 4 header.
|
|
| 1 |
2 |
3 |
4 |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 |
08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Type |
Code |
Header Checksum |
|
The Type field will specify the format of the ICMP message encapsulated within the IMCPv4 header. Altering this field will no longer make this a valid ICMPv4 Echo Request packet.
To further qualify the ICMPv4 message a Code field may be utilized. Depending on the network device and it's configuration if this field is not required it's value might be ignored and the packet processed or the packet could be considered malformed and dropped entirely.
Altering any of the ICMPv4 Header fields or any of it's encapsulated data will require the recalculation of the Header Checksum in order to maintain packet integrity.
The Type field set to 08 signals an encapsulated ICMPv4 echo request header will follow immediately after the end of the ICMP version 4 header.
|
|
| 1 |
2 |
3 |
4 |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Identifier |
Sequence Number |
| Data |
|
The Identifier and Sequence Number are typically used to match echo request with their respective echo reply packet. Either of these fields in the example can be set to any random value including 0 but will require a recalculation of the Header Checksum in ICMPv4 header.
The Data field in a ICMPv4 Echo request header is not required and will vary depending on the program or device used to created the packet, and in some circumstances the operating system. Since the ICMPv4 header contains a Header Checksum any changes to the Data field will require a recalculation of the Checksum.
Addition or removal of bytes in the Data field will require the Total Length and Header Checksum fields in the IPv4 header to be altered accordingly. Removing or adding information from the data field without altering the Total Length and Header Checksum fields may or may not be interpreted as a malformed packet by the processing device.
In this example the packet was created by the Windows ping utility which filled the Data field.
| 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
|
|
Depending on the API's you are using to craft the packet the Frame Sequence Check field may or may not be calculated for you.
End of Packet
[edit] EthernetII ARP Reply
In this example an EthernetII frame is used to encapsulate an ARP reply packet. A complete byte stream is provided with a brief discussion of some of the more relevant fields that may be altered in the header in order to create your own ARP reply packet.
EthernetII ARP Reply packet byte stream
| EthernetII frame
|
| Preamble
7 bytes
| SFD
1 byte
| Destination Address
6 bytes
| Source Address
6 bytes
| Ether Type
2 bytes
|
| Frame Check Sequence
4 bytes
|
|
The Preamble, Start Frame Delimiter, Destination Address, and Source Address have been previously discussed in the EthernetII IPv4 ICMP Echo Request example.
| 01 02 03 04 05 06
| 06 05 04 03 02 01
|
Since this example is an ARP Reply packet the Ether Type must be set to 0806 in order to maintain processing continuity of the encapsulated headers.
IANA maintains a current list of accepted Ether Types.
The Data field of the EthernetII frame will contain any and all encapsulated protocol information and frame padding if necessary.
With the Ether Type field in the EthernetII frame set to 0806 any device processing this packet will start interpreting the Data beginning on the 15th byte in the bit stream as an ARP reply header. The device if properly designed should do some basic sanity checks to verify the header conforms to ARP Protocol standards, as well as situations that fall outside accepted norms.
|
|
| 1 |
2 |
3 |
4 |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 |
08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Hardware Type |
Protocol Type |
| Hardware Address Length |
Protocol Address Length |
Opcode |
| Source Hardware Address |
| Source Protocol Address |
| Destination Hardware Address |
| Destination Protocol Address |
|
An ARP reply header does not contain a checksum field therefore allowing any field to be independently altered without requiring a checksum recalculation.
The Harware Type field is a transmission medium identifier set to 0001 since our example is using Ethernet.
The Protocol Type must be set to 0800 for IPv4 for this example and should not be altered in order to maintain packet integrity.
Since we are using EthernetII frames the Hardware Address Length field defines the size in bytes equal to the Source/Destination Address (MAC) fields which are 6 byte addresses.
The Protocol Address Length field must equal 4 bytes in order to accommodate the IPv4 Source Address and Destination Address type fields that will populate the Source Protocol Address and Destination Protocol Address fields
The Opcode field defines type of ARP packet. Altering this field will invalidate this example.
The Source Hardware Address can be any Source Address type address.
The Source Protocol Address can be any IPv4 Source Address type address.
The Destination Hardware Address can be any Destination Address type address.
The Destination Protocol Address can be any IPv4 Destination Address type address.
For an EthernetII frame to be properly formatted it's Data field must contain a minimum amount of data equal to or greater than 46 bytes. In situations where the encapsulated protocol does not contain the minimum 46 bytes of data a Padding field equal the amount of data required to meet the 46 byte requirement is appended. The contents of this Padding should be set to 00 but is often filled with semi-random information stored in memory by the device or Operating System that could create a serious security risk.
| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
Depending on the API's you are using to craft the packet the Frame Sequence Check field may or may not be calculated for you.
End of Packet
[edit] Reproducing example packets
These examples can be reproduced on your network with the use of the npg utility by simply cutting the text below and pasting it on a command line. It is recommended you also use a capture utility such as Wireshark to view the packet interaction on your own network.
Since npg makes no assumptions on which headers and payloads are encapsulated in a packet bit stream it is unable to recalculate checksums, or other dependant fields automatically. A simple way to recalculate any relevant fields is to inject your modified packet onto the network and use Wireshark to recalculate the correct values and then modify your packet accordingly.
EthernetII IPv4 ICMP Echo Request Byte Stream
npg -vv -p 01020304050606050403020108004500003c00a500008001b8c8c0a80002c0a8000108004a5c020001006162636465666768696a6b6c6d6e6f7071727374757677616263646566676869
EthernetII ARP Reply Packet Byte Stream
npg -vv -p 01020304050606050403020108060001080006040002060504030201c0a80002010203040506c0a80001000000000000000000000000000000000000
- The above examples require the Network Packet Generator npg.
[edit] Appendix
