Minggu, 27 Agustus 2017

NFS, no_root_squash and SUID - Basic NFS Security

I have come across many wide open NFS servers, which could be made a little more secure and safer with a couple of quick changes. This is a quick, make things a bit more secure guide. This is by no means a complete guide for securing NFS, but it can make things a little more secure without a lot of effort. To go another level you want to look at implementing NFSv4 and Kerberos.

What is root squash? 

Root squash basically remaps the root UID from 0 to an anonymous user with no privileges (usually mouser:no group). This means that root is stripped of all privileges and is not able to read any files which are not world read, or write to any paths that are restricted. 

Why do I want to enable root squash?

If you don’t a client mounting the NFS volume can have complete control of the files on the volume (modify, delete, overwrite). That sounds bad, but it gets worse, both the client and the server are vulnerable to some suid fun from a user with a bit of knowledge. 

SUID:
suid is a method of a user assuming the rights of the owner of a file when it is executed by the user. Why do I care about this? Imagine if a user was able to copy a file onto the NFS volume, enable to suid bit on the file, then run that on the NFS server or client effectively elevating themselves to root in the process? 

Here is an example demonstrating the risks.

NFS Server hostname is server, NFS client hostname is client. The subnet on the example network is 192.168.1.0/24. This example also assumes that both systems are running the same OS versions (i.e. both are RHEL 5, or both are SLES 11), as long as the OS major versions match.

On an NFS server create a temporary directory (/export/test) and export with the following options (substitute 192.168.1.0/255.255.255.0 with your own network/netmask):

server#vi /etc/exports

/export/test 192.168.1.0/255.255.255.0(no_root_squash,insecure,rw)

Restart the nfs server. This various depending on the flavour of linux..

RHEL 
server#service nfs restart

SUSE
server#service nfsserver restart

On the client machine, mount the export:

client#mkdir /mnt/nfstest
client#mount -t nfs server:/export/test /mnt/nfstest 

On the client, as root user, copy the vi binary to the NFS mount.

client#which vi
—— output ———
/usr/bin/vi

client#cp /usr/bin/vi /mnt/nfstest

Set the suid bit on the copied binary.

client#chmod u+s /mnt/nfstest/vi

SSH onto the nfs server as a non privileged user. As the none privileged user run the vi located in the exported mount on the server:

server$/export/test/vi /etc/passwd

Find the non privileged account in the password file and change the UID to 0, save, logout then log back in as the non privileged user. The user is now root.

The same will work on the client, if you execute the vi from the NFS mount as a regular user, you can point it at any file on the host and will be able to edit as root. It will work with any binary you can think of. 

How do you prevent this?

First of all delete the vi file from the export directory :) … then enable root_squash on the nfs export. On the server edit the /etc/exports again modify the no_root_squash to root_squash:

server#vi /etc/exports

/export/test 192.168.1.0/255.255.255.0(root_squash,insecure,rw)

Restart the nfs server, remount the filesystem on the client:

server#service nfs restart

client#umount /mnt/test
client#mount -t nfs server:/export/test /mnt/nfstest 

From the client, as root create some files on the NFS mount, check the permissions:

client#touch /mnt/nfstest/{test1,test2,test3}

Depending on the permissions set on /export/test, you will either get permission denied or if the directory is world writable, the permissions on the files will look similar to:

-rw-r--r--  1 65534  65534     0 Nov  6  2015 test1
-rw-r--r--  1 65534  65534     0 Nov  6  2015 test2
-rw-r--r--  1 65534  65534     0 Nov  6  2015 test3


The root_squash is remapping the root UID to be the uid of an anonymous user. This uid is configurable in the exports file, man /etc/exports for more information. Copy the vi command again (if permitted) as root on the client to the nfs volume and repeat the steps above (ssh to server run vi on /etc/passwd). This time you will not have permission to save the file the permissions are elevated to a non privileged account. 

That is a bit more secure, however we are not done yet. Another step you can take is to mount the exported filesystem on the NFS server with the nosuid option. 

server#vi /etc/fstab

Find the mount point for /export/, change the options column defaults to.

/dev/mapper/sys_vg-export_lv     /export    ext3    defaults                  0       0

/dev/mapper/sys_vg-export_lv     /export    ext3    nosuid                  0       0

Remount the mount:

server#mount -o remount /export

Dump the vi file on the mount, set the suid bit, switch to a non privileged account and try again:

server#cp /usr/bin/vi /export/test; chmod u+s /export/test/vi

server#su - someuser

server$/export/test/vi /etc/passwd

After making a change to the passed file, you will not be permitted to save the change.

Jump on the client as a non privileged user and try the same:

client$/export/test/vi /etc/passwd

It still works, the client needs to also be remount with the nosuid option:

client#mount -t nfs -o nosuid server:/export/test /mnt/nfstest 

Test it again with the non privileged account, it should fail.

There are a couple of other options that can be specified on mount point to further restrict what can be run from them, check out the noexec (no executable files), nodev (no device files).

If further security is required, look into Kerberos and NFSv4.









Tidak ada komentar:

Posting Komentar