LUKS password stored in plaintext at /root/keyfile


BennTech

Recommended Posts

I just came across the file /root/keyfile that stores my LUKS drive encryption password in plaintext. Why??!? I am not using a keyfile; I am using a password only. I thought that password was secure only to find it written out in plaintext on my server. This is a huge security hole. I tried deleting the file, but it is recreated on each startup.


Why would Unraid store the LUKS password in a plaintext file? Why store it all? Why not just keep it exclusively in memory? Most importantly, HOW DO I PREVENT /root/keyfile FROM BEING CREATED AT EACH STARTUP?

  • Haha 1
  • Upvote 1
Link to comment
5 minutes ago, BennTech said:

I just came across the file /root/keyfile that stores my LUKS drive encryption password in plaintext. Why??!? I am not using a keyfile; I am using a password only. I thought that password was secure only to find it written out in plaintext on my server. This is a huge security hole. I tried deleting the file, but it is recreated on each startup.


Why would Unraid store the LUKS password in a plaintext file? Why store it all? Why not just keep it exclusively in memory? Most importantly, HOW DO I PREVENT /root/keyfile FROM BEING CREATED AT EACH STARTUP?

The location /root IS in RAM.    Whether that is a good location to store it while the server is running Is not something I can comment on since I do not use encryption.

Link to comment
58 minutes ago, itimpi said:

The location /root IS in RAM.    Whether that is a good location to store it while the server is running Is not something I can comment on since I do not use encryption.

I understand /root is in RAM, but it is still setup as a file system and is accessible via simple built-in commands. Even someone who has never used Linux before can obtain the LUKS password in 2 seconds with a simple "cat /root/keyfile" and BAM! LUKS password displayed and entire array encryption compromised.

Link to comment
18 minutes ago, BennTech said:

I understand /root is in RAM, but it is still setup as a file system and is accessible via simple built-in commands. Even someone who has never used Linux before can obtain the LUKS password in 2 seconds with a simple "cat /root/keyfile" and BAM! LUKS password displayed and entire array encryption compromised.

Have a read here. This has been discussed many times in the past.

https://forums.unraid.net/topic/61973-encryption-and-auto-start/

 

Link to comment
1 minute ago, jonathanm said:

Have a read here. This has been discussed many times in the past.

https://forums.unraid.net/topic/61973-encryption-and-auto-start/

 

That's entirely different. I do NOT "autostart" my array with a keyfile. As I said, I use ONLY A PASSWORD, not a keyfile. I specifically enter my LUKS password after each boot. That password should be secret. Unfortunately, Unraid then stores that secret password in plaintext on the system.

Link to comment
1 minute ago, jonathanm said:

If you would have read the thread, they discuss deleting the file after the array has been started.

My question still stands: WHY IS UNRAID STORING MY SECRET PASSWORD IN PLAIN TEXT? If I am not using a keyfile, then why do I have to delete a keyfile every time I start the array? So now I not only have to enter the password, I have to remember to delete the keyfile as well even though I don't use one? And I should add that it needs to be securely deleted by overwriting with random/cryptographic data to prevent data leakage.

 

And how many other Unraid users have their key exposed and don't know about it because they never poked around? LUKS is very secure, but Unraid effectively makes it completely insecure by publishing the password. In fact, I dare to say it's even worse than no security because it gives users a false sense of security, thinking their data is protected and lets them relax on other security measures when in fact their password is actually published in clear text. It's not a hash. It's not salted. It's the password stored in a plain text file with the blatant name "/root/keyfile". It's the equivalent of a password written on a Post-It note and stuck on your monitor.

 

How is this not a big deal to people? This is a HUGE security flaw that basically negates LUKS entirely.

  • Like 3
Link to comment

To unlock the LUKS encryption a password or keyfile is used. In both cases the information must be stored in a file under /root to allow Unraid to start and unlock the encryption after the array is started.

 

Once the array is started the file under /root is not needed anymore (until the array is restarted) and may be deleted. The GUI offers this choice.

Or you can make use of scripts which automatically delete the file once the array is started.

 

Remember that this file is NOT ACCESSIBLE by any regular users nor remotely accessible. Also it lives in RAM and is NOT PERMANENTLY stored (rebooting the system or power off the system will make the file non existing).

 

In short there is NO SECURITY FLAW.

  • Haha 1
  • Upvote 1
Link to comment
7 hours ago, bonienl said:

To unlock the LUKS encryption a password or keyfile is used. In both cases the information must be stored in a file under /root to allow Unraid to start and unlock the encryption after the array is started.

 

Once the array is started the file under /root is not needed anymore (until the array is restarted) and may be deleted. The GUI offers this choice.

Or you can make use of scripts which automatically delete the file once the array is started.

 

Remember that this file is NOT ACCESSIBLE by any regular users nor remotely accessible. Also it lives in RAM and is NOT PERMANENTLY stored (rebooting the system or power off the system will make the file non existing).

 

In short there is NO SECURITY FLAW.

 

bonienl, you helped me out with jumbo frames affecting Unassigned Devices, and I appreciate that. But you are absolutely wrong here. Storing a secret password in a plaintext file is a HUGE SECURITY FLAW.

 

Not accessible by any regular users? So Unraid and its underlying Slackware OS is 100% free of all exploits and privilege escalation? All Unraid plugins and apps and dockers are likewise 100% free of all exploits and privilege escalation?

 

Let's be clear: NO SYSTEM IS 100% SECURE. Even LUKS can be bruteforced. The point is to make it as difficult and time-consuming as possible, something that is so unreasonable it's not worth the effort, like thousands of years to bruteforce the LUKS AES encryption. Thus, the attack vector is usually the much simpler user password that produces the full AES key. If you don't understand why storing passwords in plaintext is bad, research the RockYou breach. 32 million user passwords dumped because they were stored in plaintext. That password list is so popular that it's included in Kali Linux. To avoid things like that, passwords should be stored as hashes, not plain text. However, there are hash tables that instantly convert hashes to text. Thus, to make cracking more difficult, passwords are usually "salted" before hashing. Thus, an attacker would need to determine the salt, then bruteforce the password. Still crackable, but with long and complex passwords, it could take hundreds of years. Mission accomplished--not worth the effort.

 

I have a ridiculously long and complex password. Again, I am not using a keyfile like a lot of people do to implement the inherently insecure "autostart". Instead, I am using a SECRET password that Unraid then makes available to everyone INSTANTLY.

 

OK, fine, it's available only to root. And also available to every exploit and privilege escalation that can get root access. And let's not forget that the Unraid WebGUI and terminal REQUIRE ROOT. No other account can access those, so anyone who needs to do anything on Unraid, even just to check the status of a parity check, requires the root account. Thus, everyone who needs to administer Unraid has to share the same root account. Let's gloss over that security flaw and focus on the fact that that means everyone--regardless of how trivial their task is--has access to the Unraid LUKS password.


And it's not just the Unraid server or root account that can be compromised. After finishing in the WebGUI, did the Unraid admin (i.e., root) click the obscure little "Logout" icon? No? BAM! Access to the plaintext LUKS password. You don't even need to know the root password in this case, but if you want it, check out tools like LaZagne. How about social engineering? BAM! Access to the plaintext LUKS password. Exploits and privilege escalation? BAM! Access to the plaintext LUKS password.

 

And yes, I've seen the option in the WebGUI to delete the encryption keyfile. But since I don't use a keyfile, I shouldn't need to delete a keyfile, right? And that idea is further supported by the fact that the Delete button is disabled. It's only when I click the obscure checkbox in the other column to indicate "Yes I want to do this" that the Delete button is then enabled. So what exactly am I about to do? Like I said, I don't use a keyfile, just a password. So to me it looks is this a way to delete the AES keyfile stored on the drives. And yes, deleting the primary encryption key is an option in many disk encryption software, including LUKS. That's essentially an unrecoverable loss of encrypted drives, and hence the obvious need for the checkbox verification before the Delete button is even enabled, and hopefully a supplementary "Are you sure? Type YES to confirm" dialog. But I wouldn't know because I never got that far because I don't use a keyfile! The WebGUI is unclear what any of this does, and I sure as hell don't want to click a button that possibly makes my encrypted data permanently inaccessible. I infer from your description that that is not the case and that it just deletes the keyfile THAT SHOULDN'T EVEN EXIST, but how are we supposed to know that? Nowhere have I found Unraid mentioning that it stores your secret password in plaintext in the file system. So why would I or anyone else using Unraid LUKS with only a password even know that this keyfile exists and that we need to delete it?

 

And as I said previously, since the password is written in plaintext, it needs to be securely deleted with a tool like "shred" or "wipe". Is that what the WebGUI is doing? I don't know, but I am skeptical based on LimeTech's nonchalant security practices that I've already uncovered here. And frankly, no one should have to worry about any of this because our passwords should NOT be written in plaintext to a file.

 

And I don't care if it only "lives in RAM". It's not like it only exists in the decrypting app's internal memory--hopefully obscured and requiring complex tools and skill to obtain. Instead, that RAM is setup as a file system, and anytime the server is running, the clear text password is accessible with the basic tools built into the operating system. No special skills or tools needed.

 

LUKS does not require its password stored in plaintext in the file system. This is clearly a sloppy LUKS implementation by LimeTech that is compromising the security of their users. Why store the password at all? Apparently it's not needed after boot, so why isn't LimeTech deleting it by default? And if they're going to store it, why store it in plaintext? Whoever implemented this at LimeTech has no understanding of basic security and consequently LimeTech is putting all of their LUKS users' encrypted data at risk. Unacceptable.

  • Like 2
Link to comment
14 minutes ago, BennTech said:

And yes, I've seen the option in the WebGUI to delete the encryption keyfile. But since I don't use a keyfile, I shouldn't need to delete a keyfile, right? And that idea is further supported by the fact that the Delete button is disabled.

Aside from you actually being correct, for many reasons, this keyfile is created so that you don't have to type your password in for every single LUKS disk in your array. Ideally, a few things should change with this part of the system.

Allow me to point out an assumed security that is incorrect from people in the thread thus far:

"It's in /root, so it's only available to the root user" - this is wrong for a couple of reasons; for one, this relies on no docker's being configured in such a way that they cannot see "/root" as any docker that uses a root account would also have access to this file. Furthermore, any bootable distribution, or hypervisor would also have access to this file (though it is detroyed every shutdown) Furthermore, the file is both plaintext, and stored in memory. Anything that manages to gain access to memory (We have several major vulnerabilities right now that affect different hardware and software implementations that allow access to the memory map, even to protected regions) can see this password. All of this assumes that simple privilege escalation attacks aren't viable (which they have been, in recent times, even.)

In 2019, the only time a key should be plaintext is at the moment it is used. After that the variable it is contained in should be overwritten and destroyed. We must overwrite it because the kernel will simply mark that region "free" rather than writing 0's to it. Sure, it takes microseconds for it to be overwritten after being marked free on a system that has high memory utilization, but that's time it's available. We want to destroy the variable so there is no reference to it to make it identifiable after we use it.

Furthermore, while it *is* convenient to have a single password for all of the disks - this is not ideal. Ideally (Imho) Unraid should generate a salted and hashed key from the user-defined luks password for each drive. You have two sources of unique data for each disk: The unraid license key, and the disk serial number. Using the license key ensures that no two unraid users can end up with the same salted key - even if they choose the same password and somehow have two disks with the same serial number. These salted keys should be generated based on the user's input and each disk should have its own unique key to mount it. This greatly increases the security of the system against brute force attacks.

Edited by Xaero
  • Like 3
Link to comment

Sorry if I don't agree with your explanation/example using Docker but it's because You can't fix Stupid. If people are going to do Stupid things, they'll always find a way. The same Stupid will have the LUKS password/phrase written down on a Sticky Note by the Keyboard. They probably have it backed up to the cloud in a publicly readable container too.

Link to comment
2 minutes ago, BRiT said:

Sorry if I don't agree with your explanation/example using Docker but it's because You can't fix Stupid. If people are going to do Stupid things, they'll always find a way. The same Stupid will have the LUKS password/phrase written down on a Sticky Note by the Keyboard. They probably have it backed up to the cloud in a publicly readable container too.

I wholely agree that you cannot fix stupid. But you can implement things in a way that take stupidity into consideration. This specific instance is capable of being mitigated by implementation. If you can implement mitigation you should.

  • Upvote 1
Link to comment

Thank you, Xaero. Finally someone who gets it.

 

I will say this in defense in LimeTech. LUKS is relatively new for them, and they plan on adding features in future versions, like allowing multiple keys (something that is already built-in to LUKS, but currently has to be done manually with cryptosetup).

 

That said, I think LimeTech should keep a single password for the whole array. I shouldn't need to enter a different password for every drive in my array--that can get unwieldy. And salting the password with the license key or drive serial doesn't add much security since those are available both inside and outside Unraid. Worst of all, that would make my LUKS drives inaccessible in other LUKS-compatible systems because of some Unraid-proprietary manipulation of my password. That's one of the reasons I like both Unraid and LUKS--if my server crashes or I chose to stop using Unraid, I can plug my drives into virtually any other Linux system and access all my files.

 

What SHOULD happen--and I don't know if Unraid is doing this or not--is the AES key should be randomly generated for each drive. With LUKS, the shorter user password unlocks the huge AES key, and it's that AES key that encrypts/decrypts the drives. Each user password has its own copy of that AES key. If you give someone a single drive from your array with their unique password, they now have access to the AES key. So the security hole is that if the Unraid array uses the same AES key for all your drives, they now have the key to all your drives from that single one that you gave them. Again, I don't know whether LimeTech uses different AES keys for every drive or not. I certain hope each drive has its own unique, randomly-generated AES key.

 

That's getting nit picky and a little off-topic, and frankly I don't care too much about all that right now. I'm more concerned about the blatant security flaw of my password being saved in plaintext to a file.

 

You're absolutely right about everything else you said. I am well aware of all the other flaws you mentioned, but I didn't bother going into to those details because I can't even convince these people that saving the array password in plaintext to a file is BAD BAD BAD. Thus, they clearly won't have a clue or even care about Meltdown, Spectre, or Use After Free vulnerabilities. And frankly, none of those are even necessary since the PASSWORD IS MORONICALLY STORED IN PLAINTEXT TO A FILE and left there for all to see. Seriously, people...WTF?

 

"If you can implement mitigation you should." <<< YES! YES! YES!

  • Like 1
  • Upvote 1
Link to comment
22 minutes ago, BennTech said:

Thank you, Xaero. Finally someone who gets it.

 

I will say this in defense in LimeTech. LUKS is relatively new for them, and they plan on adding features in future versions, like allowing multiple keys (something that is already built-in to LUKS, but currently has to be done manually with cryptosetup).

 

That said, I think LimeTech should keep a single password for the whole array. I shouldn't need to enter a different password for every drive in my array--that can get unwieldy. And salting the password with the license key or drive serial doesn't add much security since those are available both inside and outside Unraid. Worst of all, that would make my LUKS drives inaccessible in other LUKS-compatible systems because of some Unraid-proprietary manipulation of my password. That's one of the reasons I like both Unraid and LUKS--if my server crashes or I chose to stop using Unraid, I can plug my drives into virtually any other Linux system and access all my files.

 


It does prevent compromising the entire array by discovering the key to one disk. If they implemented a system like this, they obviously would need to use a cipher system to generate the keys. This cipher system could need to have a "recovery" mode where if you are able to provide the full set of data it would be able to provide you with a luks keyfile to recover the data from the disk. This wouldn't break compatibility with existing luks systems, but would prevent an attacker from compromising the entire array if a single key is somehow exposed.
 

Link to comment

First a great deal of thought, design, and effort went into the Unraid OS encryption feature.  However we do think there are improvements we should make in the interest of securing the server as much as possible.

 

To clear some things up:

  • If you use a passphrase, whatever you type is written to /root/keyfile
  • If you upload a key file, the contents of that file are written to /root/keyfile
  • Hence we always pass "--key-file=/root/keyfile" to cryptsetup when opening encrypted volumes.

The Delete button action is to delete /root/keyfile.  I can see where this leads to confusion in the UI.

 

/root/keyfile is definitely not automatically recreated up system boot, but it is needed every time you Start the array if there are encrypted volumes.  You only see the passphrase/keyfile entry fields if /root/keyfile does not exist, which is the case upon reboot.

 

The default action, after luksOpen'ing all the encrypted volumes is to leave /root/keyfile present.  This is because often, especially during initial configuration, one might Start/Stop array several times and it's a pain in the neck to have to type that passphrase each time.

 

At present unlike traditional Linux distros, Unraid OS is essentially a single-user system (root) on a trusted LAN (your home).  Thus we didn't think there was much risk in leaving /root/keyfile present, and besides there is a way to delete it, though granted you have to remember to do so.

 

The primary purpose of encryption is to safeguard against physical theft of the storage devices.  Someone who does this is not going to know to first snoop in a webGUI and find an encryption key - they are going to grab the case and run.

 

Each storage device has its own unique volume (master) key.  The keyfile is used to decrypt this master key, and its the master key that is actually used to encrypt/decrypt the data.  Unraid uses only one of possible 8 slots.  We intend to add the ability to assign additional passphrases, for example to change your passphrase, or to add another one if you want to give someone else a storage device and not reveal your unique passphrase.  But of course this is very easily done with a simple command.

 

Having read through the topic, we will make these changes:

  • Change the default action of array Start to shred /root/keyfile after opening all the encrypted volumes.
  • Add an additional configuration variable, probably under Settings/Disk Settings to change this default action if someone wants to, with clearer help text that explains what's happening (though the current Help text does explain it).
  • Add the ability to change the passphrase.

 

  • Like 7
  • Haha 1
  • Upvote 3
Link to comment
38 minutes ago, limetech said:

First a great deal of thought, design, and effort went into the Unraid OS encryption feature.  However we do think there are improvements we should make in the interest of securing the server as much as possible.

 

To clear some things up:

  • If you use a passphrase, whatever you type is written to /root/keyfile
  • If you upload a key file, the contents of that file are written to /root/keyfile
  • Hence we always pass "--key-file=/root/keyfile" to cryptsetup when opening encrypted volumes.

The Delete button action is to delete /root/keyfile.  I can see where this leads to confusion in the UI.

 

/root/keyfile is definitely not automatically recreated up system boot, but it is needed every time you Start the array if there are encrypted volumes.  You only see the passphrase/keyfile entry fields if /root/keyfile does not exist, which is the case upon reboot.

 

The default action, after luksOpen'ing all the encrypted volumes is to leave /root/keyfile present.  This is because often, especially during initial configuration, one might Start/Stop array several times and it's a pain in the neck to have to type that passphrase each time.

 

At present unlike traditional Linux distros, Unraid OS is essentially a single-user system (root) on a trusted LAN (your home).  Thus we didn't think there was much risk in leaving /root/keyfile present, and besides there is a way to delete it, though granted you have to remember to do so.

 

The primary purpose of encryption is to safeguard against physical theft of the storage devices.  Someone who does this is not going to know to first snoop in a webGUI and find an encryption key - they are going to grab the case and run.

 

Each storage device has its own unique volume (master) key.  The keyfile is used to decrypt this master key, and its the master key that is actually used to encrypt/decrypt the data.  Unraid uses only one of possible 8 slots.  We intend to add the ability to assign additional passphrases, for example to change your passphrase, or to add another one if you want to give someone else a storage device and not reveal your unique passphrase.  But of course this is very easily done with a simple command.

 

Having read through the topic, we will make these changes:

  • Change the default action of array Start to shred /root/keyfile after opening all the encrypted volumes.
  • Add an additional configuration variable, probably under Settings/Disk Settings to change this default action if someone wants to, with clearer help text that explains what's happening (though the current Help text does explain it).
  • Add the ability to change the passphrase.

 

FYI, cryptsetup supports piping the keyfile via stdin:

echo "securestring" |  cryptsetup --key-file=- ...

Edited by Xaero
Link to comment
3 minutes ago, Xaero said:

FYI, cryptsetup supports piping the keyfile via stdin:

echo "securestring" |  cryptsetup --key-file=- ...

You think I don't know that?  That handles passphrases but not actual key-files.  Besides the plaintext is sitting around in RAM in other places too, eg, in network stack buffers.

  • Like 1
Link to comment

Thanks, limetech, for your thorough answer.

I have to reiterate that I still don't want my password written in plaintext to disk. This reduces security by unnecessarily introducing an additional attack vector. Now my secret password is not just vulnerable to keyloggers, shoulder surfing, etc., but also to all the vulnerabilities of a keyfile. Yes, the password is also available in memory, network buffers, etc. But to retrieve it from those locations requires precise timing and more skills than most computer-literate users possess. Again, no system is 100% secure, so this is about making it too difficult to be worth the effort, and files are ridiculously easy to obtain, even by my computer-illiterate 75-year-old mother. I'm confident that I could teach her how to get the password from the plaintext keyfile in a few minutes, but I don't think I could ever teach her how to grab the password from a network buffer. As I said and Xaero provided an example, LUKS does not require writing the secret password to a file. To me, this looks like lazy programming so Unraid can use the same unlock method for either a keyfile or a password.

 

And Xaero, I'm still not on board with your idea for different keys per drive. If it's formulaic, like salting with the license key or drive serial, that can be easily replicated. If you're relying on a cipher system, you're adding another attack vector (the cipher system, its recovery mode, its formula, its storage method, etc.), which I should note will be written by the same company that thinks it's OK to write passwords in plaintext to the file system. No thank you. Plus, I would much rather know the exact password(s) to my encrypted drive than to rely on the added complexity and insecurity and incompatibilities of an external program.

 

A potential solution could be that when LimeTech implements multiple keys. Assuming they allow users to assign unique keys per drive (e.g., so you can hand over a single drive to someone), that could be used to optionally leverage multiple passwords to start the array. This is tricky to implement because most people will want the same password for all drives and will not appreciate having to repeatedly type the same password for every drive in their array. They'll want one blank to enter one password. So how do you implement multiple passwords without frustrating the majority of users? Maybe try that one password on each drive, and prompt for an additional password if that one doesn't decrypt all the drives, then repeat until all drives are decrypted. (It would only take a few seconds to check even for a huge array.) Or maybe a multi-line text box to enter a different password on each line, then try each password on each drive until one decrypts it. Also, these techniques allow for one set of drives all containing related information to be keyed with the same password, and another set to be keyed with a different password. All certainly possible, but all depends on how LimeTech implements multiple keys.

  • Like 2
Link to comment
1 hour ago, BennTech said:

I have to reiterate that I still don't want my password written in plaintext to disk.

It's not written to any permanent storage, it's written to a file in the root file system which is in RAM.

 

1 hour ago, BennTech said:

Now my secret password is not just vulnerable to keyloggers, shoulder surfing, etc., but also to all the vulnerabilities of a keyfile.

Your "secret password" is only to decrypt the drives - even if the password were leaked somehow they still need the physical drives to make use of it.

 

1 hour ago, BennTech said:

I'm confident that I could teach her how to get the password from the plaintext keyfile

You'll first have to teach her to hack your root login password in order to get into your server.

 

As @bonienl mentioned in above post we have made some changes so that casual user doesn't accidentally leave a keyfile laying around.  These will appear in Unraid OS 6.8 release.  In meantime, click that 'Delete' button after Starting array

 

1 hour ago, BennTech said:

To me, this looks like lazy programming

and, I'm done talking with you.

  • Haha 1
  • Upvote 5
Link to comment

Oof, this got blown out of proportion.

 

First of all, thanks to @limetech for even introducing encryption support, this helps us ensure our data cannot be recovered (whenever the RMA'd drives get re-purposed) and continuing to support and enhance its functionality.

 

@BennTech Let's be mature about this. Your feedback is of course appreciated, but it needs to be constructive. I see that you have some knowledge in the infosec world and that's great, but please, don't be so condescending on the devs.

 

I am sure you are not sitting behind a pfsense with IDS and IPS configured (such as suricata, snort or even sophos utm) and you are not writing your own snort custom rules either. Your laptop is not running Qubes OS with segregated domains for your personal emails, social media and work related access. You are not using FIDO2/U2F for MFA nor are you using GnuPG for secure communication. And if you are, hats off to you good sir.


Regarding LUKS, I am sure you have seen this: https://0x00sec.org/t/breaking-encryption-hashed-passwords-luks-devices/811  (Nothing is bulletproof)

 

Additionally before bashing on devs, they do take security very seriously. Just look at the security sub-forum.

 

Security is a shared responsibility and you are the one who is also responsible for ensuring your system is configured in a secure way as well as your environment. Yes, your environment as well.

 

If we are talking about security practices then there are many security controls you can implement:

- Disable services you do not need, you don't have to run any dockers, just use storage

- Don't expose unraid or its services externally

- Implement fail2ban to prevent bruteforces

- Run your vulnerability assessments and manage it (OpenVAS/Nessus)

- Rotate your passwords every 30 days

- Randomly generate your passwords with at least 24 characters

- Use VLANs to segregate network traffic

- Don't use lower versions of SMB

- Don't use NFSv3

- Lock down physical access to the server

- Install Video Cameras

- Review access logs

- Disable IPMI if you are running supermicro

- Disable hyperthreading if you are running intel chips

- Don't use unecrnypted connections (http), instead use nginx as a reverse proxy for encrypting all traffic (certs required)

- Setup centralized logging using rsyslog to splunk or elasticsearch (ELK)

- Setup appropriate auditing accessing the filesystem and triggers

- And many others

 

If you work in infosec then you should know about risk assessments and risk management as well as how convenience and security comes clashing when you need to implement BCP (Business Continuity Planning) once your BIA (Business Impact Analysis) is done.

 

You've raised a valid point that convenience in this case should be optional and @limetech agreed to address it in the follow-up release.

 

But are you that paranoid that you don't trust the way you setup your internal network, do you not have enough traffic filtering setup to spot a data extraction operation through an ICMP or a DNS tunnel? Judging by your comments, you are a pro at this ;) 

 

In either case, let's improve things. Everybody can be a critic, remember that.

 

And remember, if somebody wants to pwn you - they will, there is always a way.

Edited by ezhik
  • Like 1
Link to comment
20 minutes ago, ezhik said:

Oof, this got blown out of proportion.

Yeah, you're right. This did get blown out of proportion.

 

This is what LimeTech representatives SHOULD do when an Unraid customer reports a security flaw:

  1. Acknowledge the customer's concern.
  2. Acknowledge the security flaw.
  3. Describe the steps being taken to correct the issue.
  4. Thank the customer for reporting the flaw so LimeTech can continue to improve and secure their product.

The only part has happened is #3. However, even in their "fix" LimeTech doesn't acknowledge that they are going to stop writing a plaintext password to a file. Quite the opposite--their fix is to shred the keyfile, so apparently they're still dumping the password to a file.

 

1 hour ago, ezhik said:

Let's be mature about this. Your feedback is of course appreciated, but it needs to be constructive. I see that you have some knowledge in the infosec world and that's great, but please, don't be so condescending on the devs.

I've offered several constructive ideas and solutions. I've thanked multiple people in this thread, including multiple devs. Has anyone thanked me for bringing this security flaw to light? What is it that I said that is so condescending? That it's lazy programming to save a plaintext password to a file? IT IS. Meanwhile, the devs have dismissed my concerns this entire thread. They have refused to acknowledge that saving a plaintext password to a file is insecure and have even denied that there is a security issue at all, with excuses like it's a RAM drive, or that you can delete the keyfile (that users don't even know exists). Is that constructive? How is dismissing a customer's valid security concerns like they don't matter NOT condescending? It is, and devs have done that to me multiple times in thread. So why don't you get onto the devs for being condescending to their customers?

 

I am offended by the way LimeTech and everyone else in this thread other than Xaero has repeatedly dismissed all my concerns, and I feel I'm owed an apology in addition to a thank you for pointing out this security flaw. I'm not so naive as to think that anyone, especially from LimeTech, is going that. Instead, I'll just have to settle for them fixing the issue (sort of), which is at least an acknowledgement that saving a plaintext password to a file is insecure even though they never actually admit it.

 

BTW, yes, I actually do run pfSense with Snort--I've been using it for 14 years since v0.9.8 when it forked off m0n0wall. No, I don't run Qubes--my work/clients require Windows, but I do run a Kali VM to perform basic PenTesting at my clients. Yes, I do know about LiME to grab passwords from memory and had started to include it in a previous response but removed it because what's the point in all that if I can't even convince any of the devs that saving a plaintext password to a file is bad.

 

And to all the LimeTech devs, even though you never said thank you, you're welcome. Assuming you implement the changes described by limetech above, you and all your users will soon enjoy a better and more secure Unraid thanks to me bringing this security flaw to your attention.

  • Like 1
  • Haha 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.