I recently used Wireshark at work to better understand one of the protocols in our codebase, and I found it was a much more efficient way of learning how the protocol works (at least on the happy path) than just reading the code. To learn more about Wireshark, I decided to download and analyze some pcap (packet capture) files. One of these pcap files was of an AIM conversation between a rogue employee (Ann) and a mystery person, and the challenge is to determine the following from the .pcap file:
- The name of Ann’s IM buddy
- The first comment in the captured IM conversation
- The name of the file Ann transfered
- The magic number of the file
- The md5sum of the file
- The secret recipe
The first thing I did was open the pcap file in Wireshark and filter by Ann’s IP address:
The AIM protocol is well-known, and Wireshark even claims to have support for it. Unfortunately for us, the initial handshake to the AIM server is done over SSL, so all subsequent messages to the AIM server are flagged as also having a protocol of SSL. The fix, of course, is to tell Wireshark to treat these packets as AIM packets. This is as easy as right clicking one of the packets, clicking “Decode As,” then selecting AIM under the transport tab. Voila, the protocol switches to AIM:
If you look above, you can see I clicked on Packet 25 (flagged as an outgoing AIM message to Sec558User1), and Wireshark has already determined the message text. I added a column to show the message text, then I added a filter to only show messages with a valid message text, and now we can see the entire conversation:
Next, we need to get the name of the file Ann transferred. A quick google search reveals that AIM file transfers occur over port 5190 using the OSCAR File Transfer Protocol (OFT2). Additional Googling reveals that Wireshark does not have built in support for AIM_OFT2. I decided to start by filtering all traffic on port 5190:
There’s a TCP handshake, then 192.168.1.158 sends a packet with a 256 byte payload. Looking at the payload, there’s some promising text such as “Cool FileXfer” and “recipe.docx”. This must be the file Ann wants to transfer. My first thought was to reverse engineer the OFT2 protocol and rebuild the attachment, but that seemed really time consuming. Instead, I decided to assume that OFT2 sends the entire attachment without interjecting any headers or anything like that. I then right clicked on one of the packets and clicked “Follow TCP Stream”, then saved the entire stream to disk.
I opened the raw stream in a hex editor and searched for the docx header, which is “50 4B 03 04 14 00 06 00”. This starts at 0x200 (512 in decimal):
To determine the end of the file, I did the same thing. docx files are supposed to end with “50 4B 05 06” followed by 18 additional bytes. This signature ends at 0x30d5, so adding 18 gets 0x30e7 for the end of the file. This looks reasonable to me, since some kind of OFT2 packet appears to start at 0x30e8.
I then used dd to extract the file and get the md5sum:
jsaxton@stalin:/data/pcap_dumps/contest01$ dd if=stream.bin of=recipe.docx bs=1 skip=512 count=12008
12008+0 records in
12008+0 records out
12008 bytes (12 kB) copied, 0.03644 s, 330 kB/s
jsaxton@stalin:/data/pcap_dumps/contest01$ md5sum recipe.docx
8350582774e1d4dbe1d61d64c89e0ea1 recipe.docx
I’m not naive enough to open a .docx file published as part of a computer security exercise, but since a .docx file is just a compressed xml file, I decided to try the following:
jsaxton@stalin:/data/pcap_dumps/contest01$ unzip recipe.docx -d tmp
Archive: recipe.docx
inflating: tmp/[Content_Types].xml
inflating: tmp/_rels/.rels
inflating: tmp/word/_rels/document.xml.rels
inflating: tmp/word/document.xml
inflating: tmp/word/theme/theme1.xml
inflating: tmp/word/settings.xml
inflating: tmp/customXml/_rels/item1.xml.rels
inflating: tmp/customXml/itemProps1.xml
inflating: tmp/word/styles.xml
inflating: tmp/docProps/core.xml
inflating: tmp/customXml/item1.xml
inflating: tmp/word/fontTable.xml
inflating: tmp/word/webSettings.xml
inflating: tmp/docProps/app.xml
jsaxton@stalin:/data/pcap_dumps/contest01$ sed -e 's/<[^>]*>//g' tmp/word/document.xml
Recipe for Disaster:1 servingIngredients:4 cups sugar2 cups waterIn a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove the saucepan from heat. Allow to cool completely. Pour into gas tank. Repeat as necessary.
Now we know what the recipe is.
While I already knew that AIM traffic was unencrypted, I was shocked at how trivial it was to extract a conversation using just a packet capture. I assumed the type of work involved would be comparable to what I needed to do to reverse-engineer the file transfer logic, but that was not the case at all…
Blog