Following on from Part 1 of this article, we continue our introduction to NFS by abusing SUID.
When we talk about SUID here, we also infer SGID. i.e. you can set the effective group ID as well; but I will leave that as an exercise for the reader.
Case 4a – nosuid
Unlike the no_root_squash option, which is by default 'squashed', the ability to have and use SUID executables on an NFS share is there by default. If you mount a filesystem, there is no indication that you have enabled this (suid) capability as the non-default flag is the inverse of that.
My Solaris 10U9 box disables this as an explict (default) flag for the /net filesystem, which you can see in the config /etc/auto_master, but for normal mounts you must specify it yourself.
What this implies is that the clients (and the NFS server) trust the data on the filesystem, so much so that you can have executable code on the filesystem that can take on the privileges of others via SUID.
Let's assume that you have got unprivileged access to a Solaris client, but wish to access the oracle user in order to pilfer data from a database. Let's also assume that you have access to another client as root or oracle (this could be the attackers box), which can (or does) mount the NFS share.
On the Solaris client (the DB server) we have the following setup:
So, from the attackers controlled box (with root access and the share mounted), we can do the following. Note that this is a Linux box in this case, and as it is the attackers box, uid 5000 is user bh5000 and not the name oracle. It will appear as oracle on the DB server.
Now, back on the Oracle DB server, where the attacker has unprivileged access, we can now do the following:
Success, our effective UID is now that of the oracle user.
If the client was a Linux box, then we could also do the same. So, for centos-7-2-t2 as a client, with the mount as /myNFSmount.
Then on the client:
Uh. I'm not euid 5000! It didn't work.
As is commonplace, we will have to do a bit more analysis. Two likely options are, the OS prevented us, or the program prevented us.
There is a quick way to test this; by using another executable and see if this causes a problem.
So it is bash. Why? Let's look at the source code.
In shell.c we find main(). Within that we see the following which will set the euid to the real uid (disabling the suid):
So, how to set privileged_mode? In flags.c we see the answer, but also the following comment:
So, let's re-try with the '-p' option:
Countermeasures depend partly on your situation.
On Solaris you can export the share as nosuid.
Alternatively, if the filesystem on the NFS server that houses the share does not need to have suid enabled, then ensure it is mounted nosuid in the first place.
In any case, however you mount it, ensure that the nosuid flag is set.
Case 4b – nosuid with no_root_squash
If the administrators have allowed no_root_squash on such a share, well; let the fun begin.
First, let's take the Linux client and perform the same trick as in case 4a.
Then on the client:
Yey; got r00t.
Let's 'quickly' finish off with the Solaris example:
Then on the client:
Arrrgh. It was working a minute ago with the oracle user!
As we are demonstrating this (or prepping in a test lab as an adversary), let's see the syscall's that occur when we run that executable. We will need a root window on the Solaris box to do the trace of the original shell and its siblings and then re-run the SUID shell:
Unfortunately we do not have the source code this time, so let's break into a debugger for some analysis of /bin/sh (NB: yes, you could just dump the code from the binary if you wish; but we would miss all the fun in using a debugger):
Here we can clearly see the answer.
We get the values for the real and effective UIDs (and GIDs).
Then, the first compare at main+0x260 checks to see if the real and effective UIDs are the same; if so we skip the rest of this test and carry on as normal.
The second compare at main+0x264 checks to see if the effective UID is greater than or equal to 0x64 (100); if so we carry on as normal.
If both tests are true then we reset the user's UID to their real UID. i.e. if we are running SUID and the UID is a system reserved UID (< 100), drop the privs to that of the calling user.
In both cases (4a, 4b), workarounds to the program preventing you becoming suid are numerous, including rolling your own program (just recompile a custom bash, for instance), use another program if available.
Suggestion 3 – don't allow suid on NFS
From an adversaries or pen-tester's point-of-view, this is a simple demonstration that it can appear your attack didn't work, but it did work as intended (the basic premise was right); it is just that something else broke it. In this case, both bash and Solaris sh shells have countermeasures to stop SUID abuse irrespective of the use of NFS.
In Part 3 we will wrap up this basic overview of NFSv2/v3 with a look at a number of other countermeasures.