Update: CCS will be released at Black Hat EU 2011!
Black Hat DC 2011 was great – a lot of interesting people, interesting talks, and nice parties. Unfortunately I wasn’t able to demonstrate and release the Cloud Cracking Suite as planned, as I’m facing legal problems. I hope that I can settle this issue soon, since I put a lot of work into CCS and really want to launch it now. I apologize for the delay, but I’m afraid that at least for the time being my hands are tied.
Because of the huge media coverage about my upcoming talk “Breaking encryption in the cloud: GPU accelerated supercomputing for everyone” at Black Hat DC I want to make sure that no one is getting the wrong impression about what I’m going to demonstrate:
Back in November last year (Happy New Year by the way) I performed a very simple benchmark using the CUDA Multiforcer to get a basic idea of how Amazon’s new ‘cluster GPU instances’ perform when it comes to brute forcing passwords that are stored as an SHA-1 hash. Because I was very interested in doing some work in this direction, I decided to start programming a tool that’s able to startup instances on the Amazon EC2 cloud and use them to crack encryptions in a distributed way. The possibility of doing this is nothing new: Moxie Marlinspike, a hacker/sailor/pyrotechnician, is running a service called WPACracker that can be used for cracking handshake captures of WPA-PSK using several, very large dictionaries on a 400 CPU cluster that runs on the Amazon cloud. Even though this process is pretty fast (it takes about 20 minutes), I wanted to know how much speed at which cost factor we can get using the latest generation of cloud instances.
The results of my work and the tool that I developed to do this will be released as part of the talk, so that everyone will be able to start his own cluster in the cloud and get some impression of what can be done using the latest high performance computing possibilities. To give you an idea about what I mean by high performance: I’ll demonstrate how to break a WPA-PSK handshake at a speed of ~400.000 PMKs/s, and maybe (if I get it finished by then) also at a speed of over 1,000,000 PMKs/s.
My last article about the benchmark on the new GPU Cluster instances in the Amazon cloud had a large impact. One magazine wrote:
“A German hacker claims to have used cloud computing to crack passwords stored in an algorithm that was developed by the NSA.”
Well, at this point, I have to get some facts straight. What I did was benchmarking the speed of the new instance type for cracking SHA1 hashes. My first result was that it takes 49 minutes to do a 95 characters, 6 digit long brute force attack on a list of 14 hashes. The thing that was new is that, due to the new Amazon offering, everyone is able to spawn a 100-or-more node cluster in the cloud and distribute the task of cracking passwords onto these nodes. The task of cracking hashes is especially suitable for massive parallelization! An attacker could easily spawn a gigantic cluster of nodes using stolen credit card information, and it would be no problem for him to crack 8-character passwords in a nice timeframe.
The reason I said that SHA1 is deprecated for storing passwords is easy to explain: SHA1 was never made to store passwords. SHA1 is a hash algorithm; it was made for verifying data. It was made to be as fast and as collision-free as possible, and that’s the problem with using it to store passwords: It’s too fast! The speed of computers is increasing incredibly fast, so brute forcing will get faster and faster, too. And the new cloud offerings make parallelization of such tasks easy and affordable. Instead of hash algorithms, one should use Key Derivation Functions like PBKDF2 or scrypt. Some of these functions hash passwords a thousand times, which makes brute forcing them a lot harder.
I hope that this article helps some people understand the real impact of using the cloud for cracking passwords.
Update: Great article about this at Threatpost! This also got slashdotted, featured on Tech News Today and there’s a ZDNet article about this.
Update: Because of the huge impact I have clarified some things here
As of today, Amazon EC2 is providing what they call “Cluster GPU Instances”: An instance in the Amazon cloud that provides you with the power of two NVIDIA Tesla “Fermi” M2050 GPUs. The exact specifications look like this:
22 GB of memory
33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core “Nehalem” architecture)
2 x NVIDIA Tesla “Fermi” M2050 GPUs
1690 GB of instance storage
64-bit platform
I/O Performance: Very High (10 Gigabit Ethernet)
API name: cg1.4xlarge
GPUs are known to be the best hardware accelerator for cracking passwords, so I decided to give it a try: How fast can this instance type be used to crack SHA1 hashes?
Using the CUDA-Multiforce, I was able to crack all hashes from this file with a password length from 1-6 in only 49 Minutes (1 hour costs 2.10$ by the way.):
This just shows one more time that SHA1 for password hashing is deprecated – You really don’t want to use it anymore! Instead, use something like scrypt or PBKDF2! Just imagine a whole cluster of these machines (which is now easily available to anybody thanks to Amazon) cracking passwords for you. Pretty comfortable, large-scale password cracking for everybody!
Some more details:
If I find the time, I’ll write a tool which uses the AWS-API to launch on-demand password-cracking instances with a preconfigured AMI. Stay tuned either via RSS or via Twitter.
Installation Instructions:
I used the “Cluster Instances HVM CentOS 5.5 (AMI Id: ami-aa30c7c3)” machine image as provided by Amazon — I chose this because it was the only image with CUDA support built in — and selected “Cluster GPU (cg1.4xlarge, 22GB)” as the instance type. After launching the instance and SSHing into it, you can continue by installing the cracker:
I decided to install the “CUDA-Multiforcer” in version 0.7, as it’s the latest version of which the source is available. To compile it, you first need to download the “GPU Computing SDK code samples“:
Now we need to install the g++ compiler:
The next step is compiling the libraries of the SDK samples:
Now it’s time to download and compile the CUDA-Multiforcer:
Since the Makefile of the CUDA-Multiforcer doesn’t work out of the box, we need to open it up and find the line
Replace CCFILES with LINKFLAGS so that the line looks like this:
And type make. If everything worked out, you should have a file ~/NVIDIA_GPU_Computing_SDK/C/bin/linux/release/CUDA-Multiforcer. You can try the Multiforcer by doing something like this:
Congratulations, you now have a fully working, CUDA-based hash-cracker running on an Amazon EC2 instance.
Update: This is fixed in revision 362 of the SET.
The current Social Engineering Toolkit version from SVN (Revision 359) contains a broken java_applet.pde which will result in a compiling error like:
You can find a small patch for this (and another) issue here (or here in plaintext).
Today I received my NXP mbed Design Challenge kit. At first glance it looks like a cool piece of hardware: NXP LPC1768 (ARM Cortex-M3 Core) running at 96 MHz, 512KB flash, 64KB RAM, Ethernet, USB device/host, CAN, SPI, I2C, Analog I/O etc., but the first question is of course: How can I get my code running on this thing? Upon connecting the mbed to your computer via USB, a mass-storage device appears, onto which you just drop your compiled files. To create these compiled files, you can either use the browser-based IDE at mbed.org or build them locally using arm-elf-gcc. When I got to this point, I was really disappointed: They only provide object files of their libraries, no source code. That sucks. But for now, let’s ignore that fact and go on.
The first thing I wanted to try out was interfacing the mbed using XMLRPC via USB (serial) from Python. In the mbed cookbook there is a module provided for that, but even loading that module fails:
Obviously, the loading fails because of the period in front of the bracket. After removing it the module loads. The next issue was this line in the sample code:
This is wrong, because DigitalOut needs either a string or a pin instance as its second argument, but the module doesn’t throw an exception which makes it harder to track this issue down. The code should look like this:
(This is fixed in the Wiki now.)
After that, I was able to get a LED on the mbed blinking – Cool! But I was anything but pleased by the module, so I started improving it. I replaced some stuff to make the code a bit easier to read and modify, and I added a list called ‘pins’ which can be used to interface pins 0-29 using something like:
You can find the latest version here: mbedrpc.py
Or check out the git repository at Github here.
After these starting difficulties, I’m now able to interface the mbed within my Python shell and everything works fine. I hope that the guys from mbed decide to open the sources of their libraries at some point, as that would make the project MUCH cooler. We would actually be able to learn something about the processor by reading the implementations and could extend the libraries with our own cool ideas – and I’m sure that there are a lot of people out there who have some great stuff in their head about what could be done with the mbed.
Update: I was relying on a cookie which only showed up under certain circumstances. This is fixed now, but accounts will show up multiple times in Firesheep. I will fix this soon.
Firesheep is a great tool to show ‘normal’ people how important it is to know how to surf securely. For that reason, I just created some simple Firesheep handlers for the German social networks from VZnet. You can find them at Github and then just import them into Firesheep or grab the latest version of them right here:
And remember: With great power comes great responsibility. Don’t be evil.
On the last day of the DIYDA we had two great workshops at the DingFabrik: Fabienne did a workshop about building small, insect-like robots, while in the other room Julian showed how to make your own lamp out of wood and some other small parts you can get at your local building center.
After that, the closing event (or “finissage“) of the DIYDA took place at JACK IN THE BOX: With live music and a cold beer it was really nice to enjoy the several sculptures they had there, mostly made out of cardboard and paper, ranging from a few centimeters to several meters in size.
In the end, I think the DIYDA was a great event to get the DingFabrik going: We had some cool workshops, many visitors, and most importantly a lot of fun. Let’s see what comes next!
Today there were two workshops in the rooms of the DingFabrik: Kathrin showed how to make your own stamps, and Fabienne and Wim brought their MakerBots. I spent most of the time socializing at the stamps workshop, and also tried to actually make my own Pacman stamp. The number of visitors really surprised me. Some interesting people who showed up were attracted by the idea behind our fab lab and may even want to join us.
Update: Wow, F-Secure UK and KoreLogic are linking to this!
Over the last couple of weeks, multiple people pointed me to articles about the idea of using maps instead of passwords. Most of them pointed me either to this MSNBC article or to this Discovery News article. In a nutshell, the idea is that instead of a password field, you’d be presented with a small box with a map like the one from Google Maps, nd instead of typing in your password, you’d have to zoom to a location on the map you specified during your registration process. Most of my friends’ reaction: “Hey, isn’t that a great idea?” My reaction: “No.“ In this post, I want to explain why I think that using a map instead of a password is a bad idea.
In my opinion, everything on the web should be accessible by disabled or physically disadvantaged people. In the case of a map, this is just not possible:
Blind or nearly-blind people just can’t see the map. They’re using braille displays or text-to-speech systems to browse the internet along with special browsers, most of which are not even able to execute JavaScript. (This is a real problem. Projects like reCAPTCHA acknowledge this by providing an audio-based alternative for people who are not able to see the captcha itself.)
Do you really want to lock out anyone who can’t see a map?
When using this approach, you’ll prevent anyone who has disabled JavaScript from logging in. Also, most of the browsers on ‘older’ mobile phones don’t work well with embedded maps, as they only have basic, broken or no JavaScript support. Then there’s the problem of the massive bandwidth consumption of this: Especially on mobile devices in areas where only 2G is available, it may take several minutes to get to your exact location. User friendly, isn’t it?
The article on MSNBC states:
By zooming down through the map to the high level of resolution, users can graphically produce a nearly unbreakable password that neither people nor viruses could track.
That’s bullshit. There are several big problems with the map approach to passwords. Here are two of them:
The first thing that came to my mind when I read about the idea was “What about shoulder surfing?” Just imagine you’re sitting behind someone who is logging in using this technique. How hard would it be to remember the exact location he zoomed in to? Well, I actually tried it out: I told a friend of mine to remember a location on a map, and then zoom in on it with all captions/labels on the map disabled. Even though the place was somewhere in South America, I was able to remember the exact location he zoomed to. You may say “Hey, I could also read the password someone is typing from his fingers!”, but that’s a lot harder, as you can’t actually see it on the screen. I’d be willing to bet good money that no one could ever just read my password off my fingers — at least not without a good hidden camera.
Just imagine you give a presentation to a crowd of people and everyone can actually see your password!
Bill Cheswick, the guy behind this idea, is quoted in the Tech Daily News as claiming:
“You could have a 10 digit latitude, and a 10-digit longitude, then you have a 20-digit password.”
First, about the math: as latitude and longitudes are numeric characters only, we have a 20-digit, numeric password. This means there are 1020 combinations, that’s 100,000,000,000,000,000,000, or one hundred quintillion different passwords. But remember: Most of the earth is covered with water, and no one will actually be able to remember a place somewhere in the ocean. (According to the Wikipedia, 71% of the planet are covered with water, but let’s just ignore this fact and go on.)
How far exactly do I have to zoom in to get this 10 digit latitude/longitude precision? Well latitudes and longitudes range from 0 to 360, so we would need 8 digits after the decimal point to get the promised “20-digit password.” Take a look at “Usability” to get an idea on how real that is.
Let’s pretend I’m not disabled, I’m not on a mobile network, no one is watching me and I’m using a modern browser with good JavaScript support. Let’s also pretend I’ve set up my ‘password’ to be the center of the cathedral of Cologne, Germany.
An overview over the Cologne Cathedral:
Zoomed farther in onto the center of the cross:
Let’s zoom in to the maximum available zoom factor of Google Maps and show the location I’ve set my ‘password’ to, in this case, it’s at the point (represented as decimal fraction) “50.94132,6.95812″:
Now, to give you an idea of the dimensions, I’ll add a second marker with an increased longitude of 0.00001:
Well, this should give you an idea of how realistic the idea of a 20-digit password is. In this case we’ve got a longitude of 7 digits and a latitude of 6 digits, and it’s already almost impossible to zoom to the exact location, and even if you manage to do so, how much practice would it take to always get to the right location without always trying out at least 5, slightly different locations? (Especially since you wouldn’t even know in which direction your ‘password’ is wrong!) And don’t forget: You’ll want to have a different location for each service you log on to. So where does Mr. Cheswick get this 20-digit password myth from?
I don’t think this idea is a viable replacement for text-based passwords. I don’t think that it’s impossible to write viruses that analyze the screen of the user and try to find password maps and then keep track of where the user zooms to. And I also don’t think this approach provides any usability- or security advantages over traditional passwords. In fact, I think it’s not usable and it’s insecure. I agree that we need new solutions, but this is definitely not the way to go. I’m also not sure if replacing the password itself is the right way to go. But I do think the spreading of SSO (Single Sign-on) and two-factor authentication are something that might be able to make the net a bit more secure.
