OpenMPI distributed password cracker: crackzor



Previous versions:


Quick start
  1. Download & extract with “tar zxvf crackzor_1.0.tar.gz”
  2. Make sure you have the right packages in place
    sudo apt-get install build-essential libopenmpi-dev openmpi-bin libssl-dev
  3. Compile with
    mpicc -O3 crackzor.c -o crackzor -lm -lssl -lcrypto
  4. Create a file called “machines” containing a newline separated list of every machine that are in your cluster, for example:
  5. Open MPI uses SSH for communication between nodes, as such, you need to make sure that the node you will be launching crakzor from is able to do SSH key based authentication to all the other nodes in the cluster. For my example above, if machine00 is where you will be working from, you will want to

    where X E [0,4] (yes, machine00 needs to be able to SSH to itself).

  6. You now need to disseminate your executable across all the machines that will be running it:
    for machine in `cat machines`; do scp crackzor $machine:~; done

    Pro-tip: having network storage attached to all the machines makes this step unnecessary.

  7. Run with:
    mpirun -npernode Y -machinefile machines crackzor fbade9e36a3f36d3d676c1b808451dd7 abcdefghijklmnopqrstuvwxzy 1 1

    where Y is the number of cores each machine in your cluster has. If you are running this on machines with 2 CPUs with 8 cores each, Y = 8 * 2 = 16.

Tested on Ubuntu 10.04 64b / Ubuntu 12.04 64b / Ubuntu 14.04 64b

mpirun -npernode 16 -machinefile machines ./crackzor 7ca4793dcdff46ecda38e48d65b6c913 abcdefghijklmnopqrstuvwxzyABCDEFGHIJKLMNOPQRSTUVWXYZ 1 7

This is what “htop” looks like with a bunch of processes spawned & hammering every core:


For the purpose of testing crackzor, we give it the md5 hash of an 8 character word and tell it to bruteforce it up to 7 characters. This insures that we will compute every permutation up to 7 character longs. The characters I asked it to permute are “abcdefghijklmnopqrstuvwxzyABCDEFGHIJKLMNOPQRSTUVWXYZ”, our sample space size is thus 52^7 + 52^6 + 52^5 + 52^4 + 52^3 + 52^2 + 52^1 = 1,048,229,971,204.

Here is the raw data, and here it is graphed:

I wish it would show the linear progression more but 3 things got in the way:

  1. approaching the machine’s actual number of cores on the Dell blades leaves little room for linear expansion
  2. which is emphasized in a multiuser environment where other users run other computation
  3. the EC2 bar flattens the graph a bit but I still wanted to show how it compares

Ideally I would run through a few iterations of EC2 to observe its progression but hey, it’s expensive :).

  • Right now, the only hashing algorithm supported by crackzor is MD5. It can very easily be expanded upon.
  • I also may not be using the fastest MD5 method with the fastest call, distribution is what I’m interested in.
  • Distributing password cracking among multiple machines is throwing linear resources to an exponential problem!

IPv6 link-local surface analyzer



Quick Start

    1. make sure that nmap, ifconfig & arping are installed and in your path
    2. run as root

    tested on Ubuntu 11.10 64b


    (actual ips obfuscated)


    With more devices coming IPv6 ready out of the box, a shadow network is emerging that nobody is paying attention to.

    There’s Joe sysadmin, configuring a tight firewall for this new server, default deny, very restrictive & all. This is great but did he realize that there is nothing in front of IPv6? We are used to setting up iptables, ipfw, et cetera. Unfortunately ip6tables & ip6fw too often get forgotten.

    With IPv4, a device was manually configured or wasn’t configured until it got an address from DHCP. With IPv6 a device that is not manually configured will hop on the network with a link-local address and try to further discover its settings. In fact, IPv6 reserves a range of addresses for network discovery, these link-local addresses are based on the device’s mac address.

    Here is what does:

    • iterate through a given IPv4 range
    • for each address in the range, discover if a host sits behind it
    • port scan potentially found host on IPv4
    • infer IPv6 link-local address of host based on its mac address
    • port scan inferred IPv6 address

    The purpose of which is to establish by how much your attack surface is augmented by link-local IPv6.

    This threat threat is somewhat mitigated by its local nature and there are 2 reasons why:

    1. link-local isn’t routed and thus your visibility is bound to networks you have a presence on.
    2. Getting a host’s mac address is only possible while being on the same network.

    Local as it may be, having a shadow network providing a way to circumvent firewalls is quite risky.

    Poor man’s 2FA: a simpler 2-factor authentication mechanism for SSH

    The problem with PAM based 2FA:
    • PAM does not get called when the SSH daemon does key based authentication. So your 2FA there only works with password authentication. This might be something you want but maybe not.
    • A PAM module based solution to 2FA is harder to implement
    The solution: Poor man’s 2FA!

    It is possible to add the ForceCommand directive to your sshd_config. Like the name suggests it simply runs a command after authentication and before the shell is spawned. This is a good spot to add an extra check, say another factor for authentication.

    The code:
    trap "echo "I'm sorry Dave. I'm afraid I can't do that."; sleep 1 ; kill -9 $PPID ; exit 1" 2 20
    code=`od -a -A n /dev/urandom | head -2 | tr -d ' ' | tr -d 'n' | sed 's/[^a-zA-Z0-9]//g' | awk '{print substr($0,1,5)}'`
    echo -e "Subject:$code\nFrom:root@server <>\n2FA code in subject" | sendmail
    read input
    if [ $code = $input ];
        `awk -F: '($1 == $LOGNAME) { print $7 }' /etc/passwd`
    kill -9 $PPID

    That’s it really, save this to an executable file, replace the obvious variables and ForceCommand its ass.