Exploiting NFS

(Continuation of Part 1)

In this challenge, I will be exploiting an intentionally misconfigured NFS server to obtain root privileges. Network File System (NFS) is used to share files over a network, allowing users to access remote files as if they were local.

Starting out with a basic nmap port scan, I discovered that an NFS service was running on port 2049. Using showmount, I discovered a visible NFS share named /home. I then mounted the share to /tmp/mount:

Inside the share, I discovered a directory called cappucino, which appears to be a user’s home directory. It contained, among other things, a .ssh folder with a private key. Using this private key, I was able to ssh into the machine:

I now have access to the system, but with low privilege. The next goal is privilege escalation.

With NFS shares, root squashing should be enabled, meaning that anyone accessing the share as a root user should not have root privileges within the remote share. This is typically done by mapping uid 0 (root) to uid 65534 (nobody). In this case, however, root squashing is not enabled. I am able to create a file in the share as root and set the SUID bit, meaning that no matter who executes it, it will be run as the file owner (root).

So, logged in as the low-privilege capuccino user, I copied the /bin/bash executable into the NFS share. Then, on my own machine as root, I made another copy of this bash executable (so that it would be owned by root) and set SUID. In hindsight, chown might have made more sense, but, well… the screenshot’s already been taken. (Alternatively, if I didn’t have SSH access to copy the original bash executable, I could have downloaded a compatible bash executable and set SUID on that.)

Finally, I again ssh’d into the low-permission user, and by running the bash executable (with the -p flag, meaning don’t reset effective user id to real user id), got root access!

This exercise demonstrates the significant dangers of a misconfigured NFS server.

Firstly, the no_root_squash option in /etc/exports should not be used, as there are clear dangers to allowing users to have root privileges when modifying files in an NFS share.

It is also important to ensure your private keys and sensitive documents are not available in a public NFS share. Ensuring that shares have proper access controls set up, via both subnet ranges and user/group permissions, is critical.