NFS
Overview
Network File System (NFS) is a network file system developed by Sun Microsystems and has the same purpose as SMB. Its purpose is to access file systems over a network as if they were local. However, it uses an entirely different protocol. NFS is used between Linux and Unix systems. This means that NFS clients cannot communicate directly with SMB servers. NFS is an Internet standard that governs the procedures in a distributed file system. While NFS protocol version 3.0 (NFSv3), which has been in use for many years, authenticates the client computer, this changes with NFSv4.
Version
Features
NFSv2
It is older but is supported by many systems and was initially operated entirely over UDP.
NFSv3
It has more features, including variable file size and better error reporting, but is not fully compatible with NFSv2 clients.
NFSv4
It includes Kerberos, works through firewalls and on the Internet, no longer requires portmappers, supports ACLs, applies state-based operations, and provides performance improvements and high security. It is also the first version to have a stateful protocol.
NFS is based on the Open Network Computing Remote Procedure Call (ONC-RPC/SUN-RPC) protocol exposed on TCP and UDP ports 111, which uses External Data Representation (XDR) for the system-independent exchange of data. The NFS protocol has no mechanism for authentication or authorization. Instead, authentication is completely shifted to the RPC protocol's options.
Default Configuration
NFS is not difficult to configure because there are not as many options as FTP or SMB have. The /etc/exports file contains a table of physical filesystems on an NFS server accessible by the clients. The NFS Exports Table shows which options it accepts and thus indicates which options are available to us.
Exports File
$ cat /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)The default exports file also contains some examples of configuring NFS shares. First, the folder is specified and made available to others, and then the rights they will have on this NFS share are connected to a host or a subnet. Finally, additional options can be added to the hosts or subnets.
Option
Description
rw
Read and write permissions.
ro
Read only permissions.
sync
Synchronous data transfer. (A bit slower)
async
Asynchronous data transfer. (A bit faster)
secure
Ports above 1024 will not be used.
insecure
Ports above 1024 will be used.
no_subtree_check
This option disables the checking of subdirectory trees.
root_squash
Assigns all permissions to files of root UID/GID 0 to the UID/GID of anonymous, which prevents root from accessing files on an NFS mount.
Let us create such an entry for test purposes and play around with the settings.
ExportFS
root@nfs:~# echo '/mnt/nfs 10.129.14.0/24(sync,no_subtree_check)' >> /etc/exports
root@nfs:~# systemctl restart nfs-kernel-server
root@nfs:~# exportfs
/mnt/nfs 10.129.14.0/24We have shared the folder /mnt/nfs to the subnet 10.129.14.0/24 with the setting shown above. This means that all hosts on the network will be able to mount this NFS share and inspect the contents of this folder.
Dangerous Settings
However, even with NFS, some settings can be dangerous for the company and its infrastructure. Here are some of them listed:
Option
Description
rw
Read and write permissions.
insecure
Ports above 1024 will be used.
nohide
If another file system was mounted below an exported directory, this directory is exported by its own exports entry.
no_root_squash
All files created by root are kept with the UID/GID 0.
Footprinting the Service
When footprinting NFS, the TCP ports 111 and 2049 are essential. We can also get information about the NFS service and the host via RPC, as shown below in the example.
Nmap
$ sudo nmap 10.129.14.128 -p111,2049 -sV -sCNmap - cont
$ sudo nmap --script nfs* 10.129.14.128 -sV -p111,2049
Starting Nmap 7.80 ( https://nmap.org ) at 2021-09-19 17:37 CEST
Nmap scan report for 10.129.14.128
Host is up (0.00021s latency).Mounting Found Shares
Once we have discovered such an NFS service, we can mount it on our local machine. For this, we can create a new empty folder to which the NFS share will be mounted. Once mounted, we can navigate it and view the contents just like our local system.
Show Available NFS Shares
$ showmount -e 10.129.14.128
Export list for 10.129.14.128:
/mnt/nfs 10.129.14.0/24Mounting NFS Share
$ mkdir target-NFS
$ sudo mount -t nfs 10.129.14.128:/ ./target-NFS/ -o nolock
$ cd target-NFS
$ treeList Contents with Usernames & Group Names
$ ls -l mnt/nfs/
total 16
-rw-r--r-- 1 cry0l1t3 cry0l1t3 1872 Sep 25 00:55 cry0l1t3.priv
-rw-r--r-- 1 cry0l1t3 cry0l1t3 348 Sep 25 00:55 cry0l1t3.pub
-rw-r--r-- 1 root root 1872 Sep 19 17:27 id_rsa
-rw-r--r-- 1 root root 348 Sep 19 17:28 id_rsa.pub
-rw-r--r-- 1 root root 0 Sep 19 17:22 nfs.shareList Contents with UIDs & GUIDs
$ ls -n mnt/nfs/
total 16
-rw-r--r-- 1 1000 1000 1872 Sep 25 00:55 cry0l1t3.priv
-rw-r--r-- 1 1000 1000 348 Sep 25 00:55 cry0l1t3.pub
-rw-r--r-- 1 0 1000 1221 Sep 19 18:21 backup.sh
-rw-r--r-- 1 0 0 1872 Sep 19 17:27 id_rsa
-rw-r--r-- 1 0 0 348 Sep 19 17:28 id_rsa.pub
-rw-r--r-- 1 0 0 0 Sep 19 17:22 nfs.shareIt is important to note that if the root_squash option is set, we cannot edit the backup.sh file even as root.
We can also use NFS for further escalation. For example, if we have access to the system via SSH and want to read files from another folder that a specific user can read, we would need to upload a shell to the NFS share that has the SUID of that user and then run the shell via the SSH user.
After we have done all the necessary steps and obtained the information we need, we can unmount the NFS share.
Unmounting
$ cd ..
$ sudo umount ./target-NFSLast updated