Network File System (NFS) is used to share files and directories over the network through ‘exports’. When a client wants to gain access to a share on the remote server, the client will firstly attempt to mount the share. The list of allowed clients per share is located in /etc/exports on the server. The problem with this approach is that the only credential for access is the client’s IP address. If a trusted machine is taken over or otherwise spoofed, the attacker has full access to the share. All versions of NFS prior to version 4 utilize this same security model. The next issue to take into account is that wildcard ‘*s’ are permitted within the exports file. Site administrators often use wildcards without thinking through the implications to allow a range of hosts access to a share. Future changes to the network or network breaches may allow a user access to a share that the administrator had not intended.
Next, in default configuration, the remote NFS server will map the UID/GID of the connecting user. For example, if ‘npn’ is my local user account, and /etc/passwd and /etc/group have assigned me a uid and gid of 1001, then on connecting to a remote NFS share, I’ll have access as that same uid and gid on the remote system, regardless of what username is assigned to it.
This is not a problem if the Client is trusted not to be compromised, however a compromised client or user with root access to the client can set/create any account with any uid/gid and thus gain access to the remote shares under that account. This even applies to a client connecting as user root! (The squash_root option will prevent a remote user connecting as local root)
https://github.com/bonsaiviking/NfSpy will allow a user to pass an arbitrary uid and gid to the remote server.
Lets take a look at the output produced by running rpcinfo against our NFS server. This will show us the RPC services running. The command succeeding also alerts us to the fact that rpcinfo is open to our IP address and neither firewall nor tcp wrappers is preventing access. Next, let’s pass a variety of arguments to ‘showmount’ to get an idea of what directories are being exported, what IPs are allowed, and what IPs are mounting what shares. This is already far too much information to be giving to an anonymous network user.
The most common attack scenarios are a) where malicious binaries are uploaded to NFS shares that allow shell access to the NFS server when run, or b) modifying rhosts or SSH’s authorized_keys file when a user’s home directory is exported, in order to grant access to the attacker’s IP or SSH key.
NFSv4 supports Kerberos for stronger security.
Lastly, we can attempt to mount a remote NFS share using the following syntax:
We can see in this case, that our mount request from our own IP (10.0.10.121) was refused per the export/IP list. Being on the local LAN, we can just change our own IP, and then attempt to remount the share which will be successful.