I Smell Packets


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