NFS

NFS is the Unix world’s file sharing — and because it pushes authentication onto RPC and trusts the client’s UID, a misconfigured export lets you mount a share, impersonate whatever user owns the files, and read or modify them at will. The no_root_squash option turns that into a clean privilege escalation.

Protocol: TCP/UDP · Ports: 2049 (NFS) · 111 (RPC portmapper)

What Is NFS?

Network File System (NFS), developed by Sun Microsystems, serves the same purpose as SMB — accessing file systems over a network as if they were local — but it’s used between Linux and Unix systems. A big advantage of NFSv4 over older versions is that it uses just a single port (TCP or UDP 2049), which makes it much easier to run across firewalls. Older versions also rely on the ONC-RPC/SUN-RPC protocol on port 111, using XDR (External Data Representation) for system-independent data exchange. The critical security fact: NFS has no authentication or authorization mechanism of its own. Authentication is shifted entirely onto RPC’s options — which is exactly the gap you exploit.

Default Configuration

NFS is simpler to configure than FTP or SMB. The /etc/exports file holds a table of the physical filesystems the server makes available, which hosts/subnets can reach them, and with what rights:

# /etc/exports
/mnt/nfs    10.129.14.0/24(rw,sync,no_subtree_check)

This entry shares /mnt/nfs to the entire 10.129.14.0/24 subnet — meaning any host on that network can mount the share and inspect its contents. Each export is the folder, then the host or subnet allowed, then the options in parentheses.

Dangerous Settings

Several export options are risky:

Option	Risk
`rw`	Read-write access — clients can modify files
`insecure`	Allows ports above 1024. Normally only root can use ports below 1024, which keeps unprivileged local users from interacting with NFS. `insecure` removes that barrier
`nohide`	Exposes nested/child filesystems
`no_root_squash`	The big one — a client connecting as root is treated as root on the share, instead of being “squashed” to the unprivileged `nobody` user

no_root_squash is the privilege-escalation enabler. With it set, you can write a root-owned SUID binary onto the share from your own machine (where you’re root), then execute it on the target to run as root. Without it, root_squash maps you down to nobody and even root can’t touch root-owned files like a backup.sh.

Footprinting the Service

RPC Enumeration with Nmap

Ports 111 and 2049 are the ones that matter. The rpcinfo NSE script lists all running RPC services, their names, and ports — confirming the share is reachable on the ports it needs:

nmap -sV -sC -p111,2049 10.129.14.128

PORT     STATE SERVICE  VERSION
111/tcp  open  rpcbind  2-4 (RPC #100000)
| rpcinfo:
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100003  3,4         2049/tcp   nfs
|   100005  1,2,3        892/tcp   mountd
2049/tcp open  nfs_acl  3 (RPC #100227)

NFS-specific NSE scripts can go further and show the share’s contents and stats:

nmap --script nfs-ls,nfs-showmount,nfs-statfs -p111,2049 10.129.14.128

Show Available Shares

List the exports with showmount:

showmount -e 10.129.14.128

Export list for 10.129.14.128:
/mnt/nfs 10.129.14.0/24

Create an empty local folder and mount the share to it, then browse it like any local directory:

mkdir target-nfs
sudo mount -t nfs 10.129.14.128:/mnt/nfs ./target-nfs/ -o nolock
cd target-nfs

List with Owners — and Why It Matters

List contents showing usernames/groups, then UIDs/GIDs:

# By username / group name
ls -l target-nfs/

# By numeric UID / GID
ls -n target-nfs/

-rw-r--r-- 1 cry0l1t3 cry0l1t3  1872 Jun 25 12:00 id_rsa
-rwx------ 1 root     root       402 Jun 25 12:00 backup.sh

Because NFS trusts the client’s UID, once you know the UIDs and GIDs that own the files, you can create matching users/groups on your own machine and adapt to the share — letting you read and modify files as those owners.

If root_squash is set, you cannot edit a root-owned file like backup.sh even as root — your root gets squashed to nobody. That single option is the difference between “I can read the share” and “I own this box.”

Escalation via SUID

NFS also enables local privilege escalation. If you already have SSH access and want to read files only a specific user can access, upload a shell to the NFS share with that user’s SUID set (from your machine, where you control ownership), then run it through your SSH session — it executes with the SUID user’s rights. When you’re finished, unmount cleanly:

sudo umount ./target-nfs/

Quick Reference

Command	Purpose
`nmap -sV -sC -p111,2049 <ip>`	RPC + NFS enumeration
`nmap --script nfs-ls,nfs-showmount,nfs-statfs <ip>`	Share contents and stats
`showmount -e <ip>`	List available exports
`mount -t nfs <ip>:/share ./local -o nolock`	Mount the share
`ls -l` / `ls -n`	List with owner names / numeric UIDs
`umount ./local`	Unmount when done

The footprinting flow: nmap/rpcinfo to confirm RPC and NFS → showmount to list exports → mount the share → list by UID/GID → impersonate owners (or abuse no_root_squash/SUID to escalate).

Next: RSYNC — enumerating and pulling files from rsync modules.

Overview

Nfs

NFS

What Is NFS?

Default Configuration

Dangerous Settings

Footprinting the Service

RPC Enumeration with Nmap

Show Available Shares

List with Owners — and Why It Matters

Escalation via SUID

Quick Reference

​NFS

​What Is NFS?

​Default Configuration

​Dangerous Settings

​Footprinting the Service

​RPC Enumeration with Nmap

​Show Available Shares

​Mount the Share

​List with Owners — and Why It Matters

​Escalation via SUID

​Quick Reference

NFS

What Is NFS?

Default Configuration

Dangerous Settings

Footprinting the Service

RPC Enumeration with Nmap

Show Available Shares

Mount the Share

List with Owners — and Why It Matters

Escalation via SUID

Quick Reference