Security Loophole

gmoy8888 · Post by **gmoy8888** » 30 Apr 2014 23:20

I just installed NAS4Free and wanted to integrate it with my Windows Active Directory for authentication. The NAS4Free AD setup required my domain administrator password. I was reluctant to type it in because I wasn't sure what NAS4Free would do with the password (and whether it would be kept safe). Unfortunately, I was shocked and deeply disappointed when I found my password in plain text in NAS4Free's config.xml file under /conf. Moreover, all passwords (admin, local users, etc.) are stored in the clear in this file as well.

kenZ71 · Post by **kenZ71** » 01 May 2014 04:37

While the above is true the only way you can view these after logging in with the admin account.

gmoy8888 · Post by **gmoy8888** » 01 May 2014 07:16

I don't need the admin login. I can easily mount the disk partition on another OS installation and read the config.xml file.

armandh · Post by **armandh** » 01 May 2014 13:07

hardware access required

as with any security once there is hardware access all bets are off
but it might be nice to employ internally mounted flash to avoid a walk by grab of the config.

Post by **b0ssman** » 01 May 2014 13:22

i can also use this 5 dollar wrech to hit you over the head with until you tell me the password.

http://xkcd.com/538/

Post by **apollo567** » 01 May 2014 14:04

b0ssman wrote:i can also use this 5 dollar wrech to hit you over the head with until you tell me the password.

http://xkcd.com/538/

lol - well this it works always.

The open question left is, can the config.xml file be accessed from network/internet or not. Only a way which allows this can be considered a security loophole where the developers would have to think about.
Hardware access is something N4F can't grant protection against .

gmoy8888 · Post by **gmoy8888** » 01 May 2014 14:58

I really can't think of any other current operating system which stores all account passwords in clear text without warning and without an option for encryption. Particularly alarming is that NAS4Free considers this the proper way to handle the domain administrator password.

For half the price of a $5 wrench, we can get a knife and take someone's wallet, car keys, ATM PIN, etc.

Post by **apollo567** » 01 May 2014 15:09

gmoy8888 wrote:I really can't think of any other current operating system which stores all account passwords in clear text without warning and without an option for encryption. Particularly alarming is that NAS4Free considers this the proper way to handle the domain administrator password.

For half the price of a $5 wrench, we can get a knife and take someone's wallet, car keys, ATM PIN, etc.

Well, N4F is a 'special purpose' OS stripped from many not needed Parts of FreeBSD to peform one specific taks : operating an NAS.
So the question is really, is there loophole in the software which allows an attacker to access this file without permission, if you leave away the danger/possibility of physical access....

Post by **crowi** » 01 May 2014 15:31

@b0ssman LOL

I really can't think of any other current operating system which stores all account passwords in clear text

Ohhh, I can think of some of them
Boot any windows machine with e.g. HBCD and you can change the passwords.
Boot any windows machine with syslinux or a LiveLinux and and you have full access to any data stored on the machine.
Although probably not clear text password stored, you even don't need the wrench to get access

Post by **b0ssman** » 01 May 2014 15:43

yes with physical access to the machine you can do anything.

change the windows password from linux

http://www.howtogeek.com/howto/windows- ... rescue-cd/

Post by **crowi** » 01 May 2014 17:29

So, back to the security loophole:

I am not happy with clear text passwords, but a sysadmin of a N4F machine, creates the shares, the users and the groups anyway and knows the passwords. The config file shouldn't be accessible for standard users and thus a copy of it shouldn't be stored on a public share, of course.
In an office environment, the server should also be placed in a locked rack anyway, which again should be placed in a locked server room.

gmoy8888 · Post by **gmoy8888** » 01 May 2014 21:19

Boot any windows machine with e.g. HBCD and you can change the passwords.
Boot any windows machine with syslinux or a LiveLinux and and you have full access to any data stored on the machine.

None of the scenarios mentioned here allows you to either get the original password or change it to a password of your choosing. You can change or destroy the password's one-way hash which prevents the user from logging in again -- that's all.

A not-so-far-fetched security breach is when a janitor (or someone pretending as one) walks into my office, plugs in his USB flash drive, boots into his OS, and gets my company's domain admin login. In less than 20 seconds, he gets full access to everything without anyone even noticing.

Post by **crowi** » 01 May 2014 21:34

Only if he boots your server which really should be locked or if you stored the config file on your own pc.

Gesendet von meinem HUAWEI Y300-0100 mit Tapatalk

gmoy8888 · Post by **gmoy8888** » 01 May 2014 21:58

The government, for one, would not be satisfied with just physical access restrictions. We are contractually obligated to protect data breach even when physical access is compromised. Furthermore, some of our servers are hosted remotely with third parties. We are also planning cloud-based VM installations. These are scenarios in which we don't have control over the physical servers and can't trust who might gain access.

Post by **crowi** » 01 May 2014 22:03

But then you should think of a real enterprise system and not be using n4f.

Gesendet von meinem HUAWEI Y300-0100 mit Tapatalk

gmoy8888 · Post by **gmoy8888** » 01 May 2014 22:13

Here's a solution I've implemented and begun testing. The steps basically involve the following:

1. Create a full installation of NAS4Free on HDD.
2. Encrypt the data partition of the installation with GELI.
3. Copy all files from the installation partition to the encrypted data partition.
4. Change fstab to mount the newly-created encrypted partition as root paritition.
5. Change /boot/loader.conf.local to load the GELI driver into kernel and to request encryption passphrase at boot time.

Here's the tutorial I found useful: https://forums.freebsd.org/viewtopic.php?&t=19082

gmoy8888 · Post by **gmoy8888** » 01 May 2014 22:23

crowi wrote:But then you should think of a real enterprise system and not be using n4f.

This is what I read straight from n4f's home page http://www.nas4free.org/. I guessed I believed the hype

Your customized NAS4Free solution will likely be cheaper, more powerful, and more custom fit to your needs than many commercial NAS boxes.

I don't mean to be 100% critical. It's a solution that can work for me after manually converting the root partition with encryption as I mentioned in my previous post.

BrickedBox · Post by **BrickedBox** » 01 May 2014 22:26

gmoy8888 wrote:I don't need the admin login. I can easily mount the disk partition on another OS installation and read the config.xml file.

Or worse, as I do, save the backup-config files to a folder on the windows laptop I use. The admin password is in plain text and a notepad search for "admin" reveals it in a second. Do a Windows Explorer search including file contents and find it anywhere on the drive.

The saving grace for me at least, is that the drive I save that stuff to is encrypted so only I can see the plain text, but it is a bit amateurish to store ANY password in pain text at ANY time.

Post by **crowi** » 01 May 2014 22:32

This is what I read straight from n4f's home page http://www.nas4free.org/. I guessed I believed the hype

The statement is true but I and many others see n4f on SOHO level in comparison to these QNAP, Synology and Buffalo NAS boxes, not as big data and upper enterprise solution.
Here I would switch to HP, SGI, LSI or other big storage systems where you also have warranty and real support.

pirateincognito · Post by **pirateincognito** » 02 May 2014 00:28

I find this highly disturbing. With all the recent events of the NSA/Edward Snowden, heartbleed etc etc. I feel that computer security is more important than ever.

How hard would it be to change the implementation of this function of nas4free to use hashed passwords or something else that isn't plaintext.

Post by **b0ssman** » 02 May 2014 06:16

pirateincognito wrote:I find this highly disturbing. With all the recent events of the NSA/Edward Snowden, heartbleed etc etc. I feel that computer security is more important than ever.

How hard would it be to change the implementation of this function of nas4free to use hashed passwords or something else that isn't plaintext.

the problem here for example is that the accounts for samba and unix use different password algorythms.

it would be possible but you would have to write the entire routine that handles passwords again for nas4free.

Post by **crowi** » 02 May 2014 14:20

I just checked, at FreeNAS they had the same problem and it took 2 years to solve it:
It's quite interesting to read: https://bugs.freenas.org/issues/1403

- first they postponed the problem,
- then there was a statement "Looks like we can't get this fix for 9.2.0 - it's a complex issue. We agree that it's a problem (security concern) but the fix is "hard"
- then the status was moved from 'bug' to 'feature'

- and now they deployed a solution
"The ability to join Active Directory without saving the Administrator password in the database now exists via 46ae467cbff9409f55dd4167b87a7808d196d9ef. Keep in mind that you can still use Administrator username/password if you choose. If not, you can use a kerberos keytab and a less privileged account for performing the LDAP queries that are necessary (but the password still remains in the database). I consider this acceptable and am marking this ticket as resolved."
https://bugs.freenas.org/projects/freen ... 08d196d9ef

Dread · Post by **Dread** » 01 Jun 2014 23:39

In this case we're dealing with XML config files, not AD. They fixed the AD issue, but if the config file is compromised the attacker still gets a root access.

Why not use a hash of the password in the config file ? Whenever the user is prompted for the root/admin password, the input in hashed with the appropriate algorithm and if the hash equals to the one stored in the XML file, access is granted. I believe that's pretty easy to implement (some parsing, etc.).

chris.shelton · Post by **chris.shelton** » 31 Jul 2015 09:53

Has there been any progress made on this?

Is there a way around storing the user passwords in plain text in the config.xml file?

Post by **b0ssman** » 31 Jul 2015 09:58

yes the config can now be encrypted when you safe it.

chris.shelton · Post by **chris.shelton** » 31 Jul 2015 10:53

b0ssman wrote:yes the config can now be encrypted when you safe it.

But that doesn't get around that fact that the passwords are stored in plain text in NAS4Free.

Is there any way to have them permanently not in plain text?

Post by **daoyama** » 01 Aug 2015 04:34

Dread wrote:Why not use a hash of the password in the config file ?

It's simply reason.
We cannot re-create samba password without plain password.
Other password should convert to hash.
Also system(ssh and other) and samba don't not use same hash.
(filemanager used other hash in 9.3 but 10.x was changed to same hash of system)
If all hashed, you must have multiple user and hash in config.

chris.shelton · Post by **chris.shelton** » 03 Aug 2015 11:01

daoyama wrote:
Dread wrote:Why not use a hash of the password in the config file ?
It's simply reason.
We cannot re-create samba password without plain password.
Other password should convert to hash.
Also system(ssh and other) and samba don't not use same hash.
(filemanager used other hash in 9.3 but 10.x was changed to same hash of system)
If all hashed, you must have multiple user and hash in config.

So, how come FreeNAS doesn't suffer from this problem?

XigmaNAS

Security Loophole

Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole

Re: Security Loophole