Filed under: hping, nping, spoof, tcpdump | Tags: hping, nping, Packet Challenge, spoof
This is a follow up to the “Ping me!” packet challenge. In the previous post I asked how you could spoof MAC addresses using Nping and Hping. Here is the answer:
Using Nping
# nping –icmp -c 1 –icmp-type 0 –dest-ip 192.168.200.128 –source-ip 192.168.200.129 –icmp-id 0 –icmp-seq 555 –data-string ‘Ping me!’ –source-mac 00:0c:29:48:55:1f –dest-mac 00:0c:29:a6:5e:2f
Starting Nping 0.5.35DC1 ( http://nmap.org/nping ) at 2011-01-02 09:34 PSTSENT (0.0000s) ICMP 192.168.200.129 > 192.168.200.128 Echo reply (type=0/code=0) ttl=64 id=17243 iplen=36
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (50B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Tx time: 0.00083s | Tx bytes/s: 59952.04 | Tx pkts/s: 1199.04
Rx time: 0.99989s | Rx bytes/s: 0.00 | Rx pkts/s: 0.00
Nping done: 1 IP address pinged in 1.00 seconds
The following is the output from tcpdump:
# tcpdump -i en1 -e host 192.168.200.128
tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes21:31:24.609114 00:0c:29:48:55:1f (oui Unknown) > 00:0c:29:a6:5e:2f (oui Unknown), ethertype IPv4 (0x0800), length 50: 192.168.200.129 > 192.168.200.128: ICMP echo reply, id 0, seq 555, length 16
Using Hping
Hping doesn’t have the ability to spoof MAC addresses, but that still doesn’t prevent us from working around it.
The MAC address of most *nix machines can be changed by doing something close to the following:
# ifconfig en1 ether 00:0c:29:48:55:1f
For instructions on how to change MAC addresses on other OSs see the following link:
Changing Your MAC Address In Window XP/Vista, Linux And Mac OS X (Sometimes known as MAC spoofing)
That takes care of the source MAC address, but what about the destination MAC address? This can be spoofed by creating a static ARP entry:
arp -S 192.168.200.128 00:0c:29:a6:5e:2f
Now just run hping as demonstrated in the previous post.
Filed under: hping, Packet Challenge | Tags: hping, Packet Challenge, spoof
As promised here’s the solution to the “Ping me!” packet challenge using hping. The first example shows how to craft the reply using just the built-in command line options. As you will see, hping does have some limitations. The second example shows a way to overcome these limitations and craft a better reply.
Example #1 — Crafting a reply using Hping
# hping3 192.168.200.128 -a 192.168.200.129 -c 1 -1 -C 0 -e “Ping me”!
HPING 192.168.200.128 (en1 192.168.200.128): icmp mode set, 28 headers + 8 data bytes
[main] memlockall(): Resource busy
Warning: can’t disable memory paging!
— 192.168.200.128 hping statistic —
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Here is a break down of the command:
- 192.168.200.128 is the destination IP address.
- ‘-a 192.168.200.129’ spoofs the source IP address.
- ‘-c 1’ sends one packet.
- ‘-1’ specifies ICMP.
- ‘-C 0’ specifies ICMP Code 0 aka a echo reply.
The following is the output from tcpdump:
11:40:26.480933 IP 192.168.200.129 > 192.168.200.128: ICMP echo reply, id 6699, seq 0, length 16
- 192.168.200.128 is the destination IP address.
- ‘-a 192.168.200.129’ spoofs the source IP address.
- ‘-c 1’ sends one packet.
- ‘-0’ specifies Raw IP mode.
- ‘-H 1’ set the protocol to ICMP when in Raw mode.
- ‘-E payload.bin’ is the payload.
- ‘-d 16’ is the length of the payload in bytes.
Here is a screenshot of payload.bin
The following is the output from tcpdump:
13:08:58.353552 IP 192.168.200.128 > 192.168.200.129: ICMP echo reply, id 0, seq 555, length 16
With scapy we were able to spoof the source MAC address. Bonus points to anyone who can tell me how we could do the same thing here?
References:
http://www.hping.org/manpage.html
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.
Filed under: hping, Intrusion Detection In-Depth, Packet Challenge, SANS, tcpdump
Earlier today I tweeted an easy little packet challenge. The challenge for me was keeping that packet to less than 140 characters. Here is a short description of how I created the challenge:
First, I created the payload for the packet. I did this by placing some text in a file using the following command:
echo 1st2DMmegetsAStarbuckscard > payload.txt
Next, I used a tool called Hping to craft the packet:
hping3 –icmp –file payload.txt –data 26 127.0.0.1
In the above command, the –icmp instructs hping to create an ICMP packet. The –file option specifies a file to be used as the payload. Next, the –data option tells hping how many bytes of data in the payload. In this case, it’s 26 bytes data. Finally there is the destination IP address which is 127.0.0.1.
To capture the packet, I ran a sniffer called tcpdump:
tcpdump -i lo0 -X -s0
Here is packet in HEX:
4500 0036 308b 0000 4001 0000 7f00 0001 7f00 0001 0800 89f3 5a27 0200 3173 7432 444d 6d65 6765 7473 4153 7461 7262 7563 6b73 6361 7264
Decoding the Packet
Here is quick run though of how to decode the packet. First of all, when decoding packets it’s often helpful to have a reference. Here is a link to the SANS website where you can download the TCP/IP Pocket Reference from. I call this the cheat sheet.
There are also a couple of other points to remember:
1. Every two HEX characters equals one byte.
2. Start counting with 0.
Starting with byte 0, there is 45. Highlighted below:
4500 0036 308b 0000 4001 0000 7f00 0001 7f00 0001 0800 89f3 5a27 0200 3173 7432 444d 6d65 6765 7473 4153 7461 7262 7563 6b73 6361 7264
Find the IP header section on the cheat sheet. Notice that in byte 0 we find the IP Version Number and the IP Header Length fields. The 4 in the IP Version Number field means is an IP Version 4 packet. The next field, the IP Header Length, there is a 5. This represents 32-bit words. So, in order to calculate the IP Header Length we need to multiply this field by 4. 5*4=20. Therefore, the IP Header length is 20 bytes.
Next count 20 bytes. Remember, every two HEX characters equals one byte and start counting at 0.
4500 0036 308b 0000 4001 0000 7f00 0001 7f00 0001 0800 89f3 5a27 0200 3173 7432 444d 6d65 6765 7473 4153 7461 7262 7563 6b73 6361 7264
The portion highlighted above is the IP Header. What comes next? To find out look at the Protocol Field of the IP Header. According to the cheat sheet the Protocol Field is found in byte 9 of the IP Header. Looking back at the packet, there is a 01 in there:
4500 0036 308b 0000 4001 0000 7f00 0001 7f00 0001 0800 89f3 5a27 0200 3173 7432 444d 6d65 6765 7473 4153 7461 7262 7563 6b73 6361 7264
Referring back to the cheat sheet, a 1 in the Protocol Field of the IP Header means that the next protocol is going to be ICMP. Remember that when I created this packet I specified ICMP, so this is what one would expect here. Now the ICMP part of the packet. The IP Header Length was 20 bytes, after that begins the ICMP protocol portion. This is highlighted below:
4500 0036 308b 0000 4001 0000 7f00 0001 7f00 0001 0800 89f3 5a27 0200 3173 7432 444d 6d65 6765 7473 4153 7461 7262 7563 6b73 6361 7264
To decode this portion of the packet look at the ICMP Header section of the cheat sheet. The first couple of bytes of the ICMP Header are the Type and Code fields. There is a 0800 in those fields, meaning, referring back to the cheat sheet that this is an ICMP Echo or a PING.
Since it’s a PING, drop down to the Ping section of the cheat sheet and locate the Data section of the ICMP Echo. This Data should contain the text in the payload.txt file. Here is the Data section highlighted:
4500 0036 308b 0000 4001 0000 7f00 0001 7f00 0001 0800 89f3 5a27 0200 3173 7432 444d 6d65 6765 7473 4153 7461 7262 7563 6b73 6361 7264
These bytes fall into the ASCII printable range, so convent it to ASCII.
31 73 74 32 44 4d 6d 65 67 65 74 73 41 53 74 61 72 62 75 63 6b 73 63 61 72 64
1 s t 2 D M m e g e t s A S t a r b u c k s c a r d
This is just a brief explanation. It may seem like a lot of work, but it’s really not that difficult. Like most other things it takes a little practice. Some people can even do this in their sleep, I assure you I’m not one of those people.
Another thing that someone could have done was just to look for that HEX that falls into the ASCII printable range. They would’ve immediately focused in on the payload. Maybe I’ll use some double XOR encryption next time to make it harder. 😉
One of my favorite courses is the SANS Security 503: Intrusion Detection In-Depth course. In that course you get to spend 6 days learning all about TCP/IP and performing traffic analysis. There are a ton of hands-on exercises. And unlike other courses that may teach networking and TCP/IP, in this course you get to learn this stuff from an attackers perspective.
Congratulations to @quine for being the first to send me a message and winning the Starbucks Card. It’s on the way.
I Smell Packets 