If you want to try out this before reading the walkthrough the VM can be downloaded from here.
We also have a few public runs of our “Hacking Enterprises: Understanding in.security” training on the horizon, so if you’re interested in attending either our onsite or live virtual courses to learn more on Linux, Windows and network exploitation do check this out.
Additionally, when we attempt to run a SUID file (owned by a different user) we will need to be aware of the following info (the below is redacted: source https://linux.die.net/man/1/bash). This relates to the -p switch within bash.
“…Turn on privileged mode… If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, these actions are taken and the effective user id is set to the real user id. If the -p option is supplied at startup, the effective user id is not reset. Turning this option off causes the effective user and group ids to be set to the real user and group ids…”
The default networking is configured as NAT so the first thing we’ll do is to change this to bridged so we can easily SSH into the box.
There are also numerous enumeration scripts and tools available, however we’ll be using LinEnum to aid in identifying vulnerabilities for this walkthrough. Obviously the output will need to be parsed and some logic will need to be applied, but these resources should get you heading in the right direction.
As stated in the original post, to start the challenge you can log on with the credentials bob/secret so this is where we shall begin…
Exploit: sudo (multiple)
Upon logon we can issue the command sudo -l and see that bob is granted access to run a vast range on pwnable programs.
We’re not going to cover the entire library of breakouts here, but a few examples include:
On Lin.security run the command:
On another session on Lin.security run the command:
Exploit: Hash in /etc/passwd
On modern Linux systems user password hashes are stored in /etc/shadow. If we look in /etc/passwd we generally will see something along the lines of:
The x in this instance denotes that the password hash for this user is stored in /etc/shadow. However, it is possible to substitute this x for a hash within /etc/passwd, which will then be evaluated by the host. On the Lin.security host you will see such an account.
A tool like JTR or hash-identifier will help identify this hash as descrypt, then we’re in a position to throw this at either JTR or hashcat to crack.
Exploit: cron job
Looking at /etc/crontab will yield some interesting results.
Cronjobs, root and tar == ripe for a bit of wildcard exploitation! For further details on this attack we recommend reading this very detailed article on the subject.
For this attack we’re going to open a second SSH session on Lin.security as bob and start a netcat listener on port 9999.
Within the attacking session we’ll execute the following commands.
In another session on Lin.security we need to have a listener running:
Now we wait for the job to execute…
Exploit: Hidden file
Sometimes the easiest exploits are hidden in plain sight 😉
Running a search for hidden files over the user home directories reveals something of interest.
Exploit: SUID #1
We can quickly find all SUID files using a command such as:
From here one binary looks to be of particular interest (assuming we are susan 😉 )
For this PoC we’ll read the sensitive file /etc/shadow.
Exploit: SUID #2
Refering back to Method 5: SUID #1 we’ll use the same command to mimic the above results.
Exploit: NFS (low privileged access)
For this task we’re going to take a new perspective and port scan the host. From the results we see that SSH and NFS (TCP 22 and 2049 respectively) are open.
Additionally we’re going to use an attacking host based on Kali (apt-get install nfs-common will ensure you have the required NFS client tools to hand).
Firstly we’ll need to identify any exported NFS resources.
Firstly to create a SSH public/private key pair.
As we have established a session as peter on Lin.security (see method 7 above for further details) we can now continue to see what this user has access to.
Looking at the id info for peter, it seems he is a member of the powerful docker group.
Continuing with abusing the privileges peter holds, let’s see if this user has sudo privileges.
Lastly, let’s take a look at the systemd configuration.
It seems that peter owns the file debug.service and he has read/write access to this file.
Viewing the file contents alludes to a service in.security debugging that is calling a binary located at /root/debug which is run as root.
To exploit this we’re going to use a technique similar to that of the sudo ssh exploit as detailed in Method 1. Firstly let’s create a new script that’ll copy bash to systemdbash and set the SUID bit on this shell. Don’t forget to make this script executable!
There may have also been a weak root password, but we’ll leave that for you to discover 😉
We hope you’ve had fun playing and learning from Lin.security and keep an eye on our feed for upcoming challenges.