I Smell Packets


Another “Ping me!” Packet Challenge Solution
October 6, 2010, 3:35 am
Filed under: nping, Packet Challenge | Tags: , ,

Jon Wohlberg (@jonw18 on Twitter) sent in a solution to the “Ping me!” packet challenge using nping:

Jon writes:

After opening the packet in tcpdump and wireshark, I immediately noticed that this was an icmp packet. Specifically, it is an icmp echo request or as it is better known as a ping request. According to the instructions we had to craft a packet that would reply to this packet.

Therefore, we need to craft an ICMP echo reply.

In order to craft a packet I could have choosen numerous programs including scapy, hping, and nemesis. However, for this task I choose nping, a packet crafter from the creators of nmap.

First we need to obtain all pertinent information from the packet provided.
1. Source IP (one initiating the echo request) –> 192.168.200.128
2. Destination IP (one receiving the request)  –> 192.168.200.129
3. ICMP Type and Code (Stating that this is an echo request)
TYPE =  8
CODE = 0
4. ICMP Identifier –> 0
5. ICMP Sequence number –> 555
6. ICMP Data –> Ping me!

Now that we have all of the important information, we can craft a packet (an ICMP echo reply) to reply to this request. We will be replying with the following information:
1. Source IP (this is the machine responding) –> 192.168.200.129
2. Destination IP (One who originally initiated the request) –> 192.168.200.128
3. ICMP Type and Code (Stating that this is an echo reply)
TYPE =  0
CODE = 0

Per the ICMP rfc (RFC 792), it states that “The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests.” “The echoer returns these same values in the echo reply.”

Meaning the ICMP identifier and sequence number need to be the same.
4. ICMP Identifier –> 0
5. ICMP Sequence number –> 555

The rfc also states “The data received in the echo message must be returned in the echo reply message.”

Translations, the data sent in the echo request must be sent back in the echo reply.
6. ICMP Data –> Ping me!

Now that we have our echo reply values we can craft our packet with nping. The command I used is:

nping –icmp -c 1 –icmp-type 0 –icmp-code 0 –source-ip 192.168.200.129 –dest-ip 192.168.200.128 –icmp-id 555 –icmp-seq 0 –data-string ‘Ping me!’

This command and be broken down as follows:
1. nping –> name of the program
2. –icmp –> tells nping to use the ICMP protocol
3. -c 1 –> tells nping to send only one paket
4. –icmp-type 0 and –icmp-code 0 –> indicates an echo reply
5. –source-ip 192.168.200.129 –> states that this will be the
address replying to echo request. Where the reply originates from.
6. –dest-ip 192.168.200.128 –> where we are sending the reply. This
is the machine that initiated the conversation.
7. –icmp-id 555 –> we need to include the icmp identifier from the
echo request.
8. –icmp-seq 0–> the icmp sequence number from echo request
9. –data-string ‘Ping me!’ –> the data from the echo request that
must be included.

Once we crafted our packet we need to capture the results. This can be done with tcpdump. The command I used was:

tcpdump -vnnX -i eth0 -w 13_answer.pcap icmp

This tell tcpdump to listen in verbose mode, disable name and port resolution, print hex, use interface eth0, write the results to a file and filter on icmp traffic.

tcpdump captures the following echo reply


14:39:57.508501 IP (tos 0x0, ttl 64, id 18673, offset 0, flags [none],
proto ICMP (1), length 36)
192.168.200.129 > 192.168.200.128: ICMP echo reply, id 555, seq 0, length 16
0x0000:  4500 0024 48f1 0000 4001 1f95 c0a8 c881  E..$H…@…….
0x0010:  c0a8 c880 0000 b975 022b 0000 5069 6e67  …….u.+..Ping
0x0020:  206d 6521                                .me!

After viewing our results in wireshark, we confirmed a successful echo
reply to the challenge.

The capture file can be download from the I Smell Packets Google group at the following URL:

http://groups.google.com/group/ismellpackets

The filename is:

13_answer.pcap


Chris continues:

I hadn’t used nping until this.  Pretty cool.  Thanks for the write-up Jon.  I’ll post a solution using hping tomorrow.

 

Advertisements


The “Ping me!” Packet Challenge Solution
October 5, 2010, 1:39 am
Filed under: Packet Challenge, scapy, spoof | Tags: , ,

The winner of The “Ping me!” Packet Challenge is Johannes Ullrich (@johullrich on Twitter) Here’s Johannes’ solution:

Johannes writes:

I used scapy to craft the response. Here is the scapy command line sequence with explanation:

e=Ether(dst=’00:0c:29:a6:5e:2f’, src=’00:0c:29:48:55:1f’, type=0x0800);

The ethernet header: Just reverse source and destination, but keep the type the same.

i=IP(version=4, ihl=5, tos=0, len=36, id=1234, flags=0, frag=0, ttl=64, proto=1, src=’192.168.200.129′,dst=’192.168.200.128′);

For the IP header:
– – we swap the source/destination, but keep everything else the same. TTL could of course be different but lets just assume that the receiving host also uses a Unix’isch starting TTL of 64. I picked a different IP ID just to make a point that it is not necessarily the same as the inbound one.

The ICMP Header:

ic=ICMP(type=0, code=0, id=1, seq=555);

type and code is ‘0’ for an ICMP echo reply. The ID and sequence number have to be the same as in the request.

The payload is the same as the request (Ping me!).

So the complete packet:

p=e/i/ic/’Ping me!’

and then send it at layer 2: sendp(p) (optionally, we could specify the interface here).


Here is the packet as received by tcpdump using the ‘xx’ option to inspect the full ethernet header:



02:19:27.048612 IP 192.168.200.129 > 192.168.200.128: ICMP echo reply, id 1, seq 555, length 16
0x0000:  000c 29a6 5e2f 000c 2948 551f 0800 4500
0x0010:  0024 04d2 0000 4001 63b4 c0a8 c881 c0a8
0x0020:  c880 0000 b974 0001 022b 5069 6e67 206d
0x0030:  6521

 

Chris continues:

Congrats Johannes!  Of course if Johannes enters he’s going to win. 🙂  Honorable mention goes out to Jon Wohlberg who used Nping to craft the ICMP echo reply.  I’ll post Jon’s solution tomorrow.



The “Ping me!” Packet Challenge
September 20, 2010, 2:19 pm
Filed under: Packet Challenge, pcap | Tags: ,

Yet another packet challenge for all of you to try.  This time the challenge is to craft the best possible reply in response to the packet in this capture.

The capture file can be download from the I Smell Packets Google group at the following URL:

http://groups.google.com/group/ismellpackets

The filename is:

13.pcap

As always, best explanation wins. Send your answers to chris (dot) christianson (at) gmail (dot) com.



“The Spy Hunter” Packet Challenge Results and Solution
September 13, 2010, 1:34 pm
Filed under: Packet Challenge | Tags: ,

The results are in and the solution has been posted to the “The Spy Hunter” Packet Challenge.  Go to Alec R Waters (@alecrwaters on twitter) blog at wirewatcher.wordpress.com for the whole story.

Bookmark and Share



“The Spy Hunter” Packet Challenge
August 23, 2010, 1:38 pm
Filed under: Packet Challenge, pcap | Tags: ,

spyhunter.jpgThere has been an incident at Yellow Sun Heavy Industries, a government defense contractor.  You have been called in to investigate. Do you think you have what it takes to solve the case?

Try the latest packet challenge from ismellpackets.com friend, Alec R Waters (@alecrwaters on twitter). The packet challenge is entitled, “The Spy Hunter.”

The capture file can be download from the I Smell Packets Google group located at the following URL:

http://groups.google.com/group/ismellpackets

The filenames are:

spyhunter-brief.pdf

spyhunter-irc.pcap

Best explanation wins their choice of a $15.00 Starbucks Gift Card or $15.00 iTunes Gift Card. Send your answers to chris (dot) christianson (at) gmail (dot) com.

****************************

Disclaimer: All characters in this challenge are fictitious. Any resemblance to real or virtual persons, living or dead, is purely coincidental.

At no point in this challenge should you attack any system. All tasks can be accomplished by performing simple analysis.

******************************

Bookmark and Share



Winning Solution to “Add It All Together” Packet Challenge Reloaded
August 14, 2010, 1:19 am
Filed under: NetworkMiner, Packet Challenge, pcap, Wireshark | Tags: , , ,

The winner of the “Name that Tune” – Packet Challenge is Travis Lee (@eelsivart on Twitter) Here’s Travis’ solution:

Travis writes:

To analyze this packet capture, I will be opening this file in Wireshark.

In Packet 1, expand the Internet Protocol section.  This is the IP Header information for this packet.  To find the 8th byte of the IP header for this packet, click on Internet Protocol line.  This is the line that also shows the source and destination IP addresses.   After you click on this line, in the bottom frame in Wireshark, you will notice that a group of numbers is highlighted.  These are the bytes (separated by spaces) that make up the IP header.  When counting bytes in a packet, you must start counting with the number zero.   Counting from the first highlighted byte, we will count until we reach byte eight and we see that it is 40.  If you click on that byte on the bottom frame, you will see that the Time to live field is now highlighted.  This is the 8th byte in the IP header.  Notice that we are not using the number 64 because that is the value of the field and not the actual byte (hex) equivalent.

In Packet 4, expand the Transmission Control Protocol section.  In here you will find the Flags field of the TCP Header.  When you expand this section, you will see that this section contains eight, 1 bit flags.  When an individual flag is set, the bit is set to 1.  Since each individual flag is only 1 bit in length, when a flag is set, its value will be 1 in binary which is also 1 in decimal.  Looking at the Acknowledgement (ACK) flag, we see that it is Set and its value is 1.

In Packet 8, expand the Internet Protocol section.  This section contains the IP Header for the packet.  Part of the IP Header contains the Time to live (TTL) field for the packet.  We see that the TTL for this packet is 128, but this is in decimal form.  The quickest way to get the hex equivalent for this value is to click on the “Time to live” line, and look at the bottom frame in Wireshark.  You will see that a number is highlighted in the bottom section.  This is the hex value for that field in the packet.  We see that the number is 80.

The next question is asking for the number of bytes in the 8th IP Datagram.  The term datagram is usually synonymous with the term packet and since all the data in this capture have been transmitted over TCP/IP, we can say that the 8th IP datagram is the 8th packet.  To find the number of bytes in this IP datagram, we will select Packet 8 and expand the Internet Protocol section.  This is where we will find the Total Length field in the IP Header.  The Total Length field defines the entire datagram size, which includes the header and data in bytes.  We see that this number is 113.

In Packet 10, we see that the destination IP address is 192.168.94.128.  IPv4 addresses are represented by 32 bits and are split into four parts, separated by dots, each of which is represented by 8 bits.  A grouping of 8 bits is called an octet.  When we look at this IP address, we see that the last octet is 128.  Now we need to convert this number into binary.  First we need to list the powers of two in a base 2 table from right to left.  Since an octet is 8 bits, we will list eight elements.

128         64           32           16           8              4              2              1              (base 2 table)

Then we need to find what the greatest power of two from this table that will go into our decimal that we are converting, 128.  128 is the greatest power of two that goes into our number 128.  Easy!  We will then write a 1 underneath 128 in our base 2 table.  We will now write a 0 under all the other numbers because none of the other base 2 numbers go into 128.

128         64           32           16           8              4              2              1              (base 2 table)

——————————————————————————-

1              0              0              0              0              0              0              0              (binary)

We see that the number after conversion to binary is 10000000.

In Packet 12, expand the Internet Protocol section.  In here you will find the Flags field of the IP Header.  When you expand this section you will see that this section contains three, 1 bit flags.  When an individual flag is set, the bit is set to 1.  Since each flag is only 1 bit in length, when a flag is set, its value will be 1 in binary which is also 1 in decimal.  Looking at the Don’t fragment flag, we see that it is Set and its value is 1.

Now what do we do with this number?  This doesn’t look like it is a “phrase that pays.”  Unless that’s the amount of money you win on this challenge?  Probably not… J

Let’s look further into this packet capture to see if there is anything else that might lead us to an answer.

We can see that this is a capture of FTP traffic according to the Protocol field in Wireshark.  Looking at the Info field, we see that a user is connecting to a FTP site, logging in, and downloading a file named File.rar.  Let’s find out what that file is and what it contains.

To figure out what this file contains, we need to extract the file from the packet capture.  To do this, we need to first find the packets where the data transfer is taking place.  Looking at Packet 33, the protocol is FTP-DATA and the size is 112 bytes.  This is a good place to start.  To find other packets associated this, we will right-click on Packet 33 and select Follow TCP Stream.  Looking at the raw packet data, we see that this is possibly a RAR archive with a file named File.txt in it.  This might be what we are looking for!! We want to make sure that the only data we extract is the data that the FTP server is sending back to the client.  To do this, in the Follow TCP Stream window, there is a drop down box near the bottom of the window.  We will select the part of the conversation that is from the server (192.168.94.152) to the client (192.168.94.128), which is 112 bytes in size.  We will also make sure that the radio button next to Raw is selected as we want the data its original raw format.  Then click Save As and select the directory to save it to and a name for the file.  Since this looks like a RAR file, we will save it as File.rar.

Now let’s try opening this file.  Since I am on Windows, I am using a program called WinRAR to try to extract the file(s) in File.rar.  File.rar opens in WinRAR and shows that there is a file named File.txt contained in it.  As we try to extract File.txt, we notice that it is protected by a password.  Let’s try using the solution that we came up with during the challenge (10000235).  It worked!!

When you open File.txt, you see that there is a phrase that says “Too Many Secrets”.

Chris continues:

Congrats Travis! Well done. Thanks to everyone who sent in entries. Honorable mention goes out to Aaron Lundell, who also submitted a very good write-up. Another cool tool I thought I would mention in case you’ve never heard of it is NetworkMiner. It is great for extracting files from pcaps.

Here is a screenshot:

NetworkMiner Screen shot.jpg

NetworkMiner can be downloaded from the following URL:

http://networkminer.sourceforge.net/

If you’d like to submit a challenge to http://www.ismellpackets.com contact me at chris (dot) christianson (at) gmail (dot) com.

Bookmark and Share



“Add It All Together” Packet Challenge Reloaded
August 7, 2010, 1:29 am
Filed under: Packet Challenge

The file in the previous pcap that was posted got corrupted. Here is a new pcap and what you now need to do to win.

To win this challenge add the following numbers together:

  • The 8th byte of the IP header of the 1st packet
  • The value of the ACK flag in the 4th packet
  • The TTL of the 8th packet (in hex)
  • The number of bytes in the 8th ip datagram
  • The value of Last Octet of the Destination IP address of the 10th packet (in binary)
  • The value of the don’t frag bit in the 12th packet

The capture file can be downloaded from the I Smell Packets Google group located at the following URL:

http://groups.google.com/group/ismellpackets

The new filename is:

12b.pcap

Best explanation wins. Send you answers to chris (dot) christianson (at) gmail (dot) com.

Bookmark and Share