NFS Enumeration

Why NFS Matters

Network File System (NFS) is a standard file-sharing protocol in Unix/Linux environments, allowing remote file access as if local. Unlike SMB (Windows), NFS operates entirely differently and is vulnerable to misconfigurations that commonly leak sensitive files and credentials.

NFS is ubiquitous in enterprise environments from clustered databases to distributed storage and backup systems. Because it’s designed for trusted internal networks, its security model is often overlooked during deployments. This makes it a frequent source of data exposure and privilege escalation vulnerabilities in security assessments.

NFS Versions

Version	Key Feature
NFSv2	Oldest, UDP-only, widely supported
NFSv3	Better error handling, TCP support
NFSv4	Kerberos, stateful, single port 2049, firewall-friendly

How NFS Works

NFS relies on ONC-RPC on port 111 and uses port 2049 for the actual NFS service. Critically, NFS has no built-in authentication it trusts UNIX UID/GID mappings entirely. The server doesn’t verify that a client’s claimed UID matches reality, which is why NFS should only run on trusted networks.

In practice, when a client connects, it sends its UID/GID in requests. The NFS server translates these to local user/group mappings without additional verification. This design choice made sense in the 1980s for campus networks, but it’s a liability in modern security contexts. If you control the client, you can impersonate any user ID on the server.

Configuration & Exports

The /etc/exports file defines what the server shares. Each entry specifies a folder, which hosts/subnets can access it, and what permissions they have:

/mnt/nfs  10.129.101.0/24(rw,sync,no_subtree_check)

This entry shares /mnt/nfs with any host in the 10.129.101.0/24 subnet in read-write mode with synchronous updates.

Common Options

Option	Meaning
rw / ro	Read-write or read-only
sync / async	Wait for disk (safer) or don’t wait (faster but risky)
secure / insecure	Require privileged ports (< 1024) or allow any
no_root_squash	Root files retain UID 0 (dangerous)
root_squash	Root becomes ‘nobody’ user (safer default)

The secure option is important: it requires connections from ports below 1024, which normally requires root. The insecure option removes this requirement, allowing any unprivileged user to interact with NFS.

Dangerous Settings

Several option combinations frequently create exploitable conditions:

• no_root_squash: Allows root to create files with UID 0, enabling privilege escalation. If you can write to a share with this option, you can upload a SUID binary and execute it as root.
• insecure: Clients can use unprivileged ports, bypassing the intended privilege requirement. This allows non-root users to directly interact with NFS.
• rw + no_subtree_check: Open write access without subdirectory verification. Combined, these allow unrestricted file modification.
• async: The server doesn’t wait for disk writes to complete before acknowledging, which is faster but can cause data corruption on crashes.

During assessments, finding no_root_squash + rw on a mount you control is often the quickest path to privilege escalation.

Enumeration

Start by scanning for RPC services on the target:

nmap -p 111,2049 -sV -sC <target>
nmap --script nfs* <target>

The first scan identifies the RPC and NFS services. The second uses Nmap’s built-in NFS scripts to enumerate shares, permissions, and file listings directly.

List all accessible shares on a target:

showmount -e <target>

This command queries the target’s export list and shows which shares are available to your network segment.

Once you’ve identified an accessible share, mount it to inspect contents:

sudo mount -t nfs <target>:/ ./nfs-mount -o nolock
ls -l ./nfs-mount/

The nolock option disables file locking, which is useful when enumerating. When mounted, you can see all usernames and file ownership. If no_root_squash is set, you may be able to write files as root, which is a critical finding. Look for private keys, configuration files, and world-writable directories.

Key Takeaways

• Trust model: NFS trusts UID/GID mappings completely with no additional verification. Never use it across untrusted networks.
• Priority checks: Always check for no_root_squash and insecure options first these are the quickest wins.
• Enumeration: Mount shares to enumerate files, users, and permissions in a human-readable format.
• Hunting grounds: Look for world-writable directories, private SSH keys, backup files, and database credentials.
• Hardening: Use root_squash and secure by default in production. Consider NFSv4 with Kerberos for stronger authentication.
• Assessment value: NFS misconfigurations are common findings and often lead to direct file access or privilege escalation.

---

A practical reference for NFS security testing and safe enumeration.