Data Extraction From Packet Capture

I stumbled across an interesting contest today, and just had to give it a shot. There's just one catch though, I have never tried to extract data from a PCAP file before. In fact, I really didn't even know that it could be done...although I'm not surprised. Anyway, here is how I extracted the complete document that was transferred from Ann's computer to the rogue laptop. You did read the puzzle's scenario, right?

Bear in mind that as this was my first attempt to do something like this, I went through quite a few failures before I did the following. Despite my problems, I had fun and am glad I kept at it.

The first thing to do was download the PCAP file and open it up in Wireshark. Once the file was opened, I set Wireshark to show only the packets sent from Ann's computer by setting the following filter:

ip.src == 192.168.1.158

From the scenario, I knew that Ann sent some sort of file to the rogue laptop, and that more than likely it was done through an IM client. The previous image shows that "aol" is listed in the info for all of the packets going to the address 192.168.1.159. I don't know much about AOL, but I do know that they have an instant messenger that is quite popular. Knowing this, I decided to look at these packets and see what could be found.

The first thing I noticed in the packet was "Cool FileXfer." Things started looking really interesting. So that I could see all of the traffic sent from Ann's computer to this address, I chose to follow the TCP Stream of the conversation.

It all looked like a bunch of gibberish, but one thing really caught my attention..."recipe.docx." Maybe this was the file I was after. I decided to give it a shot and chose to save the stream. To save it, I selected Raw, clicked Save As, and saved the stream as recipe.docx.

Trying to open the file in Word proved unsuccessful, as there was an error with it. Still certain that this contained the file I was after, I decided to do a little hex editing. Not wanting to mess things up, I opened up Word and created my own DOCX file to serve as a baseline for my editing.

Looking at my test file, I noticed that its header had a hex value of:

50 4B 03 04 14 00 06 00 08 00 00 00 21 00 DD FC 95 37 66 01 00 00 20 05 00 00 13 00 08 02 5B 43 6F 6E 74 65 6E 74 5F 54 79 70 65 73 5D 2E 78 6D 6C 20 A2 04 02 28 A0 00 02

The corrupted Recipe document had the same hex value, but there was unnecessary bits preceding it. I decided to do some hex editing and remove the unnecessary bits from the Recipe document. After hex editing, I saved the Recipe file and opened it in Word. I still got a warning about the file, but I chose to try and open it anyways.

Bingo! There was the secret recipe I was looking for. I had actually managed to extract all of this from a simple packet capture. Wicked!

What? You want to know the recipe? Well...go get your hex editing on like I did.

Read More

Insecure Data Transmission

Back in April of this year I made a startling discovery regarding a certain web site that I was required to use for one of my college classes. This web site was not using SSL on its login page.

For those who don't understand how SSL works, here's a partially summarized explanation:

SSL (Secure Sockets Layer) is a protocol that was designed to transmit data securely across the Internet. Data transfered across an SSL connection is encrypted using a public key. TLS (Transport Layer Security), an extension of SSL, is a protocol designed to provide privacy and data integrity between devices communicating across the Internet. Together, these two protocols are known as SSL/TLS.

There are two layers that make up SSL/TLS, the TLS Handshake Protocol and the TLS Record Protocol. The TLS Handshake Protocol is where the authentication between the server and client takes place, as well as the negotiation of the encryption that will be used during the communication. The TLS Record Protocol ensures privacy during communication by using data encryption.

SSL is used to secure web communications by way of HTTPS (Hypertext Transport Protocol over Secure Sockets Layer). This differs from HTTP in that data is sent over SSL/TLS, and is therefore encrypted. HTTP, on the other hand, sends data as plain text.

Knowing all if this, the problems with the discovery that I made start to become clear. With users submitting their login information over HTTP and not HTTPS they were unknowingly transmitting their usernames and passwords to the site as plain text.

This was big a problem.

With data transferring insecurely, an attacker on the same network as the user could run a packet capturing application to obtain the user's login information to this particular web site. The security problems start to really add up when it is taken into account that many users still use the same login credentials across multiple web sites. With this in mind, the security flaw with this one site can potentially compromise multiple web site accounts owned by a user.

Eventually, I had one of my IT instructors notify the web site's administration about this flaw so that they could fix it. Four months later and this is what can be seen in the packets sent to the web site.


It has yet to be fixed.

Read More

NetStumbler Fun

Fired up NetStumbler today while in town. Managed to scan a total of 36 access points during my short trip. Of the 36 access points, 24 were using encryption. Can you guess what type of encryption they all used? Yeah, they were all using WEP. Of those 24 access points that used WEP, 13 were using default SSIDs.

I'm seeing more and more people setting up their APs with WEP as of late. I guess I should be happy that they're actually trying to secure themselves, but I'd really like to see some SSID cloaking. Better yet, some WPA encryption going on.

Nonetheless, driving around with NetStumbler running is always fun. I get to see how popular WiFi is becoming in these rural towns, plus I get to see some very unique SSIDs from time to time.

Read More