CyberSecLabs – “Shares” Walkthrough

CyberSecLabs

Shares from CyberSecLabs is a interesting beginner box in that there’s very little actual exploitation. No reverse shells, no payloads and we also won’t be using any automated tools for enumeration during privilege escalation. What we will be doing is taking advantage of a open share containing a user’s home directory with everything that entails. We’ll get to root by abusing Sudo permissions two different ways.

Let’s get started.

Shares IP address is 172.31.1.7. Connect to the VPN and ping your target to verify connectivity.

Scanning and Enumeration

As usual I’ll start with a Nmap scan of the target. Here I’m scanning with -sC for default scripts, -sV for service enumeration, and -p- to scan all 65535 TCP ports.

nmap -sC -sV -p- 172.31.1.7

Nmap scan results show a handful of open ports. FTP is open, but we need a password. Port 80 is hosting a web server, and we have RPC on port 111. Next we jump to port 2049 which is hosting a NFS file share. Interesting. Then we have SSH on port 27853 which is also very interesting. After that we have some higher level ports I don’t recognize, and I’ll ignore them for now.

I’ll start by examining the file share that’s being hosted on 2049.

showmount -e 172.31.1.7

Showmount reveals a mounted home directory for a “amir” user. Now we can mount that directory to our local machine and explore the files on the share. I’ll do that using the mount command, NFS for the type of share, followed by the IP address of the target with the path, and the local path where the share will be mounted on our local machine.

After mounting the share I ls -la to reveal all hidden files and folders. Here we see the contents of the user’s home folder. We even have the .ssh folder which hopefully contains a private key we can utilize.

mount -t nfs 172.31.1.7:/home/amir/ /root/CSL/Shares/Mnt/Shares
ls -la

Change directory into the .ssh folder and we see exactly what we hoped. Private SSH keys! Now if you pay attention to the permissions on the left, we can only read one of those files id_rsa.bak.

cd .ssh
ls -la

Let’s take a peek at id_rsa.bak, and unsurprisingly we see it’s a RSA private key. Next we’ll try and use this key to connect to SSH.

cat id_rsa.bak

I copy the id_rsa.bak file into my Shares working directory. Chmod to give the file permissions so we can make it useful. Then attempt to connect to the target over SSH as Amir using the private key.

cp /root/CSL/Shares/Mnt/Shares/.ssh/id_rsa.bak .
chmod 700 id_rsa.bak
ssh -i id_rsa.bak amir@172.31.1.7 -p 27853

As you’ll notice above, we are prompted for a password for Amir. Which we don’t have…. yet.

Exploitation

We need a password to SSH to the box as Amir. How do we get it? Since we have the RSA private key, we can utilize a tool included with John the Ripper aptly called “ssh2john”.

Ssh2john will extract the hash from the SSH private key, and what do we do with hashes? That’s right, we crack them.

locate ssh2john
/usr/share/john/ssh2john.py id_rsa.bak

Run ssh2john again, and this time redirect the output to a new file called hash. Then run John the ripper with a specified wordlist against the hash file. I’m using the go-to rockyou.txt wordlist. If you aren’t sure which wordlist to use when doing capture the flag style boxes, I would recommend starting with rockyou.txt.

/usr/share/john/ssh2john.py id_rsa.bak > hash
john –wordlist=/usr/share/wordlists/rockyou.txt hash

It took almost no time to crack the hash. Very simple password which we see in the John the Ripper output.

Same as before. Connect to the target over SSH as Amir. Enter the password when prompted. Now we have access to the target system.

Privilege Escalation

We have access to the target now as a low privileged user named Amir. We already know the target is a Linux system. Like I mentioned we won’t be using any tools to automate the enumeration process for us.

So where do we start? Well the best place to start in my opinion for a Linux system would be checking what Sudo permissions the user has. That’s the low hanging fruit. A lot of the time we can score a quick win if we have Sudo permissions on a file or command.

sudo -l

Above we see that the Amir user has the ability to run two binaries as the user Amy. One being python3 and pkexec.

First thing we do when we find binaries listed under Sudo, is we look them up on GTFO bins. Lookup python3 and you’ll see we have a Sudo option.

sudo python -c 'import os; os.system("/bin/sh")'

This python command will spawn a /bin/sh shell for us. We can tweak it just a bit, by adding /bin/bash and now it will spawn a bash shell. We’re ready to go now, run the command and specify the user as amy.

sudo -u amy /usr/bin/python3 -c ‘import os; os.system(“/bin/bash”)’
whoami
sudo -l

Boom. We have spawned a bash shell and become the Amy user. Rinse and repeat. Let’s check her Sudo permissions. We see above she also has a binary listed, this time /usr/bin/ssh.

Go back to GFTO bins and let’s find another way to exploit this binary. Of course we find a Sudo option listed for this binary.

sudo ssh -o ProxyCommand=';sh 0<&2 1>&2' x

There’s the command above, and this will spawn a interactive shell as root. I run the command as is and you’ll notice that we do indeed get a root prompt. However, its the basic sh prompt #. If we tweak this command by also spawning a bash shell, we will get a nice Root@Shares prompt.

sudo ssh -o ProxyCommand=’;sh 0<&2 1>&2′ x
whoami
exit
sudo /usr/bin/ssh -o ProxyCommand=’;bash 0<&2 1>&2′ x

Capture the Flags!

cat /home/amy/access.txt
cat /root/system.txt

There you go. Shares from CyberSecLabs. A interesting beginner box, that really enforces some good habits to get into while pentesting or doing capture the flag scenarios. You learn a couple cool tricks on how to work with mounted network shares, and how to reverse a SSH Private key into a hash and then crack it. Lastly we learned to check Sudo permissions first, and always always look them up on GTFO bins for a quick win.