Breaking Encryption – Hashed Passwords (LUKS Devices)

Hello 0x00sec! Today in this article we’ll be cracking a device encrypted with LUKS (Linux Unified Key Setup). Breaking LUKS encrypted devices (or any type of encrypted devices) are surprisingly easy if you know what you are doing.

It’s been some time since I joined 0x00sec so I thought it’s about time I contributed something. This is my first article so any valid criticism is welcome.

##The Theory

We could crack LUKS like how these guys did it, but that means authenticating many, many passwords with the luks device the normal way. Which means that that every password would take 1 second just to find whether or not it is correct. If we were using the crackstation wordlist to find the passwords it would take 1,493,677,782 seconds (or 47 years) to get through the wordlist and the password may not even be found.

A better way exists though.

Basically every program loads itself into memory. This includes encryption programs (surprise!). What this means is that whenever a drive is getting authenticated, the program loads the hashed password into the RAM. If we can grab the memory, all we need to do is find the hash, run it through a password cracker and volia! We’ve got the plain text password.

##Practical

That sounds goods in theory, but how do we implement that in the real world? Well, you’ll need a few tools. I used:

  • 1 LUKS encrypted device (preferably USB) – We’ll use this as our test subject

  • 1 USB (we need somewhere to store the memory dump)

  • 1 Linux OS with cryptsetup on it (I used a Live USB)

  • LiME LKM (Using this to dump the RAM)

  • AESKeyFind from http://citp.princeton.edu/research/memory

With that out of the way, let’s begin!

##Step 1: Get an encrypted LUKS device

We need a test subject to test our super 1337 H4X03R skill on, so go ahead and encrypt a USB with LUKS. To do this open terminal and type:

fdisk -l
// Find the disk we want to encrypt
cryptsetup luksFormat /dev/sdX 
// Creates the LUKS container. Make sure to remember password here. We’ll need it for the next steps.
cryptsetup luksOpen /dev/sdX crackme 
// Opens the LUKS container so we can create a filesystem
mkfs.ext4 /dev/mapper/crackme 
// Creates the filesystem
mount /dev/mapper/crakme /crackme
// Mounts freshly made filesystem. We need to check if it’s working.
cd /crackme
//At this point feel free to create a secret file (proof text) to prove you hacked it :)
umount /crackme
// Unmounts device, it is ready for hacking.
cryptsetup luksClose crackme

With our device ready, let’s move on to the next step:

##Step 2: Install LiME

LiME is an LKM used to dump the memory of a computer running Linux. (If you don’t know what an LKM is, google it.) To get it go to http://github.com504enesicsLAbs/LiME and download the zip file. If you want, you can gitclone it.

Once downloaded, unzip and compile LiME:

unzip LiME-master.zip
cd LiME-master/src
make // Compiles the LKM from the makefile provided.
modinfo lime.ko // Shows us the details of the newly built LKM.

There should now be a file called LiME.ko. Don’t close the terminal yet. We’ll need it for later.

##Step 3: Open device and dump the RAM

Next, we want to open the LUKS device for authentication, then dump the RAM. Open a new terminal and type:

fdisk -l

This lists all the devices connected to the computer. Find your LUKS encrypted device and note down the /dev/sdX of the device. Next, type:

cryptsetup luksOpen /dev/sdX crackme  
// Where /dev/sdX is the letter of your device

Leave the terminal there.

The hashed password has now been loaded into the RAM. Time to dump the RAM! Go over to the over terminal where you compiled LiME. In it type:

insmod /path/to/lime.ko “path=/path/to/usb/memdump.raw format=raw” // That’s where that second usb comes in.

We want the output to be raw because we don’t want the hash to get mucked up by formating. Also aeskeyfind probably won’t understand other formats.

This will dump the RAM to a disk on the computer. Any disk can suffice, so long as you can access it and it is not the luks device.

LiME will give no ouput, but when it is done it will return the terminal back to you. It’s best not to do run other apps right now. LiME will take some time to finish (on my computer it took around 5 minutes to dump 4GB) so take a break and do something else while you wait.

##Step 4: Grab the hash from the RAM dump

With the ramdump finished, we now need to find the hash. To do this, download aeskeyfind from http://citp.princeton.edu/research/memory. Unzip it and compile the program. To do this, in a terminal type:

tar -xvf aeskeyfind-1.0.tar.gz
cd aeskeyfind

There should now be a program called aeskeyfind in the folder. To find the hash run:

./aeskeyfind -v /path/to/memdump

This will show you the found hashes in the memory dump. Once that’s done, you can run it through a password cracker. If you need more information for your password cracker, type:

cryptsetup luksDump /dev/sdX

This will give you the cipher, salt and UUID of the LUKS device among other things.

##Conclusion:
As always, a long and complex password is the best form of defense against such an attack. There really isn’t much you can do about people grabbing hashes from the memory, apart from said defense or nuking your keyslots.

This article has been more centered around grabbing the hashed password of the LUKS device. If you want to learn how to crack hashes, check out this null-byte link: http://null-byte.wonderhowto.com/how-to/password-cracking/

Anyway, that’s enough for today. As always, take your security seriously and hope to see you here or at ##0x00sec on freenode sometime soon.

– Falcon403

6 Likes

Awesome post man. 1337 cred to you :stuck_out_tongue: I never considered this approach. I’m guessing this would be a lot more tricky on a main HDD, and on a computer that wasn’t on to when you found it.

I look forward to seeing your other posts, they’re very easy to read, good job!

3 Likes

Nice post.

Just one question. As you have root access (what you need to load the LKM) and you have to be on-line when the drive is mounted, why not just trojanize cryptsetup and get the password next time somebody mounts the drive?.. I know is not that cool but is there any other reason you can point out?

Didn’t know about lime. Looks interesting. Thanks for the share

@0x00pf: I think you might be missing something out. I used a live USB, which is why I had root access. You don’t need to have access to the main OS.

But yes, you could ‘trojanize’ cryptsetup on the main OS but that would include RE I guess. Not my level of expertise yet. Or you could program a false authentication portal and hand the typed password over to the true cryptsetup.

Anyway, thank for the feedback!

I may be too tired today, and certainly I’m missing something… if you boot with a live USB, how does the LUKS password gets into memory?

In step 1 you enter the password to create the crypted device. If after that you follow all your steps without rebooting, the password is indeed still in memory. But if you reboot the memory is deleted.

If you boot with a USB live to get root… who enters the password?.

Surely I’m missing something… any pointers?

GREAT post, and I admire your creativity on achieving the decryption!

1 Like

@0x00pf: The password is not what’s in memory. @falcon403 is using a memory dump to grab the hash of the password.

2 Likes

Thanks for the support, @pry0cc! I appreciate it :slight_smile:

@0x00pf: In step one we are creating a LUKS device to test our skills on it. The password was only needed to create a filesystem inside the LUKS container.

Whenever you start to open a LUKS device the hash gets loaded into the RAM, ready to authenticate passwords. You don’t even have to input a password for this to happen. That is why we could get the hash. Anything in step one is irrelevant to step three. Nobody needs to enter the LUKS password, cryptsetup does that for you (the hashed password anyway.)

Hope that helps.

@falcon403 thanks for the explanation mate. I overlooked this part of your post

1 Like

I’m wondering whether the hashes are salted; on the last screenshot I can see that the easkeyfind displayed a 256-BIT key (probably SHA256). Do you know whether once hashes are in memory, are they salted - probably even if they are on disk, they are not in memory and what we obtain is an actual hash.

Other than that, it would be great to talk about the possible arguments that one needs to pass to luksFormat when creating an encrypted drive to make this somewhat harder. I realized an attacker can obtain the hash regardless, but a SHA-512 hash should be harder to crack than the SHA-256 hash - it would be great if you can provide the safest luksFormat command currently provided by cryptsetup.

This topic was automatically closed after 30 days. New replies are no longer allowed.