Network File Share (NFS)

This is the second in a series of posts based on an assignment I had. Phase one is to exploit a vulnerability in Metasploitable 2. Phase two is to secure that same vulnerability.

Exploiting NFS

My next target was NFS hosted on port 2049. I installed rcpbind and ran the command rcpinfo -p 192.168.211.148 to show the running services and the command showmount -e 192.168.211.148 which identified that the entire file system was mounted as a file share.

With access to the root file system, the student’s objective was to put an ssh key into the authorized_keys file to ensure later access. The student first generated an ssh key with the ssh-keygen command. WARNING: If you post a private key out in public like I do below, make sure to delete it.

Next, I mounted the NFS to the attack system with the command mkdir /tmp/r00t to create a mount point and sudo mount -t nfs 192.168.211.148:/ /tmp/r00t to mount the share. Navigating to this folder and checking the directory contents showed it was successful.

Next, I attempted to append my newly minted SSH key to the authorized_key file with the command sudo cat /tmp/r00t/tmp/metassh_key.pub >> /tmp/r00t/root/.ssh/authorized_keys. This action was not allowed, so I copied the key and pasted it directly into the file with the nano file editor using the command sudo nano authorized_keys.

Finally, I was able to gain remote root access using the command ssh -I metassh_key root@192.168.211.148. Figure 15 shows the command and root access.

Securing NFS

The next vulnerability I set out to secure was the NFS root mount. My primary objective was to change the shared directory in NFS. First, I created a new directory to share with the command sudo mkdir /mnt/nfs_share. I then made these files accessible to any connected users with the commands sudo chown nobody:nogroup /mnt/nfs_share and sudo chmod 777 /mnt/nfs_share. WARNING: This is not a best practice: chmod 777 gives read write and execute permissions to all users and groups. Read and write should have been used 666, 664, or 644. For more on Linux permissions check out this post on https://linuxize.com/  

Next, I modified the /etc/exports file with the command sudo vim exports. This file showed one share for the root file system. I commented out this line by adding a “#” character and added a new line /mnt/nfs_share *(rw,sync,root_squash,subtree_check,secure). Compared to the previous entry the new line included three additional options. The “root_squash” option stops an external root from having root privilege in the share. The “subtree_check” option helps ensure that a user cannot break out of the shared folder. Finally, the “secure” option forces a connection on a port of 1024 or lower where it is harder to spoof root privilege.

Next, I stopped and restarted the export using the commands sudo exportfs -ua and exportfs -a.

The fix was validated on the attacking Kali machine with the command showmount -e 192.168.211.128 and mounted using the command sudo mount -t nfs 192.168.211.128:/mnt/nfs_share /tmp/test. I validated that the new share only had access to the identified directory, not the entire root directory.