Confidentiality and Integrity vulnerability with encrypted disks

[MichaelAnders]

All my hard disks are encrypted. One reason for doing that is so that the content of the disks are protected - which also means that the file names etc. are also not known until the disks are unlocked. The only part that is not encrypted is the USB drive.

 

Looking at the /boot/config/shares folder I can see all the shares which I created. While not disclosing the files, the "content" on the disks can be guessed based on the filename. That is considered an "Confidentiality" vulnerability (even if not a very critical one in this case). None the less, it is one.

 

Renaming the shares to something like A, B, C ... beats the purpose of defining names at all and is therefore not helpful imho. And it doesn't prevent other issues,

 

Additionally, these configuration files store information on the shares regarding the "security" levels. An attacker just needs to pull out the USB stick and change the shareSecurity from private to public, reinsert the USB stick and then has access to the share. That is considered an Integrity vulnerability which allows the attacker to delete/change/add (maybe illegal stuff) data on the encrypted share (even the flash disk allowing covering up any changes made) which could even get the user into a lot of trouble when user unlocks his disks and finds a surprise there...

 

However, as the shares are not used (and therefore useless) until the disks are unlocked (scenario: the user has encrypted all disks), it would make perfect sense to store the configuration files of the shares in encrypted format instead of plain text as is done right now.

 

Suggestion: Using the keyfile (which is created after the user has unlocked the disks) as the password for AES encryption/decryption of the filename and it's content is easily possible, preventing both attack vectors.

 

The same applies to other data I suspect is being stored on the USB stick, e.g. "users" (config/shadow), log files (could be stored as encrypted ZIP files), and maybe more (maybe a wlan password?) I can't think of right now. Maybe everything in the config file???

 

The argument "but the attacker would need access to your system so this is not really a problem" is imho not valid. The issues should be fixed (and I cannot imagine this being very difficult to achieve from a code perspective).

 

And also true is that this will not prevent someone from changing the unraid code itself to achieve the same goal - but that is a different technical league.

 

The ultimate security would be available using USB disk encryption for Unraid so that the authentication (and unlocking) happens when the system starts, but that is a different technical league to accomplish as well in Unraid.

 

And all this may sound paranoid, but since Snowden paranoia is now reality I guess So whatever can be done to increase security should be done imho.

[tr0910]

It will be interesting to see what level of interest this generates. I agree that more security would be a good thing,

The current limitation forcing all array and unassigned disks to use the same encryption key might be higher priority to fix.

Especially unassigned drives would benefit from supporting different encryption key files.

Sent from my chisel, carved into granite

[ken-ji]

On 4/27/2019 at 9:04 PM, MichaelAnders said:

Additionally, these configuration files store information on the shares regarding the "security" levels. An attacker just needs to pull out the USB stick and change the shareSecurity from private to public, reinsert the USB stick and then has access to the share. That is considered an Integrity vulnerability which allows the attacker to delete/change/add (maybe illegal stuff) data on the encrypted share (even the flash disk allowing covering up any changes made) which could even get the user into a lot of trouble when user unlocks his disks and finds a surprise there...

 

A server reboot will be necessary after unplugging the USB stick from a live system, in which case the disks are now encrypted and awaiting proper key input.

The attack vector is a bit long winded and will probably be a very directed attack. Additionally, this already means the knowledgable attacker is on premise and on hand to the server. I don't know if the typical user warrants such a level of security, but I guess its possible to wrap the entire USB boot process with an optional mini encrypted disk image on the USB drive. 

I can definitely guess that Limetech cannot afford such a development direction, unless they have a number of enterprise customers and support contracts lined up for the resulting security featured product (as the resulting encryption makes it difficult for normal users to fix any issues)

 

Personally, I'd rather store the usb boot drive inside the server chassis (physically hardlocked with necessary alarms) which mitigates the perceived attack vector.

 

[MichaelAnders]

22 hours ago, ken-ji said:

A server reboot will be necessary after unplugging the USB stick from a live system, in which case the disks are now encrypted and awaiting proper key input.

I guess you are refering to the Integrity of the files on the disks? That is just one of the two problems I see here. Plus, any server "can" reboot for some reason right? So if I wanted to attack such a system, I'd press the button, pull the USB stick, adjust it, reinsert it and let the user press the button again. He'll never know I did anything...

 

22 hours ago, ken-ji said:

The attack vector is a bit long winded and will probably be a very directed attack. Additionally, this already means the knowledgable attacker is on premise and on hand to the server.

 

Correct. Such "local" attacks are one attack vector. Using local and my above assumptions I get a security related CVSS rating of ~ 6.1, which is "medium". Still, if you look at other security updates which have been released e.g. by Microsoft, they also sometimes include local access to the system. Still the publish fixes for the vulnerabilities.

 

22 hours ago, ken-ji said:

Personally, I'd rather store the usb boot drive inside the server chassis (physically hardlocked with necessary alarms) which mitigates the perceived attack vector.

And that is in my opinion way over the top. I don't want to fiddle around with my hardware as the vulnerabilities can be solved in software.

 

22 hours ago, ken-ji said:

I guess its possible to wrap the entire USB boot process with an optional mini encrypted disk image on the USB drive. I can definitely guess that Limetech cannot afford such a development direction, unless they have a number of enterprise customers and support contracts lined up for the resulting security featured product (as the resulting encryption makes it difficult for normal users to fix any issues)

That is an option, but takes a lot of development effort. That's why I suggest to rather just encrypt the attackable files on the USB disk which can be easily tampered with as a first step of reducing the attack vector.

Of course it would be possible for Limetech to create a disk creator similar to what other Linux distros use, allowing the user to set up an encrypted (USB) boot disk which can then also automatically unlock all other disks. Not sure if that would work for Unraid due to the limitations which I believe exist regarding the USB stick & license key, but maybe I'll give it a shot to set up an encrypted USB boot disk which then boots Unraid without any possible tampering.

[ken-ji]

1 hour ago, MichaelAnders said:

I guess you are refering to the Integrity of the files on the disks? That is just one of the two problems I see here. Plus, any server "can" reboot for some reason right? So if I wanted to attack such a system, I'd press the button, pull the USB stick, adjust it, reinsert it and let the user press the button again. He'll never know I did anything...

Well that depends on the security consciousness of the user, since if the physical security was really important, he'd have the usb drive locked away and/or have a CCTV monitoring the server.

1 hour ago, MichaelAnders said:

And that is in my opinion way over the top. I don't want to fiddle around with my hardware as the vulnerabilities can be solved in software.

It is less way over the top then having to have USB boot disk encryption. Why? Any plain Joe with the right hardware - ie a lockable server chassis (or small padlock + regular chassis and a drill) and correct motherboard (or optional parts) can easily install the boot flash drive in the chassis and lock the chassis (+ the rack while you are at it) and be better secured than if the system had an encrypted USB which upon failure or error might render your entire config non-recoverable (of course you have backups)... Any plain Joe can unlock same system, take out the USB to check the filesystem for corruption or replace, and lock it back in.

1 hour ago, MichaelAnders said:

Of course it would be possible for Limetech to create a disk creator similar to what other Linux distros use, allowing the user to set up an encrypted (USB) boot disk which can then also automatically unlock all other disks. Not sure if that would work for Unraid due to the limitations which I believe exist regarding the USB stick & license key, but maybe I'll give it a shot to set up an encrypted USB boot disk which then boots Unraid without any possible tampering.

It would work (licensing is tied to the physical USB not the partition/filesystem) but the encrypted USB would require the server have a console attached or support IPMI (Mine is headless and I do not have IPMI support). Current drive encryption does not require this, as the Web UI can be used to mount the drives, or the keyfile be fetched from a nearby local device (even on the network) before the Unraid core process is started up, neither can be done if your USB is encrypted.

Edited April 30, 2019 by ken-ji

[repomanz]

I can see both sides of this discussion and what risk is appropriate for unraid's primary audience.   Personally I like the idea of encrypted usb within this process, just to keep the file systems all encrypted.  As a side note; I'd like my unraid to boot needing both the usb boot device but also a yubikey.

 

What about a docker container escape writing to the usb drive?  My understanding is once the array is booted up, the file systems can be read/write which includes the boot usb device.

 

[chrispeddler]

Hi. Newbie here. I am learning upon reading your insights here about security and encryption. I'm just wonedering...if an attacker uses USB stick to encrypt..then you can lock USB ports, right?...or i might be throwing a wrong idea...