> ## Documentation Index > Fetch the complete documentation index at: https://0-x.dev/llms.txt > Use this file to discover all available pages before exploring further. # 111 & 2049 - NFS (Network File System) `Default Ports: 111 (RPC/portmapper), 2049 (NFS)` NFS lets a Unix/Linux host mount another machine's directory as if it were local, and it's one of the few services where misconfiguration alone, with no exploit and no credentials, can hand over full root access to a target. The whole trust model is built around the client's own UID, which is exactly where it tends to fall apart. > **RPC / Portmapper (111)** > > NFS doesn't listen on a fixed port for every function. Portmapper tells a client which port a specific NFS service (mounting, locking, etc.) is actually running on. > **NFS Service (2049)** > > Where the actual file-sharing happens once a client knows which share to mount and has permission to do so. > [!WARNING] > > NFS has no concept of usernames or passwords. Access is controlled entirely by UID/GID, and trust in the client's claimed UID is the root of almost every NFS misconfiguration covered below. *** ## How NFS Trust Actually Works Unlike SMB, NFS doesn't ask for a login at all. When a client mounts a share, the NFS server trusts whatever UID and GID the client's own OS reports for the connecting user, and grants file access based on matching that UID against the file's ownership on the server. In practice, this means if you can set your own user's UID on your attacking machine to match a UID that has access on the target (often simply `1000`, the first regular user on most Linux installs, or `0` for root), the server will treat you as that user without ever checking a credential. > [!NOTE] > > The `no_root_squash` export option is the single most important misconfiguration to look for. By default NFS maps a connecting root user (UID 0) down to an unprivileged "nobody" account, a protection called root squashing. If `no_root_squash` is set on an export, that protection is disabled and a root user on the client is treated as root on the share too. *** ## Enumeration Before mounting anything, find out what's actually being shared and what permissions apply. ```bash theme={null} showmount -e TARGET ``` `showmount -e` lists every export the server is offering along with the IP ranges or hosts allowed to mount each one, which tells you immediately whether a share is open to anyone or restricted to specific hosts. ```bash theme={null} rpcinfo -p TARGET ``` `rpcinfo` queries the portmapper directly and lists every RPC service registered on the host, not just NFS, which can reveal other RPC-based services (NIS, rpc.lockd, etc.) worth investigating alongside it. Nmap covers the same ground with NFS-specific scripts layered on top: ```bash theme={null} sudo nmap TARGET -p111,2049 -sV -sC sudo nmap TARGET -p111,2049 -sV --script nfs* ``` > [!TIP] > > The `nfs*` script category includes `nfs-showmount` and `nfs-ls`, which between them list exports and actually browse file contents without ever mounting the share, worth running before touching `mount` at all. *** ## Mounting a Share Once you know an export exists and nothing's obviously restricting it, mounting works like any other local filesystem. ```bash theme={null} mkdir target-nfs sudo mount -t nfs TARGET:/SHARE ./target-nfs/ -o nolock ``` `-o nolock` skips NFS file locking, which avoids a dependency on `rpc.statd` running and often sidesteps a class of mount errors on misconfigured servers entirely. ```bash theme={null} sudo umount ./target-nfs ``` > [!TIP] > > List the UID/GID of files inside the mount with `ls -la` before assuming you have no access. A file owned by a UID other than yours may still be readable or writable if you adjust your own user's UID to match it. *** ## Privilege Escalation via no\_root\_squash > [!WARNING] > > This is a direct path to root on the NFS server itself when the misconfiguration is present, treat a positive finding as critical. If an export has `no_root_squash` set, mounting as root on your attacking machine gives you root-level file operations on the share. The classic technique is dropping a SUID binary into the share from your attacking host, where you control root, then executing it from the target host, where it now runs as root. ```bash theme={null} # On your attack host, as root, inside the mounted share cp /bin/bash ./rootbash chmod +xs ./rootbash ``` ```bash theme={null} # On the target host, once the SUID binary is visible on its side of the mount ./rootbash -p ``` > [!NOTE] > > The `-p` flag on bash preserves the elevated privileges from the SUID bit rather than dropping them immediately, without it the shell resets its effective UID back to the invoking user's. *** ## UID Spoofing Without Root Even without `no_root_squash`, matching a regular user's UID can expose their files. Linux lets a local user create and switch to arbitrary UIDs with root privileges on your own attack box, which doesn't require anything on the target at all. ```bash theme={null} sudo useradd -u 1000 nfs-user sudo su nfs-user ``` Any files on the mounted share owned by UID `1000` on the target are now readable as this user, no credentials or vulnerabilities required, just a UID collision. *** ## Quick Reference Tools > **[Hackviser: NFS](https://hackviser.com/tactics/pentesting/services/nfs)** > > Quick-reference pentesting guide for the NFS service. > **[HackTricks: NFS](https://hacktricks.wiki/en/network-services-pentesting/nfs-service-pentesting.html)** > > Deeper breakdown of NFS enumeration and privilege escalation techniques. > [!WARNING] > > Mounting a share and modifying UID mappings can expose or overwrite real user data on the target. Stick to read-only verification until write access is confirmed to be in scope. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.