There are several ways to gain root access in Vulnix (release 1.0). Here I shall discuss a variety of methods, although this is in no way a conclusive list.
Assuming you’ve located the IP address, you can run a port scan and will find the following services listening (shortened for easy reference):
- 22/tcp open ssh
- 25/tcp open smtp
- 79/tcp open finger
- 110/tcp open pop3
- 111/tcp open rpcbind
- 143/tcp open imap
- 512/tcp open exec
- 513/tcp open login
- 514/tcp open
- 993/tcp open ssl
- 995/tcp open ssl
- 2049/tcp open nfs
The following stages break down the task into enumeration, attack and privilege escalation.
User Enumeration #1 – SMTP
Firstly we’ll telnet into the SMTP server to see if VRFY is enabled, as this will allow us to enumerate users.
telnet %vulnix_ip_address% 25
You should see the following response:
The user ‘vulnix’ seems to exist (252 response) and by entering another name, in this case ‘thisusercannotexist’ we see that we’re given a 550 response and informed that the user is unknown.
It’s been proven that VRFY methods are implemented so we could quickly enumerate users by using a script such as smtp-user-enum or by using an auxiliary module within Metasploit etc.
User Enumeration #2 – Finger
It may have been noticed that the finger service is available. The following command will confirm if a user exists, and will display interesting information such as the home folder, plan file contents etc.
finger –l –p vulnix@%vulnix_ip_address%
From the results we can see that the user does exist and, as suspected, their home directory is /home/vulnix (see Entry Point #3).
Entry Point #1
If you had previously run smtp-user-enum or a similar script, you may have identified another interesting user named ‘user’. Using hydra to brute force logins via SSH it would be possible to identify that this user has a very weak password. It should be noted that this is just one way to gain shell access with a low privileged account, others exist!
hydra –l user –P passwordlist.txt %vulnix_ip_address% ssh
Entry Point #2
As stated, brute forcing the password is only one way in. You may have noticed that rservices are running on the host. Using putty (or another tool) you should be able to find that one of the identified accounts has been allowed rlogin access to the host.
Note: Within Putty there are two areas to enter login details (auto-login & local username, screenshots follow).
As you can see from the .rhosts file, the account ‘user’ has been granted login rights from any system.
Entry Point #3
The final entry point to discuss is via NFS. Firstly we’ll probe NFS to see what’s available. To view the NFS share(s) you can use the following command:
showmount –e %vulnix_ip_address%
You should see the following share:
From this we can assume that the home directory of vulnix is shared, and this can be mounted from any system.
To mount the share, perform the following commands:
mount %vulnix_ip_address%:/home/vulnix /mnt/vulnix
You should see that permission is denied when attempting to change to the working directory of /mnt/vulnix (permissions are enforced and root squashing is enabled!). However, you should see that owner and group ID’s are set to 2008. Assuming you don’t have an account with the ID of 2008 you won’t be able to access these prior to creating/editing another account. The following command will create a new user with the ID of 2008.
useradd vulnix –u 2008
To view the new user/group and prove the correct ID has been assigned you can cat /etc/passwd and /etc/group respectively to identify the new entries.
Alternatively if you already have another account you could easily alter the ID values to 2008 to achieve the same result.
Switch to the new account and enter the /home/vulnix directory:
With access to the /home/vulnix directory we can now ‘play’ with SSH (as this is the users home directory). The following will allow you to gain SSH access to the host.
On the attacking system create a public/private rsa key pair and copy the public key to the authorized hosts file on the vulnix host using the following commands:
ssh-keygen (complete the onscreen process)
cat id_rsa.pub > /mnt/vulnix/.ssh/authorized_keys
To gain access to the host use the following command:
ssh –i /root/.ssh/id_rsa vulnix@%vulnix_ip_address%
If you’ve managed to log onto the system using the vulnix account (perhaps via SSH as described above), it’s quite an easy task to find how to escalate privileges.
By performing a command such as ‘sudo –l’ immediately it is obvious that this user has sudo access to sudoedit /etc/exports (the NFS share config). Currently the configuration is a little limiting, but what if we were to disable root squashing?
cat /etc/exports (to check to see if the config successfully saved – it did!)
As we have a limited account it isn’t possible to restart the NFS services for our config changes to come into effect. In this particular case we’ll simply hard reboot the host through the VMware player controls – make sure you unmount the share first though.
When the victim host has booted, again mount the NFS share.
Now it is possible to access the NFS share with the root account from which we could copy a bash shell and enable the SUID bit (execute as the owner, in this case root!)
cd /mnt/vulnix (as local root)
cp /bin/bash /mnt/vulnix (make sure it’s from a 32-bit OS – otherwise use SSH etc to make a copy of bash from the vulnix host)
chmod 4777 bash
Now use any method to gain shell access (for the purpose of this I’m using SSH via the previous exploit).
./bash –p (preserves file permissions)
I hope you have enjoyed this challenge. More to come very soon 🙂