Rooting HackLAB: Vulnix
This one, available here, is quite a bit more difficult. The idea behind this VM is that the vulnerabilities are due to misconfigurations, rather than any underlying software exploits. Once the VM is up and running in our virtual lab, it's time for host discovery:
As I know my own IP address, and the address of the Virtual DHCP server, I can tell that the target machine is at 192.168.56.101. Time for some more in-depth enumeration. Let's start with a basic nmap version detection scan:
There's a lot to digest here. For now, I'll use some additional enumeration tools. enum4linux returns nothing of real interest. I try a more extensive nmap --script=vuln scan, but it doesn't return anything actionable either. Time to start poking around at the services we already know are running on the box. First, we can see an SMTP server, so let's try to enumerate SMTP usernames with the VRFY command. I have a simple python script just for the purpose:
Let's run this against the target, using a suitable wordlist. I used nmap's wordlist at /usr/share/nmap/nselib/data/usernames.lst
Great! We found users. Now if they're local users on the machine as well, we could try to brute force an ssh login. (of course root is, but we'll test "user") Since finger is running on the target, we'll use that to query for information about "user."
Nice! We have a candidate for brute forcing, which we'll do next, using hydra:
And now we have a password for "user" that we can use to ssh in to the target:
Were in! Now, the question is whether we can escalate privileges. I attempt to sudo su directly to root, but it doesn't work, because "user" isn't in the sudoers file. We can't do much with this user, but I did get a look at the /etc/passwd file, and discovered an additional user, "vulnix" with uid 2008. This will come in handy later...
Now at this point we can try to brute force an ssh login "vulnix" like we did previously with "user," but as it turns out this password is far more difficult and computationally infeasible to guess. At this point we step back and look at our previous enumeration steps. From our initial nmap scan, we saw that nfs is running on the target machine, so perhaps we can mount a share and enumerate further. We can see what shares are available through the showmount -e command.
So, the shared folder is the user vulnix's home directory. We can mount it to our local filesystem, like so:
We can't access it at this point, as we don't have the privileges of the owner. but we can use a neat little hack to work around this. If we create a user on our local machine named "vulnix" with the same user ID 2008, then we can access the mounted share locally.
And we're in! But how can we leverage greater access to the target from here? We'll generate an rsa key pair using the ssh-keygen command, create a new .ssh directory in the mounted vulnix home directory, then create an authorized_keys file therein, into which we'll put our public key. We generate the keys:
Then put it in our mounted directory:
Now we can ssh into the target as vulnix.
Let's check what privileges we have as vulnix, using sudo -l:
Since we can edit the /etc/exports file, we can change the root_squash option for /home/vulnix to "no_root_squash," which will allow remote users to upload setuid binaries to the nfs share. (Obviously not the most secure option)
Now that we've done this, we can create a reverse shell binary as root on our attack machine and chmod 4777 to set the setuid flag. We'll put it in our mounted directory, then ssh in as vulnix and execute it on the target, awaiting the shell in another terminal window with a netcat listener.
First, though, one issue here is that you have to reboot the VM from the hypervisor for the change to the /etc/exports file to take effect, which is a bit of a cheat, but I could think of no other way to do it, and everyone else, including the VM creator, seems to have done it this way.
So, we'll use msfvenom to create our reverse shell as an ELF binary, chmod 4777 it, reboot, then remount the nfs share, ssh in, and execute our setuid reverse shell:
Meanwhile, on our listener:
Root!
An alternate way to do this is to copy /bin/bash to the share, chmod it, then execute it with the -p option to retain these original permissions, but it didn't work for me, as the target wouldn't execute my bash file, I presume because the target has a 32 bit architecture and my Kali box is 64 bit.
Overall, this machine was challenging, but a good learning experience with regard to nfs configuration vulnerabilities. This was a new vector for me, and I learned some new tricks in my research for this one, thanks to abatchy and others, who helped me get unstuck. Credit for the VM goes to rebootuser. Well done.
As I know my own IP address, and the address of the Virtual DHCP server, I can tell that the target machine is at 192.168.56.101. Time for some more in-depth enumeration. Let's start with a basic nmap version detection scan:
There's a lot to digest here. For now, I'll use some additional enumeration tools. enum4linux returns nothing of real interest. I try a more extensive nmap --script=vuln scan, but it doesn't return anything actionable either. Time to start poking around at the services we already know are running on the box. First, we can see an SMTP server, so let's try to enumerate SMTP usernames with the VRFY command. I have a simple python script just for the purpose:
Let's run this against the target, using a suitable wordlist. I used nmap's wordlist at /usr/share/nmap/nselib/data/usernames.lst
Great! We found users. Now if they're local users on the machine as well, we could try to brute force an ssh login. (of course root is, but we'll test "user") Since finger is running on the target, we'll use that to query for information about "user."
Nice! We have a candidate for brute forcing, which we'll do next, using hydra:
And now we have a password for "user" that we can use to ssh in to the target:
Were in! Now, the question is whether we can escalate privileges. I attempt to sudo su directly to root, but it doesn't work, because "user" isn't in the sudoers file. We can't do much with this user, but I did get a look at the /etc/passwd file, and discovered an additional user, "vulnix" with uid 2008. This will come in handy later...
Now at this point we can try to brute force an ssh login "vulnix" like we did previously with "user," but as it turns out this password is far more difficult and computationally infeasible to guess. At this point we step back and look at our previous enumeration steps. From our initial nmap scan, we saw that nfs is running on the target machine, so perhaps we can mount a share and enumerate further. We can see what shares are available through the showmount -e command.
So, the shared folder is the user vulnix's home directory. We can mount it to our local filesystem, like so:
We can't access it at this point, as we don't have the privileges of the owner. but we can use a neat little hack to work around this. If we create a user on our local machine named "vulnix" with the same user ID 2008, then we can access the mounted share locally.
And we're in! But how can we leverage greater access to the target from here? We'll generate an rsa key pair using the ssh-keygen command, create a new .ssh directory in the mounted vulnix home directory, then create an authorized_keys file therein, into which we'll put our public key. We generate the keys:
Then put it in our mounted directory:
Now we can ssh into the target as vulnix.
Let's check what privileges we have as vulnix, using sudo -l:
Since we can edit the /etc/exports file, we can change the root_squash option for /home/vulnix to "no_root_squash," which will allow remote users to upload setuid binaries to the nfs share. (Obviously not the most secure option)
Now that we've done this, we can create a reverse shell binary as root on our attack machine and chmod 4777 to set the setuid flag. We'll put it in our mounted directory, then ssh in as vulnix and execute it on the target, awaiting the shell in another terminal window with a netcat listener.
First, though, one issue here is that you have to reboot the VM from the hypervisor for the change to the /etc/exports file to take effect, which is a bit of a cheat, but I could think of no other way to do it, and everyone else, including the VM creator, seems to have done it this way.
So, we'll use msfvenom to create our reverse shell as an ELF binary, chmod 4777 it, reboot, then remount the nfs share, ssh in, and execute our setuid reverse shell:
Meanwhile, on our listener:
Root!
An alternate way to do this is to copy /bin/bash to the share, chmod it, then execute it with the -p option to retain these original permissions, but it didn't work for me, as the target wouldn't execute my bash file, I presume because the target has a 32 bit architecture and my Kali box is 64 bit.
Overall, this machine was challenging, but a good learning experience with regard to nfs configuration vulnerabilities. This was a new vector for me, and I learned some new tricks in my research for this one, thanks to abatchy and others, who helped me get unstuck. Credit for the VM goes to rebootuser. Well done.
Comments
Post a Comment