Following on from Part 1 and Part 2; in this final part of this overview of NFS version 2 and 3, we will look at a number of other countermeasures and a nice way to compromise a system.
Case 5 – Read only shares
This is one of the more useful options. If we are sharing out part of the filesystem, then lets stop the client writing to the share if they don't need to write to it; least privilege.
In this case we specify the ro attribute on the share. Note that we can have combinations, in that we can specify that some clients are rw and others ro. So, we update /etc/exports thus:
Then, from the adversaries machine, when we mount the share rw, we get the following.
As you can see, whilst it appears to mount rw, you still cannot write to it, since it is prohibited at the server end.
However, just like on web services it is important we validate at both ends; that authorized clients also ensure that the 'rules are followed' in case the server is compromised. So, valid clients should also mount the share read-only.
Suggestion 4 – don't share or mount something read-write if read-only is all that is needed.
Case 6 – ACLs
This is probably the best standard NFS option you have. Just like a firewall, we can restrict the range of hosts (there are various filters available; e.g. subnets, netgroups), so that only authorized clients can access the share (or write) in the first place. In this case, the adversary is forced to compromise an authorized client (or the server itself), rather than taking advantage of any other host.
In this case we'll state that only server t2 can access the share.
Now, only t2 can access the filesystem. So, from the adversaries box, this will fail, won't it:
Ah, you need to restart the NFS server in this case:
You need to carefully check the semantics of the specific system.
On Linux the semantics are to share read-only to all clients unless specified otherwise.
On Solaris, the default is to share read-write to all clients unless specified otherwise.
There are other semantics as well, so in short, you should always validate the setup.
Suggestion 5 – Always use an ACL unless you are absolutely sure it cannot be used in your situation.
Case 7 – noexec and nodev
As with any technology, it always worth looking at what options are available or changed, as some can improve security, and some can weaken security.
Often-times, the changes are done in a way that doesn't break existing functionality. So, you can find a weakness in an (old) system that it still present in newer incarnations, since the feature needs to be activated.
In this case, we are going to look at two useful options for NFS mounts – noexec and nodev. By default these are allowed.
First, noexec. This sort of makes sense – by default allowing you to execute programs on NFS shares. However, in today's landscape, as it isn't (normally) authenticated (e.g. Kerberos); probably less so. Let's turn that off on authorized clients:
Next, nodev. This is a nice one. By default we allow special files on an NFS share, these can be named pipes, sockets, and also filesystem devices; basically any device.
Device special files are special on the client that is accessing it. This implies that whether it is the NFS server or the NFS client, the access is the kernel device driver on the system you are accessing it. So, if you create a device for the root filesystem, from a client, then access it on the server; you have access to the root filesystem device on the server.
There is a caveat, by default root is 'squashed', so you cannot just create a device for a filesystem from a client. However, a) this isn't always the case, and b) you can always compromise the NFS server itself and use it the other way round to escalate privileges on the clients.
First example will be with no_root_squash, thus:
Now, on the centos-dummy filesystem we have a secret file. So, from the adversaries box (or a compromised client), we can do this:
Then as joe on the NFS server (or a client) we can then view the filesystem (for the demo we are just using strings, but there are many options including e.g. dd the whole thing for offsite enjoyment):
i.e. we are reading the following file:
Now, for a cross-platform attempt. First, what device do we need on Solaris:
Then on the adversary's Linux box we do the following:
Then back on the Solaris box we can now do this:
But due to some quirks with this kernel we cannot do the following (there may be kernels for which this will work .. I would need to look into it in much more detail)
As you can see, being able to create device special files via a client or the server can be extremely dangerous.
As a side note, Solaris does not have nodev. Instead, nosuid infers the equivalent of nodev. So, it will inadvertently be stopped by the more obvious nosuid lockdown.
Suggestion 6 – only allow appropriate files on a share or mount. Pay particular attention to special files and suid files.
Suggestion 7 – if possible, ensure that the filesystem you are sharing is also mounted with restrictive options on the NFS server.
Case 8 – SELinux
On Linux we can use SELinux to enforce a number of security constraints.
This isn't as scary as people think. You don't have to go into the details of creating policies, etc. Instead, the default targeted policy has a set of SELinux booleans that you can turn on and off to influence policy.
You can see a few by running:
SELinux is a big subject in itself, so I'll leave it for now in this article. Perhaps for another time.
There are many other ways to abuse NFS. For example, normally none of it uses encryption or cryptographic authentication. You can protect part of the NFSv2/3 connections using Kerberos, but for full authentication/encryption you need to be using NFSv4.
So, MITM attacks to monitor or alter data is also a viable option, but I will leave that as an exercise for the reader.