We have written in the past about how to
crack passwords on password-protected RAR and ZIP files, but in those cases someone wrote a program to extract the
password hashes from the RAR and ZIP files first. After that, we could use
John the Ripper to generate passwords (or use a dictionary) to attack the password hashes. In this case, John the Ripper generates a password, then hashes the password with the same hashing/salting method as the hash we are attacking. If the hash matches, then we have the clear-text password.
However, in some situations, we don't have a password hash to attack, or maybe we don't know what algorithm is used. Either way, we may not be able to extract a hash for whatever reason. In this case, we can still brute-force the password using the standard authentication mechanism.
In this tutorial, I will be brute-force attacking a
LUKS encrypted file using
John the Ripper. A LUKS encrypted file is similar to a truecrypt container. It could be used to encrypt a disk, partition, or file.
Let's assume that an investigator extracted all files from a suspect disk. By looking at the file headers, we find the following:
encrypted: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 811f8a08-85da-4f7d-b50f-3e64ed7a66f4
Maybe the investigator has no memory image of the suspect device or any other information regarding the file, but still needs to get into it....
To mount a LUKS file from the (linux) command line, you have to use
cryptsetup . The command usually looks like
cryptsetup luksOpen container mountpoint . When you attempt to mount, by default it will ask for a password 3 times if the attempts are incorrect. We cannot pass the password directly to cryptsetup as an option, it will always ask for a password.
Regardless of some challenges, cryptsetup does have some useful options, such as -T which controls how many times it will ask for a password before giving up. And also the option
--test-passphrase, which will see if the password worked without actually opening the device. So right now we have the following command to open the LUKS device:
cryptsetup luksOpen $1 x --test-passphrase -T1
Now we can use John the Ripper in incremental mode sending the output to standard out to generate our password list.
john -i --stdout
Now we just need a small script to capture the output of JtR and test the cryptsetup password:
#!/bin/bash
# Using john the ripper to brute-force a luks container
startTime=$(date)
if [ $(file $1 | grep -c "LUKS encrypted file") ]; then
john -i --stdout | while read i; do
echo -ne "\rtrying \"$i\" "\\r
# as root
echo $i | cryptsetup luksOpen $1 x --test-passphrase -T1 2> /dev/null
STATUS=$?
if [ $STATUS -eq 0 ]; then
echo -e "\nPassword is: \"$i\""
break
fi
done
echo "Start time $startTime"
echo "End time $(date)"
else
echo "The file does not appear to be a LUKS encrypted file"
fi
This bash script first uses file to check whether the input is recognized as a LUKS encrypted file. If so, it will run JtM in incremental mode, and output to stdout. A while loop is used to capture the generated password as a variable "i". We then echo the password, and pipe it to the luksOpen command. That way, when cryptsetup asks for a password it will use the password we have piped to it. The status will be either 0 if it worked or 2 if the password failed. If the status is 0, then we print the password, and how long it took. If the status is not 0, we get a new password and try again.
Now, if you start to run this script you may notice that it is very, very, very slow. Generating passwords with JtM is relatively quick, but trying the passwords on a LUKS device is designed to be slow.
This process will likely take a very long time, but 1) it will eventually crack any type of device and 2) it can be used when you have no other option.
Try to use the script to play around with other password-protected files/devices.
