Filed under: NetworkMiner, Packet Challenge, pcap, Wireshark | Tags: NetworkMiner, Packet Challenge, pcap, Wireshark
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 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.
The winner of the “Name that Tune” – Packet Challenge is Jon Wolhberg (@jonw18 on Twitter) Here’s Jon’s solution:
Jon writes:
Here is my answer to the latest packet challenge and how I got to it.
The song is Never Gonna Give You Up by Rick Astley
The first thing I did was to open the pcap in wireshark and just look around to see if anything sticks out. What I noticed right away were all of the beacon frames which means we are dealing with some wireless traffic. Since the beacon frame has the name of the network, I decided to look at one of the packets and identify the SSID — in this case the name is “Linksys”.
I also noticed that the protocol being used is 802.11 which means there is some authentication to the network and probably some encryption surrounding the packets. I decided to look for the packets the provided the authentication in hopes of cracking the password. After some trial and error, in Wireshark, I filtered on eapol to see if eap over lan was the method for authentication. Low and behold I got 8 packets, that have the authentication handshake (these can be seen in packets 137,139-143,145,148).
Now that I have the SSID and I know I have a capture file with the authentication handshake, I need to crack the password. For this I used Backtrack4. After loading Backtrack I decided to use the program cowpatty. In order for this to work I need the capture file, the SSID, and a dictionary file, which cowpatty comes with (yes there are faster ways). The command I used was ./cowpatty -f dict -r 11.pcap -s Linksys (-f = dictionary file, -r = capture file, -s = SSID). After a few seconds the password had been cracked. The password is 12345678
Now that I have to the password, I need to decrypt the packets. I went back to wireshark with the packet capture opened and went to edit -> preferences > IEEE 802.11. You then need to enter the wpa password in Key 1 exactly as the following: wpa-pwd:12345678:Linksys
You also have to check the box that says “enable decryption”.
Once this is done the packets will become decrypted. I then saw an IP address I had not seen before (209.237.235.166). Not recognizing this address, I did a NSlookup to see what it resolved to, and it came back to lala.com, a music site. I also noticed that the site was sending a lot of traffic to the on port 1420 to the client machine. Wondering what that was, in wireshark I clicked on one of the packets and clicked follow tcp stream. It was there that I saw that this is a web request and in the header it revealed this: Content-Type: audio/x-mpeg. This was the song we need to identify. In the tcp stream I saved all traffic from the server to the client. I saved this as song.mp3
Figuring this was a media file I ran the file command to verify. To my surprise I got the response: filetype ascii data. I then remembered that the http headers are also downloaded, so we need to remove them. I could have used a hex editor but found a good perl program at
http://blog.rootshell.be/2009/04/15/forensics-reconstructing-data-from-pcap-files/
The program strips out the http headers. I then ran the file command again and got this MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo. Now that I have the file I just need to listen to it. After listening for a couple of seconds, I couldn’t remeber the song title. I open my iPhone and loaded the Shazam app that identifies songs…. and that is how I got my answer.
Chris continues:
Congrats Jon! Well done. Thanks to everyone who sent in entries. Honorable mentions go out to Travis Lee for his entry, he used Aircrack-ng to crack the WPA key. And Andy and Fab who used this Top 20 Password List to crack the key:
Imperva reveals top 20 passwords
Look for another challenge coming soon.
The winner of the “What’s wrong with Smelly Widgets packet challenge?” is . . . Arvind Doraiswamy.
Here’s Arvind’s solution.
Arvind writes:
1. A blank form with a login and a password is first displayed. The webserver is running on 192.168.94.143 and an access attempt is made from 192.168.94.144.
2. Attempt at logging in with a blank username and password is then done(Packet 9). This is insuccessful as shown in Packet 12 where a user is not allowed to login with empty credentials.
3. Packet 14 sees the user try to login with the username chris and an empty password. This too is insuccessful as shown in Packet 17 , a user must have something in the password field.
4. Packet 19 sees a third attempt at trying to login with the username chris and the password “password” . The attacker is trying out various common password combinations. This too is insuccessful as shown in Packet 22 and returns an error message of “Invalid credentials” . This means that you must enter something in both fields. So the attacker must now either find a valid combination or must try and bypass the login somehow. Well, he doesn’t have a valid combination so he decides on the latter.
5. At this point though there is another request for the home page on 192.168.94.143 from 192.168.94.1. He tries to login with the username of chris and a password of smellywidgets. This results in a successful login and displays order history. This is crucial…
6. On packet 37 we now see chris making another attempt to unsuccessfully login with username chris and password ismellpackets from the IP 192.168.94.144. This again is unsuccessful.
7. The attacker on 192.168.94.144 is now fed up and decides to try and get in without a valid username and password. On packet 42 he sends a request with username and password as follows:
username: ‘ OR 1=1–
passsword: password
This login is a success!! What happened here? Lets take a look at how a normal successful login would happen in the first place.
—
EXPLANATION:
A website is hosted on a webserver. A login page is part of the website. When a user enters his username and password on the website, it is accepted as input by the website form and handed over to the code for further processing. The application code now must compare what the user entered with what is already stored in the database. If it didn’t do this — well , there wouldn’t be a need for a login form at all and everyone could see everyone’s data. Now how does the application actually do this?
The application needs to ask the database whether it has entries for the input that the user gave at the login page. So if we take the example of a successful login made by chris from the IP 192.168.94.1 the application will ask the DB – “Do you have an entry for someone called chris , he’s entered a password called smellywidgets. Is this correct?” . The DB checks in its entries and says “yes that’s fine.. Chris indeed exists – allow him in”. Now the language that the application talks to the DB is called SQL – and when it asks a question – its said to be “querying” the database. So effectively the application queries the database in a language called SQL.
Now obviously there needs to be some structure to this SQL query. So while checking authentication is sends a query as follows:
SELECT username from users where ‘username’=’chris’ and ‘password’=’smellywidgets’ . SQL surrounds its userinput by single quotes, that’s part of the syntax.
The DB check the validity of the user chris , checks if his password is smellywidgets and then if it finds an entry like that, returns the username to the application. The application checks if the number of entries returned are not 0 (meaning there was a match) and then allows the user access. Great..now we know how a normal login happens. Now what happened when we typed ‘ OR 1=1– instead of chris? Again an SQL query is formed , but this time the query is as follows:
SELECT username from users where ‘username’=” OR 1=1– and ‘password’=’password’
Pay careful attention to the ” OR 1=1– . It effectively translates to .. “Please check is there is a user called ” (BLANK) OR check if 1=1 “. Huh? Now obviously there is no user called ” or BLANK in the DB but the second part 1=1 .. well that’s always going to be true ..right? 1 is always 1 and 2 is always 2 so that part will alwys be true. This means that the first part of checking the username has evaluated to TRUE and a successful message will be returned if the password is correct as well. Er..but I don’t know the password. No problem .. that’s where the — comes along.
A — in SQL means a comment , which means everything after the — is ignored by the DB engine thus resulting in the query which runs as :
SELECT username from users where ‘username’=” OR 1=1–
It didn’t matter what password I entered, the DB just checked if 1=1 which is always TRUE, returned a message to the app saying.. hey this is TRUE. Go ahead and grant access, and the application duly did so. This technique is called SQL Injection where you modify a backend SQL query using your own input and retrieve data accordingly. Now back to the challenge!!
—–
8. Packet 51 depicts a login successful message to the SQL injection request made on packet 42. Packet 53 shows each and every widget order that was placed by every user, this is clear because multiple credit card numbers are shown in the HTTP response. This has happened because the DB has returned the first entry which it found matched the user’s request – and this was the first user , who in this case was probably an admin user who could see all entries.
9.On packet 68 the user clicks the logout button and decides to logout of the application. Confirmation of his successful logout is shown in Packet 77 and 79.
10. The attacker starts another login process in Packet 81. The body of the HTTP POST request is split across so many packets because of the size of the __VIEWSTATE parameter which ASPX applications use to remember previous entries made by users in forms. This isn’t that relevant here though as of now. The request is so huge that you see the actual userinput only in packet 86 this time. This time the entry he has made is %27%3B+UPDATE+Orders+Set+Amount%3D0.01– . What does this mean now? Time for a little bit of background on what those funny characters are:
—-
EXPLANATION:
When you type a special character which isn’t alphanumeric the browser performs something called URL Encoding on it before sending it to the server. It effectively means – When you send data over the Internet , it doesn’t need to be encoded if its ASCII.. coz ASCII is an example of “WYSIWYG” (What you see is what you get). However that isn’t true of other characters like ‘ % and others – hence they are URL encoded before sending it out. A single space is encoded as %20 by the browser – hence if there’s a space in your data you must send it as a + instead. Now back to the challenge, what does this input say?
—-
11. %27%3B+UPDATE+Orders+Set+Amount%3D0.01– translates to ‘; UPDATE Orders Set Amount=0.01– . Hmm ..things are getting interesting now. If you recall how we discussed SQL before – the backend query for this translates to: SELECT username from users where ‘username’=”; UPDATE Orders Set Amount=0.01– and ‘password’=’password’ . This tells the DB to check if the username is blank and the update all entries in the Amount column in the Orders table to 0.01. Now note …this isn’t going to successfully log you in to the DB – we don’t have a 1=1 like before but the SQL query will still work. Why? Because we know that the username field is vulnerable to SQL Injection I can not only log in by bypassing authentication — I can tell the application to send any query I want executed on the remote DB. In this case its an update query — I separate the original SELECT query and the UPDATE query with a ; — The UPDATE query won’t run unless you put the ; — That’s a separator incase you want to run multiple queries (batched queries they are called in SQL). Potentially I could run more queries by just putting in a ; between each of them. Phew ..lets move on.
12. Packet 98 – shows a failed login attempt for the UPDATE query..but that’s perfectly fine. You do not need to be “logged in” to do damage with a SQL injection. All you need is an entry point. That’s why its so dangerous. Going on then..
13. Now he tries to login with the ‘ OR 1=1– input which we discussed earlier..possibly to check whether what he did with the UPDATE succeeded or not. The complete Request body is in Packet 105.
14. Perfect!! Look at Packet 121 now.. You need to look directly at 121 because Wirshark has this feature called Reassembled TCP where it basically joins all the data split across packets into 1 long bit. if you don’t want to read inside Wireshark , you can right click paket 121 in Wireshark and do a Copy — Bytes Printable text only to a text editor. You can also copy from a FollowTCPStream. Here you can clearly see that the amounts of each and every widget is now 0.01 , meaning that the UPDATE query succeeded.. even without a successful login.
15. Packet 129 sees the attacker logout again..now that he’s confirmed that the SQL Injection has worked and Packet 140 shows him the login page again.
16. Things are now getting worse on Packet 147. By following the same methodology above you can see that the payload the attacker uses this time is:
INSERT INTO Users VALUES (100,’hacker’,’sniffthis’)– . He’s creating a new user with an ID of 100 a username of hackers and a password sniffthis. Again..the SQL will succeed..but he won’t be able to login. This shows that the ‘ OR 1=1– was primarily just a test to find out whether the field was vulnerable or not, the real juicy stuff is here. The hacker should now try and login with this new account..lets see if this happens. Packet 159 BTW predictably rejects the login attempt.
17. Yes, predictable the hacker now logs in with the username of hacker and the password of sniffthis in Packet 166 and Packet 170 shows a successful response. After the test login he logs out again on Packet 172.
18. Now he starts SQL injecting again this time using a batched SQL query (remember queries split by a ; ? ) to log in successfully with a ‘ OR 1=1– as well as add a new entry with the query :
‘ OR 1=1; INSERT INTO Orders (OrderId, Item, CreditCard) SELECT UserId,Username,Password FROM users–
Now there should be a new entry in the Orders table with the values 100,hacker,sniffthis .. right at the bottom. We’ve basically retrieved the hacker’s details from the users table and Inserted them into the orders table for some reasson. Lets see why..lets look at the response.
19. Yes , just like we thought. Have a look right at the bottom of Packet 206. We see a row 100 hacker sniffthis ; meaning that the attacker managed to successfully INSERT and VIEW his results. He then successfully logs out as can be seen in Packet 236. Now what?
20. He’s placed an entry into Orders , meaning he bought stuff without paying a cent, he’s changed all order prices , now he destroys the entire users table by SQL injecting again — ‘; drop table users– . This is on Packet 248. The by now familiar Invalid Credentials message comes in on packet 266… but he’s not bothered any more. His job is done.
21. Now there’s a connection again from the other IP 192.168.94.1 . Remember the guy here successfully logged in once? Lets see what happens now. Yes, he tries again on Packet 276 with the same username and password with which he succeeded last time – Username: chris and Password: smellywidgets.
22. Disaster.. The Users table is not found…of course it won’t be – The ‘hacker’ user dropped it after he inserted a successful order. The response in packet 279 shows this error message clearly – ERROR: Failed to execute SQL command: Invalid object name ‘Users’
Maybe there will be guys who use clever scripting techniques to pull out all the data – but since the dump was just 280 packets I didn’t really spend too much time thinking on how I’d do that and stuck to good old Wireshark instead. Thnx for a nice challenge anyway though 🙂
—
Chris continues:
About the only thing I’d like to add to Arvind’s solution is that it’s sometimes nice to know what type of systems you’re dealing with. In this particular case, you can do this by following the TCP Stream and looking at Host Headers. Notice bold text in the following output:
GET / HTTP/1.1
Host: http://www.smellywidgets.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 05 Oct 2009 17:51:57 GMT
Content-Length: 1922
…
Examining the above, we can see that this server appears to be running IIS 7 and ASP.NET. We can probably safely assume that this is a Windows 2008 server. Now, just because this is a new Windows 2008 server doesn’t mean that it’s immune to SQL injection. User input always needs to be sanitized. Filtering out characters like single quotes, double quotes, and semi-colons would have prevented this attack.
Just case you’re interested, this challenge was created using a Windows 2008 virtual machine, IIS, ASP.NET, Visual Web Developer 2008 Express, and SQL Server Express 2008.
Thanks to everyone for sending in all the write-ups. You all did a great job. It was really hard to choose a winner. Special shot out to Louw Smith for being the only one to mention the Beatles reference. It was also nice to have a couple of my former Sec 401:SANS Security Essentials students submit answers. You guys rock!
Speaking of Sec 401: SANS Security Essentials, I’ll be teaching it again in Sacramento, CA. January 28-30 and February 1-3. If you’re interested in attending please feel free to contact me. There are also some links on the left with more information.
That’s it for now. Again, congratulations to Arvind and thanks to everyone who sent in answers.
The following are some links to more information about this week’s challenge:
SecuriTeam – SQL Injection Walkthrough
SQL Injection Cheat Sheet
Cheat Sheets – pentestmonkey.net
Here is the solution to the hard version of the Crypto Kitchen Packet Challenge from Alec R Waters (@alecrwaters on twitter). There was some misdirection in this version and I think it threw a lot of people for a loop. Check this out.
Alec writes:
The first step is to load the capture into something like Wireshark for a quick look. The capture contains just one TCP session showing an email being sent from a mail client to a mail server for delivery. The easiest way to see everything that’s going on is to right-click on any row in the capture and say “Follow TCP Stream”. This will show you all of the printable characters in the TCP segment payloads, stripping off the headers:
We can see the SMTP server accepting an email from really.hungry@i.eat.packets addressed to newrecipe@recipes.on.line. The text that follows “354 OK, send” is a multi-part MIME formatted message.
The Content-Type header field tells us that it’s a multipart/mixed message, which is a way of sending several items of different types in a single email (for example, a plaintext message with an attachment). The content-type header also specifies a boundary, which is how the receiving mail client will know where one part stops and the next one begins.
As we look down the message, we can see the first instance of the boundary string (it’s hard to tell by eye, but it’s actually prefixed with two additional dashes). Each message part has its own header and body, and we can see that we’re looking of something of type text/plain – this is likely the body text of the email.
Looking further, we see the boundary again followed by another header. This time, we’re dealing with what appears to be a base64 encoded JPEG called “SecretIngredient.jpg”.
Finally, at the end of the message, we see the boundary for the last time. In this instance, it is both prefixed and suffixed with –, which tells the receiving mail client that this is the end of the message.
So, what the capture is showing us is the transmission of an email with a plaintext body and an attached image.
The object of the challenge was to discover the secret ingredient – everything needed to work out what it is is in the email, hidden in plain sight – all we have to do is look hard enough!
The first thing to notice is amongst the list of ingredients. The recipe calls for:
“30 ml Balsamic vigenere”
“Vigenere”, huh? That’s not an ingredient, that’s a cipher!
Now we have to look for something that could be ciphertext. There don’t seem to be any likely candidates in the body or header of the email, so let’s turn our attention to the attached image.
A quick-and-dirty way to extract it is to highlight all of the base64 encoded data and paste it into an online base64 decoder, like this one:
http://www.opinionatedgeek.com/dotnet/tools/Base64Decode/
Hit the “Decode” button, and you’ll download a file called DecodedBase64.bin. As we’ve already examined the structure of the raw email, we think that this is actually a file called SecretIngredient.jpg, and we can add weight to that with the file command:
thanatos:~# file DecodedBase64.bin
DecodedBase64.bin: JPEG image data, JFIF standard 1.01
Once we’ve satisfied ourselves that this isn’t a hostile JPEG that’s going to exploit a flaw in our imaging software, we can go ahead and load it up. It looks like this:
Hmm. There’s some swirly text here, hopefully telling us what we’re after. “Swirl” effects are often reversible, albeit with a degree of loss. If we load the image into an editor that can do swirls, we can try to reverse it. I used Paint.NET on Windows (http://www.getpaint.net/index.html), but I imagine there are many others that can do this.
First, highlight the swirled part of the image with the rectangle select tool:
(I’ve zoomed in a bit to make it easier)
Now select Effects->Distort->Twist… from the menu and play around with the settings. Set the Amount/Direction to -30 and squint a bit, and we find out that the secret ingredient is…
…drum roll…
…not in here! Messing around with the image was a wild goose chase.
So, we’re still looking for something that looks like ciphertext. Where else could it be?
JPEG images (amongst others) can have EXIF metadata attached to them:
http://en.wikipedia.org/wiki/Exif
This is intended to be used to store things like the camera make/model, the settings in use when you took the picture, geotagging information, etc. If we load up the image in an EXIF editor or viewer, we can see what’s there. There’s an online version here:
This tells us that there are three EXIF fields:
Document Name Pmjeyeglwfh7F
Resolution 96 pixels/inch
Software Paint.NET v3.36
The document name looks a bit odd. Perhaps that’s our ciphertext?
If we proceed with the theory that Pmjeyeglwfh7F is the product of a Vigenere cipher, all we need is the key (or enough time to brute-force it!)
Fortunately, the key is provided in the message too:
“discretion is the key”
We can decrypt our ciphertext online here:
http://sharkysoft.com/misc/vigenere/
Put Pmjeyeglwfh7F into the Input box, use discretion as the key, and hit Decode. The result is:
Merchandise7X
…which is apparently the secret ingredient in a certain brand of soft
drink 🙂
Chris writes:
The twist was a very cool idea. Again, Alec’s blog is http://wirewatcher.wordpress.com. Tomorrow, I’ll reveal the winner of the challenge and his solution.
I wanted to share another solution I received to the ‘Where in The World is Chris?’ packet challenge. This one comes from Justin Acquaro.
Justin writes:
Short Answer:
Mohrenstrabe 30
10117 Berlin, Germany
The long answer:
Using wireshark it appears that the packet is a http session to twitter ( http://twitter/cchristianson )
Follow the TCP stream shows this conversation followed by a GZIP download:
Using the save as function I save the file to packets.bin I then open packets.bin up in a hex editor (winHex). According to the RFC for gzip (http://tools.ietf.org/html/rfc1952) the start of a gzip file is always “1f 8b”. I then locate these two values in WinHex.
I then deleted all the data above this magic value and saved the results as packets.bin.gz
When I opened the file I was presented with the original contents.
Opening the file up it appears to be the HTML source of a twitter page.
Rendering the HTML yields:
Which once plugged into google maps yields:
Chris writes:
Thanks for the write-up Justin (jacquaro on twitter.)
If anyone else would like share how they solved this or any of the other challenges, please feel free to send me a message. It’s always nice to see how others go about it.
I’m back from vacation. It was a blast! Where was I? Here is the solution to last week’s packet challenge.
Opening up the pcap file in Wireshark we see the following:
A quick glance at the fourth packet reveals that this is a HTTP request to twitter.com. Note that in the Packet List Pane the fourth packet has been selected. In the Packet Details Pane the Hypertext Transfer Protocol field section has been expanded. In particular, this is a request to twitter.com for /cchristianson.
Another thing to take note of, is that there is also only one connection or flow in this particular capture. We know this because there is only one set of IP addresses, source port, and destination port combonation. In this case, it’s the one from 192.168.51.143:60538 <-> 168.143.162.116:80.
Back to the question at hand, ‘where in the world is Chris?’ Most of us are familiar with Twitter. One of Twitter’s features is the ability for a user to update their Location. This Location field is displayed on every user’s page. In this instance, this field reveals exactly where I am.
Looking through all these packets for my location would be a little tedious. To assist us in our efforts to find the right packet, Wireshark does have a nifty little search feature. To access the Search feature, go to the Edit Menu and select Find Packet. Search for the string ‘Location’ in the ‘Packet Details’ like so:
This highlights the packet that contains my location. Selecting that packet and then expanding the Line-based text data: text/html section at the bottom, reveals all the content of the web page. Scrolling through that information will reveal the Location field as well as some numbers.
The numbers are of course GPS coordinates. Inserting those coordinates into Google Maps or any other mapping software will reveal my exact location at the time, the Hilton Hotel in Berlin. Berlin is fantastic by the way.
Lot’s of people got this one right. Congratulations to Jorge Orchilles (@jorgeorchilles on twitter) for being the first. Thanks to everyone else for playing and following along.
I’ll be in Las Vegas next week attending Blackhat and Defcon. Send me a tweet or an email if you’d like to meet.
Before I go, here is one of the pictures I took while I was there. It’s of the Brandenburg Gate in Berlin.
References:
The TCP/IP Guide
Wireshark User’s Guide
Brandenburg Gate
We left off the answer to our challenge last time with a pcap file containing 4 packets. Still not knowing what Fred’s secret was, let’s continue.
Opening the file with Wireshark shows the following:
tshark -nr 5.pcap 1 0.000000 192.168.94.129 -> 192.168.94.128 SMB Session Setup AndX Response, NTLMSSP_CHALLENGE, Error: STATUS_MORE_PROCESSING_REQUIRED 2 19.000000 192.168.94.128 -> 192.168.94.129 SMB Session Setup AndX Request, NTLMSSP_AUTH, User: wilma\fred 3 39.000000 192.168.94.129 -> 192.168.94.128 SMB Session Setup AndX Response 4 296.000000 192.168.94.128 -> 192.168.94.129 SMB [TCP Retransmission] Session Setup AndX Request, NTLMSSP_NEGOTIATE
The reason tshark is used here is that it has the ability to decode Server Message Block (SMB) traffic. Tshark is basiclly a command-line version of Wireshark. Anyways, right away we see that there is a challenge, authentication, and a response. This is Fred logging into a Windows system.
Tshark can display much more information about these packets by using the -V switch. Here is just a snippet of the output:
tshark -Vnr 5.pcap
…
.... .... .... .... .0.. .... .... .... = Negotiate This is Local Call: Not set
.... .... .... .... ..0. .... .... .... = Negotiate Workstation Supplied: Not set
.... .... .... .... ...0 .... .... .... = Negotiate Domain Supplied: Not set
.... .... .... .... .... 0... .... .... = Negotiate Anonymous: Not set
.... .... .... .... .... .0.. .... .... = Negotiate 0x00000400: Not set
.... .... .... .... .... ..1. .... .... = Negotiate NTLM key: Set
.... .... .... .... .... ...0 .... .... = Negotiate Netware: Not set
.... .... .... .... .... .... 0... .... = Negotiate Lan Manager Key: Not set
.... .... .... .... .... .... .0.. .... = Negotiate Datagram Style: Not set
.... .... .... .... .... .... ..0. .... = Negotiate Seal: Not set
.... .... .... .... .... .... ...0 .... = Negotiate Sign: Not set
.... .... .... .... .... .... .... 0... = Request 0x00000008: Not set
.... .... .... .... .... .... .... .1.. = Request Target: Set
.... .... .... .... .... .... .... ..0. = Negotiate OEM: Not set
.... .... .... .... .... .... .... ...1 = Negotiate UNICODE: Set
NTLM Challenge: 89234201B1621ED1
Reserved: 0000000000000000
Address List
Length: 60
Maxlen: 60
Offset: 66
Domain NetBIOS Name: WILMA
Target item type: NetBIOS domain name (0x0002)
Target item Length: 10
Target item Content: WILMA
Server NetBIOS Name: WILMA
…
The portion of the packet highlighted above contains the NTLM Challenge. There are also some hashes in the other packets. This is all the information needed to find out Fred’s secret password.
The easiest way to go about this is to use Cain. Cain is a Windows based password cracking tool available for free. To crack Fred’s password with Cain follow these steps:
1. Open the 5.pcap file with Cain. A SMB password will appear under the Passwords on the Sniffer tab.
2. Right click the password and Send to Cracker.
3. Click the Cracker tab.
4. Select the user and scroll all the way over to the right and notice the Type of password. This is a NTLM Session Security password.
5. Right click the User name and select either a Brute-Force or a Dictionary Attack. Both will work.
6. As we just saw, the type of password we are trying to crack is a NTLM Session Security password. Select NTLM Session Security.
If you choose to do a Dictionary attack, use Cain’s default wordlist. The wordlist is located in C:\Program Files\Cain\Wordlists.
7. Click the Start button.
After a short time, no more than a minute or two, the password will be cracked. In this case the plaintext of user wilma\fred is betty. I always thought Fred might have a thing for Betty, she’s much hotter.
Congratulations goes to Davy Douhine (@ddouhine on twitter) for being the first to solve this challenge. Davy used scapy, Cain, and brute-force to figure out Fred’s Secret. He also sent me a fun little challenge to figure out. We’ll share that with you next week.
Thanks everyone for playing.
Here are links to some information referenced in this challenge:
Tshark
NTLM – Wikipedia
Security Watch: The Most Misunderstood Windows Security of All Time
Windows Passwords: Everything You Need To Know
Cain & Able
After the last Packet Challenge I received questions from a couple of individuals about viewing fragments in tcpdump and Wireshark.
To view the IP ID, the More Fragments Flag, and the Fragment Offset in tcpdump use the -v switch:
tcpdump -v
The -v switch stands for verbose. For even more detailed information add another one or two v’s:
tcpdump -vv or tcpdump -vvv
Wireshark by default reassembles fragments. To change this default behavior edit the preferences. In the Edit menu, select Preferences, expand the Protocols section, select IP, and uncheck the Reassemble fragmented IP datagrams checkbox.
For more information on Fragmentation the following is a link to The TCP/IP Guide section on the IP Message Fragmentation Process:
The TCP/IP Guide – IP Message Fragmentation Process
I Smell Packets 