Here is the solution to Packet Challenge #2 and how I created it.
I mentioned it last time and I’ll mention it again here, the problem with posting these challenges to Twitter is keeping them to 140 characters or less. It’d be nice if Twitter could increase the size of tweets a bit more. That way I could at least get some good TCP packets moving over this thing.
Anyways, since the size of tweets is such an issue. I decided to do the same thing a router has to do when it has a packet that’s too big to shove down the wire. I fragmented it. While I was cutting it in to little pieces, I also took the time to rearrange it a little.
I used the same tools as in the previous challenge (hping and tcpdump.) However, I needed the help of one more tool to perform the actual fragmentation. I chose a nifty little tool called Fragroute.
Fragroute was created by Dug Song (@dugsong on twitter.) It has the ability to take traffic destined for a particular host and do all sorts of things with it. It can delay, duplicate, drop, fragment, overlap, reorder, etc. It was created primarily to test network based intrusion detection systems, firewalls, and IP stack behavior.
Fragroute can be downloaded here.
To create the packet I did the following:
First, I created a text file with the payload. Then I ran hping as follows:
hping3 –icmp –file payload-2.txt –data 17 192.168.94.134 –c 1
Here is the output from hping:
HPING 192.168.94.134 (eth0 192.168.94.134): icmp mode set, 28 headers + 17 data bytes
[main] memlockall(): Success
Warning: can’t disable memory paging!
len=46 ip=192.168.94.134 ttl=128 id=6852 icmp_seq=0 rtt=1.0 ms
— 192.168.94.134 hping statistic —
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.0/1.0/1.0 ms
At the same time as I ran hping, in another window I ran fragroute to fragment and reorder the packet:
fragroute -f frag-3 192.168.94.1
Here is the output from fragroute:
fragroute: ip_frag -> order -> print
192.168.94.129 > 192.168.94.1: (frag 61058:8@16+)
192.168.94.129 > 192.168.94.1: icmp: type 8 code 0 (frag 61058:8@0+)
192.168.94.129 > 192.168.94.1: (frag 61058:1@24)
192.168.94.129 > 192.168.94.1: (frag 61058:8@8+)
What the fragroute command is basically saying is to modify traffic going to this destination. In this case, the destination is 192.168.94.1. The -f option allows for the specifying of rules. I chose to use one of the rule files that came with fragroute. It is located in the scripts directory.
Here is the frag-3 file:
ip_frag 8
order random
print
Note that hping created 1 packet. Now look at the output from fragroute. Fragroute took that packet and broke it up into four smaller pieces. Fragments!
Something else to note here is that the IP ID is different. In the packet created by hping the IP ID is 6852. In the output from fragroute the IP ID is 61058. This is because in order to perform this packet manipulation, fragroute actually had to rewrite the packet. The significance of the IP ID field will be discussed more later.
Here are the packets:
45 00 00 1c ee 82 20 02 40 01 2e 89 c0 a8 5e 81 c0 a8 5e 01 63 6b 65 74 73 2e 63 6f
45 00 00 1c ee 82 20 00 40 01 2e 8b c0 a8 5e 81 c0 a8 5e 01 08 00 f8 bb 3f 1f 00 00
45 00 00 15 ee 82 00 03 40 01 4e 8f c0 a8 5e 81 c0 a8 5e 01 6d
45 00 00 1c ee 82 20 01 40 01 2e 8a c0 a8 5e 81 c0 a8 5e 01 69 73 6d 65 6c 6c 70 61
This is the beginning of the IP Header portion of the packet. I removed the ethernet frame header to keep it small enough for Twitter. I also removed the | to make it easier to read here. Building upon the last packet challenge here is a quick dissect.
Starting with byte 0, we see that familiar 45. This is an IP Version 4 packet and the IP Header is 20 bytes in length. In the Protocol Field, found in byte 9, there is a 01, so this is an ICMP packet. In fact, all of them are ICMP packets.
The ICMP portion of the packet is highlighted below:
45 00 00 1c ee 82 20 02 40 01 2e 89 c0 a8 5e 81 c0 a8 5e 01 63 6b 65 74 73 2e 63 6f
That’s weird. That doesn’t look like an ICMP header. Normally one would expect to see the ICMP Type and Code here. Something like 00 00 for an a echo reply or an 08 00 for an Echo Request. Instead these bytes fall into the ASCII printable range. Converting the HEX to ASCII.
63 6b 65 74 73 2e 63 6f
c k e t s . c o
This appears to be part of a message, but it can’t be the whole message. Here is the ICMP portion of the next packet.
08 00 f8 bb 3f 1f 00 00
Ah, here is the ICMP Header. The 08 00 in the first couple bytes here in the ICMP header means this is an Echo Request. There is no payload though here to look at. Moving along to the next couple of packets. Again, focusing on the ICMP portion of the packet.
6d
m
69 73 6d 65 6c 6c 70 61
i s m e l l p a
There is the message, but how come it’s all messed up? Recall that Fragroute not only has the ability to fragment packets, but it also has the ability to reorder them. How does the system know how to put all of these back together? By using the IP ID field, the More Fragments Flag Field, and the Fragment Offset Field. Back to the packets:
45 00 00 1c ee 82 20 02 40 01 2e 89 c0 a8 5e 81 c0 a8 5e 01 63 6b 65 74 73 2e 63 6f
45 00 00 1c ee 82 20 00 40 01 2e 8b c0 a8 5e 81 c0 a8 5e 01 08 00 f8 bb 3f 1f 00 00
45 00 00 15 ee 82 00 03 40 01 4e 8f c0 a8 5e 81 c0 a8 5e 01 6d
45 00 00 1c ee 82 20 01 40 01 2e 8a c0 a8 5e 81 c0 a8 5e 01 69 73 6d 65 6c 6c 70 61
The IP ID is found in bytes 4 and 5 of the IP Header. It is highlighted in each packet below:
45 00 00 1c ee 82 20 02 40 01 2e 89 c0 a8 5e 81 c0 a8 5e 01 63 6b 65 74 73 2e 63 6f
45 00 00 1c ee 82 20 00 40 01 2e 8b c0 a8 5e 81 c0 a8 5e 01 08 00 f8 bb 3f 1f 00 00
45 00 00 15 ee 82 00 03 40 01 4e 8f c0 a8 5e 81 c0 a8 5e 01 6d
45 00 00 1c ee 82 20 01 40 01 2e 8a c0 a8 5e 81 c0 a8 5e 01 69 73 6d 65 6c 6c 70 61
The ee 82 in decimal equals 61058. That is the IP ID of the fragmented packet created by Fragroute. Every packet has an unique IP ID. If a packet is fragmented while on the way to its destination, each of the fragments will contain that same IP ID. This ensures that receiving host knows that all of these particular fragments go together to form a particular packet.
How does one know though that a packet is fragmented then in the first place? What about the order of the fragments? That is the purpose of the next couple of fields, the More Fragments Flags field and the Fragment Offset Field. They are located in bytes 6 and 7 of the IP Header and are highlighted below:
45 00 00 1c ee 82 20 02 40 01 2e 89 c0 a8 5e 81 c0 a8 5e 01 63 6b 65 74 73 2e 63 6f
45 00 00 1c ee 82 20 00 40 01 2e 8b c0 a8 5e 81 c0 a8 5e 01 08 00 f8 bb 3f 1f 00 00
45 00 00 15 ee 82 00 03 40 01 4e 8f c0 a8 5e 81 c0 a8 5e 01 6d
45 00 00 1c ee 82 20 01 40 01 2e 8a c0 a8 5e 81 c0 a8 5e 01 69 73 6d 65 6c 6c 70 61
Here are these two fields converted to binary for each fragment:
00100000 00000010
00100000 00000000
00000000 00000011
00100000 00000001
The More Fragments Flag Field is represented by a single bit. It’s the 3rd bit in located in byte 6 and is highlighted here:
00100000 00000010
00100000 00000000
00000000 00000011
00100000 00000001
The 1 here means that more fragments follow. Everything to the right of the More Fragments Flag Field is the Fragment Offset. The Fragment Offset Field tells the destination where these particular bytes fall in the original packet. The Fragment Offset Field is a multiple of 8. Here it is highlighted, converted to decimal, and multiplied by 8:
00100000 00000010 = 2 * 8 = 16
00100000 00000000 = 0 * 8 = 0
00000000 00000011 = 3 * 8 = 24
00100000 00000001 = 1 * 8 = 8
The second fragment is first, occurring at offset 0. The last fragment actually occurs next at offset 8, followed by the first fragment at offset 16, and then finally the third fragment at offset 24. Also, notice that the third and final fragment doesn’t have the More Fragment flag set.
All of this visible in the output from Fragroute.
fragroute: ip_frag -> order -> print
192.168.94.129 > 192.168.94.1: (frag 61058:8@16+)
192.168.94.129 > 192.168.94.1: icmp: type 8 code 0 (frag 61058:8@0+)
192.168.94.129 > 192.168.94.1: (frag 61058:1@24)
192.168.94.129 > 192.168.94.1: (frag 61058:8@8+)
The + sign represents the More Fragments Flag.
Putting all the fragments in the correct order now reveals the following:
ismellpackets.com
One other item of note here; only the first fragment will carry the embedded protocol header information. In this case the second fragment, which was actually the first fragment was the only part of the fragment that contained the ICMP Header. If one stops and thinks about this for a moment, it makes sense. No really, it does.
Congratulations to @leonward for being the first to figure it out. Thanks everyone else for playing and following along.
If anyone has any questions, comments, or ideas for challenges, feel free to contact me.
2 Comments so far
Leave a comment
I Smell Packets 
Maybe you could post the challenge, and tweet the announcement.
Regards,
Comment by vmforno May 15, 2009 @ 6:58 pmI’m considering it. I wonder if enough people would visit to the site though.
Comment by ismellpackets May 15, 2009 @ 8:38 pm