CSAW CTF 2012 - Networking 200

Networking challenges for CSAW CTF 2012 reminded me of classic PCAP diving, and this one proved to be no different.

lemieux.pcap
Some dude I know is planning a party at some bar in New York! I really want to go but he's really strict about who gets let in to the party. I managed to find this packet capture of when the dude registered the party but I don't know what else to do. Do you think there's any way you can find out the secret password to get into the party for me? By the way, my favorite hockey player ever is mario lemieux.


Digging through the PCAP showed a lot of standard network traffic: HTTP, DNS, UPNP, DLNA, HTTPS, etc. Where to start? Since the user supposedly registered for a party, the likely candidate is some sort of HTTP transaction. Setting a Wireshark filter for "http" still yields A LOT of traffic. Using tshark, NetworkMiner, etc we can see which URLs are being requested.

tshark -r lemiuex.pcap -R "http" -Tfields -e http.host

This reduces the possibilities, but isn't the cleanest. Luckily, the last few lines show a server or "taproom307.com". Now that's an establishment I've heard of. If the user did register, there's hopefully a HTTP POST associated with it. Let's narrow our search:

tshark -r lemiuex.pcap -R 'http.request.method == "POST" and http.host == "www.taproom307.com"'

Yup. Since I'm lazy, I fired up the same request in Wireshark to view the actual HTTP contents. One of the POSTs shows a message being sent with a 'key phrase' of "brooklyn beat box".

CSAW CTF 2012 - Web 100

Ahh, a simple Web attack problem:

[URL FROM GAME]

Lara Anderton needs to break into PreCrime to free her husband, but they just installed a fancy new security system. Help her break into it!


Browsing to the website presented a simple username/password form. Exploiting web sites presents many different avenues when looking at a black box (aka no source). First? Look at the HTML presented to the user's web browser. In this case, nothing stands out. Next step? Maybe try some blind SQLi? How about watching the traffic from the browser?

Firing up Wireshark showed that web browser was given a plaintext cookie with the active username, and a field called auth which was set to 0. I think we just found our avenue. There are mutliple ways of manipulating the HTTP headers, but in this case I used Burp proxy since I had it lying around.

When the browser sent over the next request, using the Intercepting Proxy, I modified the Cookie to "auth=1;user=admin" and the following response had the key response: "c4ca4238a0b923820dcc509a6f75849b".

Metasploit's SSL giving you the alkjblkjalksjdf.org blues?

So you've developed your awesome, passive 0-day exploit module in Metasploit. 100 out of 100 throws and every time it succeeds. Sweet! But wait a tick, what's this? Looking at the SSL handshake you find that Metasploit's auto-generated SSL certificate is less than optimal. What? Waddya mean adkljablkj1kljadsf.com is going to set off any red-flags to your un-suspecting victim?

Easy enough, let's just change the SSL cert that's being used with the server's handshake. While you'd think this is a straight-forward config value, turns out the implementation is a little round-about.

GDB error != runtime error

While trying to develop an exploit recently, I ran into a 'fun' issue with GDB: lies. See, while working on a ROP buffer I had been stepping through with GDB to ensure everything was lined up properly. At the very last step of the exploit, the one before actually calling my shellcode, I kept running into the same error:

(gdb) msi
0x0804a92e in <....... removed .......>
=> 0x804a92e <....... removed .......>    ret   
(gdb)
Cannot access memory at address 0x5f
(gdb)

After double-checking the exploit payload, the registers, re-adjusting values, etc I still saw the same error. Finally out of frustration, I told GDB to continue just so the application would crash. To my surprise, the crash never happened and my shellcode executed! Wait! What? I thought we had a memory access problem. Turns out, that error was from GDB trying to read the current application location by referencing EBP, which had just been trashed with the value 0x5f. Next time, need to pay attention that no SIGNAL had been received by GDB. Or, maybe GDB could have been nicer to state that why/what it was accessing 0x5f.

More than fossils in TAR

Buried deep in the GNU manual for tar are references to a prompt when changing tapes. Now, I don't know many people who actually still use tar with tapes, but let's look an interesting excerpt:

When GNU tar comes to the end of a storage media, it asks you to change the volume. The built-in prompt for POSIX locale is(23):

Prepare volume #n for `archive' and hit return:

where n is the ordinal number of the volume to be created and archive is archive file or device name.
When prompting for a new tape, tar accepts any of the following responses:

and

!

Request tar to run a subshell. This option can be disabled by giving ‘--restrict’ command line option to tar(24).

So if we can force the end of a tape prematurely, tar will allow us to drop to a prompt. Turns out a few lesser used options provide just that ability. Here's an example script that will drop to yet another shell. Check it yourself with 'ps f' afterwards.

#!/bin/sh
dd if=/dev/zero of=./filler bs=1024 count=30
echo "at the next prompt, enter '!' without the quotes and press Enter"
tar cf /tmp/tmp.tar --multi-volume --tape-length=10 ./filler

Hex-Rays + C++ = The Low Pass Filter

Recently doing some RE on a closed-source C++ library, and Ida alone wasn't cutting it as the C++ name-mangling, and operations can be quite 'noisy'. So I figured why not throw it through Hex-Rays' decompiler to get a look at just the C++ operations.

My favorite feature of Hex-Rays is being able to quickly recognize obfuscation operations. These are generally instruction intensive and if written in a high-level language, often times filled with extra mov's and unnecessary operations. This makes it more time-consuming to decipher. Hex-Rays generally chews this kind of stuff up and spits out the juicy bits.

Now, following the de-obfuscation was a series of C++ string-class operations that consisted of concatenating various pieces. To aid in deciphering which pieces were used when, I figured that Hex-Rays would be able to easily decipher this and provide me the same goodness as the de-obfuscation.

Anyone who's used Hex-Rays knows all about its ability (or IN-ability) to actually decompile some code and the feature of just omitting the code. In this case, I was hoping that it should at least pick up the C++ object operations and just display those to minimize the extraneous work. Turns out, Hex-Rays actually dropped most of the C++ operations that I was originally interested on the floor. BUT, what it did reveal was a key even better than what I was searching for. So in this case, Hex-Rays acted as low-pass filter to remove the noise that I thought was interesting data. Lesson learned? Just because it was omitted doesn't mean it wasn't useful, but it may make something else more obvious.

Red Dead while PSN is Dead, Part 3

So after one night of the script working, future tests kept turning up nil results.

Everything we tried kept showing the broadcast messages for finding a server, as well as the server response; but, the client would not connect.

Reviewing traffic over-and-over again turned up nothing new at the IP layer. Turns out, the IP address of the server is embedded in the message sent by the server. I discovered this by noticing ARP requests for my IP address on the other network. A quick fix of changing the repeater address of the "fake" server to that of a PS3-server and voila, working again.

I'll dig into the protocol to find that in the fields and release a new version of the scripts that will fix the IP on the fly. Until then, at least there is a work around.