01-21-2017, 04:39 PM
After multiple weeks of coding and preparations I've completed the support for hashcat to crack LUKS protected partitions and volumes.
LUKS offers a set of "crypto items" (hashes, ciphers, blockmodes and keysizes) which can be used to configure an encrypted block device. The user can freely select them which then creates a large number of possible crypto relevant combinations. This made it a very work intensive implementation especially without a crypto library and on GPU.
The following crypto items are supported for LUKS:
Hashes:
To find out which crypto items are configured in your LUKS volume you can use the command:
Unless you're using some very uncommon setup, I'm certain that hashcat will support all of the crypto items in your LUKS volume. Hashcat will automatically detect them and automatically select the correct kernel for you.
Short story on LUKS is:
The first PBKDF2 iteration count is automatically selected from cryptsetup by measuring how many iterations can be done in 1000ms on the host CPU (unless the user override the time using -i). However, the second PBKDF2 is not needed actually. While it provides a bullet-proof way to check if the password is correct, it also adds a very expensive PBKDF2 with usually more than 100000 iterations (on a modern system). It is preferable to avoid it, and that's why hashcat does the following instead:
This is how I tested how the first sector changes after a format:
The idea is simply to find out if the mkfs.XXX is doing "something" to the first sector at initialization (formating). And they do, all of them! They either set zero bytes or some kind of header. That's what we're hoping for, because that enables us to do an entropy check on it with the goal to workaround the expensive 2nd PBKDF2 computation.
Hashcat also supports the cracking of the multiple keyslots that can be used in LUKS. For those who are not familiar with this concept: LUKS allows the use of multiple passwords ("keyslots", up to 8) for the same volume. We can not know which one contains the easiest password, but each of them have its own iteration count. In theory it makes sense to attack the one with the lowest iteration count, but after some thought I decided against it. We need to test all of them, regardless of the iteration count because it's easier to crack a simple passwords with 1000000 iterations than a hard one with just 100 iterations. Therefore it doesn't make any sense to give the user control on which keyslot to test, but if anyone has a good idea why it would make sense letting the user choose, please let me know and I'll add a parameter for it.
There's two things missing (at the moment) in order to make hashcats LUKS support "full featured":
To crack LUKS with hashcat, simply use hash mode 14600 and specify the path to the partition "file". For instance that is /dev/sda1 on where you normally specify the hash file. There's no luks2hashcat or so required. To make the LUKS image more "portable" you can also use this command:
This creates a 2mb file which includes all the data hashcat needs to start cracking.
Being able to crack LUKS using hashcat doesn't mean that LUKS is broken. There's also no reason to criticize the KDF of LUKS because of the possible shortcut. The high iteration count and the large AF dataset makes this algorithms one of the slowest you can think of. At least I was able to make it 15 to 25 times faster (yes, times, not percent!) than any other password cracker (both commercial and non-commercial) on the same system/hardware. I'm very proud on this work.
- atom
LUKS offers a set of "crypto items" (hashes, ciphers, blockmodes and keysizes) which can be used to configure an encrypted block device. The user can freely select them which then creates a large number of possible crypto relevant combinations. This made it a very work intensive implementation especially without a crypto library and on GPU.
The following crypto items are supported for LUKS:
Hashes:
- PBKDF2-HMAC-SHA1
- PBKDF2-HMAC-SHA256
- PBKDF2-HMAC-SHA512
- PBKDF2-HMAC-RipeMD160
- AES
- Serpent
- Twofish
- CBC-Plain
- CBC-Plain64
- CBC-ESSIV
- XTS-Plain
- XTS-Plain64
- 128
- 256
- 512
To find out which crypto items are configured in your LUKS volume you can use the command:
Quote:$ cryptsetup luksDump /dev/XXXX
Unless you're using some very uncommon setup, I'm certain that hashcat will support all of the crypto items in your LUKS volume. Hashcat will automatically detect them and automatically select the correct kernel for you.
Short story on LUKS is:
- Do a PBKDF2 on the password with a very high iteration count
- Use the derived key to decrypt a large set of anti-forensic data
- Merge the decrypted AF data to form the masterkey
- Do a PBKDF2 on the masterkey again with a high iteration count
- Compare the derived data with the data stored in the LUKS header to verify if the password was correct
The first PBKDF2 iteration count is automatically selected from cryptsetup by measuring how many iterations can be done in 1000ms on the host CPU (unless the user override the time using -i). However, the second PBKDF2 is not needed actually. While it provides a bullet-proof way to check if the password is correct, it also adds a very expensive PBKDF2 with usually more than 100000 iterations (on a modern system). It is preferable to avoid it, and that's why hashcat does the following instead:
- Since we have the masterkey after the first PBKDF2 we can start decrypting the payload data
- If we can predict the data after decrypt we can do a known-plaintext attack
- Unfortunately the data isn't 100% known, but from my tests it shows it's different to random data (see below)
- Decrypted data with an invalid key looks like random data, therefore hashcat can do an entropy check on it
- If the entropy is below some threshold we can assume the password was correct
- EXT2
- EXT3
- EXT4
- XFS
- Reiser4
- Btrfs
This is how I tested how the first sector changes after a format:
Quote:$ dd if=/dev/urandom of=test bs=1M count=100
$ cryptsetup luksFormat test
$ cryptsetup luksOpen test tmp
$ xxd -l 512 /dev/mapper/tmp ## is random data at this point
$ mkfs.XXX /dev/mapper/tmp
$ xxd -l 512 /dev/mapper/tmp ## should no longer be random data
$ cryptsetup luksClose tmp
$ rm test
The idea is simply to find out if the mkfs.XXX is doing "something" to the first sector at initialization (formating). And they do, all of them! They either set zero bytes or some kind of header. That's what we're hoping for, because that enables us to do an entropy check on it with the goal to workaround the expensive 2nd PBKDF2 computation.
Hashcat also supports the cracking of the multiple keyslots that can be used in LUKS. For those who are not familiar with this concept: LUKS allows the use of multiple passwords ("keyslots", up to 8) for the same volume. We can not know which one contains the easiest password, but each of them have its own iteration count. In theory it makes sense to attack the one with the lowest iteration count, but after some thought I decided against it. We need to test all of them, regardless of the iteration count because it's easier to crack a simple passwords with 1000000 iterations than a hard one with just 100 iterations. Therefore it doesn't make any sense to give the user control on which keyslot to test, but if anyone has a good idea why it would make sense letting the user choose, please let me know and I'll add a parameter for it.
There's two things missing (at the moment) in order to make hashcats LUKS support "full featured":
- Support for Keyfiles
- Support for Whirlpool
To crack LUKS with hashcat, simply use hash mode 14600 and specify the path to the partition "file". For instance that is /dev/sda1 on where you normally specify the hash file. There's no luks2hashcat or so required. To make the LUKS image more "portable" you can also use this command:
Quote:$ dd if=/dev/XXXX of=header.luks bs=512 count=4097
This creates a 2mb file which includes all the data hashcat needs to start cracking.
Being able to crack LUKS using hashcat doesn't mean that LUKS is broken. There's also no reason to criticize the KDF of LUKS because of the possible shortcut. The high iteration count and the large AF dataset makes this algorithms one of the slowest you can think of. At least I was able to make it 15 to 25 times faster (yes, times, not percent!) than any other password cracker (both commercial and non-commercial) on the same system/hardware. I'm very proud on this work.
- atom
Amazing work!
gj on ur work and thanks alot!