Pwn Machine through NFS
*This is an educational post. Please lock down your NFS and for all that is good on earth don't connect your shares to the internet
Today we are going to work through an example of (1) finding a vulnerable target that allows us to enumerate NFS. When the target vulnerability is discovered we will (2)exploit it and (3) escalate privileges to fully own the machine.
First find a target. There are many options for this, most would like the more targeted approach of using shodan, or if you like the roulette approach you could just send SYN packets to random machines on port 111 and see who responds. (Someone always does). Whatever the approach is, it's exceptionally easy to find a machine/port that responds to a SYN packet. Below we have a target that after an initial scan is showing signs of NFS vulnerability.
port 111 has the service rpcbind. This is our entry point!
Before we dive in with exploits, we need more information to make our exploit more effective.
Let's see what else nmap can tell us about our target.
#ls - l /usr/share/nmap/scripts/nfs*
The above line will show us all the nfs NSE available.
#nmap -p111 --script nfs* 192.168.1.73
It comes back with very valuable information
In the picture above we are pointing at two key pieces of information. Essentially what we have learned here is that everything under the root folder is being shared. Crazy!!!
Awesome, so we can see that our target has a share pointing out to the internet. Now I want to actually interact with that data.
#mkdir meta
#sudo mount -o nolock 192.168.1.73:/ ~/Desktop/htb/meta
"-o nolock" = disable file locking
"192.168.1.73:/" = the share that is available. In our case root directory is the share, which is why we have a single forward slash
"~/Desktop/htb/meta" = the location where you want your mount to be
upon success you will have successfully mounted.
Take a look at this we can now see everything under root
At this point I can touch the data. I want continue digging, perhaps there is a way to escalate what I can do. In this image you can see that I am looking at the first 10 lines of passwd and shadow. This is valuable because now I know the users on this system and I have their hashes.
This next part can be done directly by manipulating the data located on the share, however I personally like to grab a copy of important files so that I can work on them offline (Using my own processor, and mitigating risk of detection).
I'm going to assume you followed my method. We need to use "unshadow" and combine the acquired "etc/passwd" and "etc/shadow"
#unshadow passwd.txt shadow.txt > combined.txt
You should now have a "combined.txt" file that has put the hash from shadow into the second delimited spot of your etc/passwd file.
Next step is to try and crack whatever hashes we can. Let's use John the Ripper.
#john --wordlist=/usr/share/wordlists/rockyou.txt combined.txt
Once John the Ripper has completed run this command
#john --show combined.txt
Awesome now we have credentials for 3 users!!!!
I tested each of these users. 2/3 of the users have shells associated with their accounts. Neither have root privileges.
Ran JtR with with a different wordlist "sqlmap.txt"(if you don't have sqlmap.txt in your /usr/share/wordlists/ then you can download it to your kali instance [3]). Two more users acquired!!
All of these users are able to ssh, none have root privileges.
We want to give one of these users more power. Let's work with "user." Before we go there though I want to check if I can modify data on the target machine. I copied a user from meta/etc/passwd and pasted it at the end.
I connected via ssh and looked at the same file, my change worked! At this point there are MANY things we can do to own this machine. (The fact that you can manipulate files at this points opens up a ridiculous amount of ways to use/abuse this target machine) Let's pick an easy one, giving "user" root capabilities
When I was connected with user via ssh I was unable to sudo. From my attacker machine I opened up meta/etc/sudoers and added the following line
"user ALL=(ALL) ALL"
connected again with ssh and attempted to read the /etc/shadow file (a file that can only be viewed by someone with high privileges or are able to sudo). Since we added "user" to the sudoers we are now able to view the shadow file. Excellent!
My next step is to change the root password.
#sudo passwd root
switch to root user
#su root
We are now root!
*Important
The steps you saw in this demo will not protect you from detection. We literally changed the root password. Next time the real root user attempts to log in they will have a rude surprise (will not be able too). If evading detection is your goal, than changing the root password is not a good route to go. It does work though if your goal is to be a pain.
In addition my activities were logged by the target machine. I didn't do any clean up here. I logged in with ssh as different users and all of these connections were logged. I didn't get shut-out by ssh for brute forcing (because I didn't use brute force tactics), but the switching between different users in a short period of time should raise alarms for the folks monitoring the system.
Hope this post was helpful. Watch out for those shares!
Reference:
[1] https://0xdf.gitlab.io/2019/02/21/htb-legacy.html
[3] https://github.com/3ndG4me/KaliLists
[4] https://www.garron.me/en/linux/visudo-command-sudoers-file-sudo-default-editor.html
