Louwrentius

This article has been updated to reflect the changes for John version 1.7.8 as released in june 2011. The most important change is the fact that MPI support is now integrated in the jumbo patch.

The original John the Ripper off-line password cracker only uses a single processor (core) when performing brute-force or dictionary attacks.

JtR does not use multiple cores (or machines). However, there is a patch available that enables support of MPI. MPI allows you to distribute the workload of a program across multiple instances, thus cores or even machines, but your application must support it.

The fun thing with MPI is that it is very easy to create a password cracking cluster. But for now let's just focus on using all these unused CPU cores to help us with cracking passwords.

I am using Ubuntu and Debian Linux as my platform but Mac OS X works also perfectly.

install MPI support

Note: Mac users have mpi support installed by default and don't need to install this.

• apt-get install libopenmpi-dev openmpi-bin

download John the Ripper with extra patches

• Get the john-1.7.8-jumbo-2.tar.gz file.

extract John & edit the Make file

• tar xzf john-1.7.8-jumbo-2.tar.gz
• cd john-1.7.8-jumbo-2/src
• uncomment the following lines in the Makefile:

  CC = mpicc -DHAVE_MPI -DJOHN_MPI_BARRIER -DJOHN_MPI_ABORT`
  MPIOBJ = john-mpi.o`
  

Compile John the Ripper with MPI support

• Run make and choose the most appropriate processor architecture. Example:

  make linux-x86-64 (for 64-bit i386)
  make linux-x86-sse2 (for 32-bit i386)
  make macosx-x86-64 (for 64 bit Mac OS X)
  

Test john the Ripper

• cd ../run
• ./john --test

Look at the benchmark values of the first test and remember them. Now let's see if MPI does any better:

• mpirun -np [number of processor (virtual) cores] ./john --test

Let's asume that you have an iMac 27" with a Core i7 with 4 real cores and hyper threading enabled. This will provide a total of 8 virtual cores.

• mpirun -np 8 ./john --test

If you notice a significant increase in performance, you know that MPI is working properly.

Some benchmarks without and with MPI support (Traditional DES)

These are the benchmark test results when using a single core on an old Nehalem Core i7 920:

Many salts: 2579K c/s real, 2579K c/s virtual
Only one salt:  2266K c/s real, 2266K c/s virtual

These are the benchmark test results when using MPI and thus all 8 cores:

Many salts: 11015K c/s real, 11015K c/s virtual
Only one salt:  9834K c/s real, 9834K c/s virtual

And just look at the performance improvement when we overclock from 2,66 to 3,6 Ghz:

Many salts: 15004K c/s real, 15004K c/s virtual
Only one salt:  13232K c/s real, 13232K c/s virtual

That is very significant. Now admire how the Core i7 920 @ 3.6 Ghz is blown away by the Sandy bridge based Core i7-2600 @ 3.4 Ghz:

Many salts: 20007K c/s real, 20209K c/s virtual
Only one salt:  16881K c/s real, 16881K c/s virtual

Setting up an MPI cluster

MPI clustering is based on using SSH keys. There is a single master that uses all nodes to perform the computation. The nodes are put into a text file nodes.txt like this:

node01  slots=2
node02  slots=2
node03  slots=4 
node04  slots=4

In this example, node 2 and 3 are dual-core systems, while node 3 and 4 are installed with quad-core processors. You must create an account on all your nodes with the same name that is used on the master, when running the master process. You also must generate a private SSH key and distribute the public part as the authorized_keys file to all nodes. This is outside the scope of this post. Please note that the SSH private key should be loaded with ssh-agent if used with a passphrase, or do not configure a passphrase on the key. If you do not use a pass phrase, understand that anyone with access to the key can access all nodes.

You may also have to put the nodexx entries in your /etc/hosts file if the names cannot be resolved by DNS.

Now I'm assuming that you are able to ssh into all nodes without requireing a password, thus ssh is properly setup.

* mpirun -np 12 -hostfile nodes.txt ./john --test

Now you should see increased performance, beyond the limit of a single host.

Some benchmarks

I ran a password cracking test on some data using a large dictionary. These are the performance differences when using all 8 cores of my Core i7 920 instead of just one:

single: 0:00:04:48      c/s: 11192K
mpi:    0:00:01:26      c/s: 46568K

The performance increase is significant.

The battle between Firewire and USB has been won by USB, but Firewire is still arround. It is not that prevalent, cheap computers lack Firewire, but they often have a PCMCIA slot.

The thing is this: Firewire allows direct access to all RAM of your computer. An attacker can:

• unlock your screensaver without a valid password;
• read the contents of documents or files present in memory;
• defeat FDE (Full Disk Encryption) like Truecrypt or Bitlocker;
• do nasty things with your computer limited only by skill and imagination.

So if you leave your system unattended for a short duration, consider your system compromised. I mean, if you are a celebrity or something, otherwise, don't worry, nobody would be bothered since it is a risky attack: the attacker needs physical access.

The attacker attacks your laptop by connecting his laptop to yours with a Firewire cable. Firewire must be enabled in the BIOS of the victim, which is the default in most cases. Even if Firewire is disabled, the PCMCIA adapter can also be used to access RAM. The attacker can insert a PCMCIA Firewire controller and use it to attack your laptop.

Basically, the Attacker makes the attacking laptop pretending to be an iPpod, a type of advice which is allowed to access memory through DMA. This allows the attacker READ and WRITE access to memory. The possibilities are endless, but injecting executable code, compromising the laptop is not far fetched.

Many people may already have stopped reading because this attack is very old and widely publicised: it dates back to 2003/2004. However if you are not familiar with this attack and want to know more about it, visit this site.

The mitigation

As far as I know, the only solution to prevent this type of attack is to disable both Firewire and PCMCIA support in the BIOS. It is smart to protect the BIOS with a strong password, so both options cannot be enabled.

I read somewere that most recent Apple Macbook models are no longer vulnerable, but I could just make that up.

I started a small new Google project for a new script I wrote called LFS. It stands for Linux Firewall Script.

I run a small Linux box as an internet router that doubles as a firewall. The firewall is configured using iptables. In my opinion, iptables is not the easiest tool to use and may have a steep learning curve for people new to it.

The goal of LFS is to provide an easier interface to iptables. It also adds some features that by default are not or difficult to setup using only iptables. The most important additional feature is the use of objects and groups. Object groups can be used to make a single rule affect multiple hosts, networks or services.

LFS uses a single configuration file which contains the firewall rules. Rules look like this:

nat 192.168.1.0/24 88.32.44.144 eth0
port_forward 88.32.44.144 192.158.1.10 80/tcp 8080/tcp

Or by using variables:

nat "$INTERNAL_NETWORK" "$EXTERNAL_IP" "$NAT_INTERFACE"
port_forward "$EXTERNAL_IP"  "$INTERNAL_HTTP_SERVER" "80/tcp" "8080/tcp"

Please visit the project page for some examples.