Stratosphere — An Apache Struts-Shock HackTheBox Walkthrough

Mitch Moser
Sep 2, 2018 · 5 min read

Summary

Stratosphere is a Linux host running a web server vulnerable to CVE 2017–5638: a critical vulnerability in Apache Struts 2 that was leveraged to gain remote code execution as a low-privileged user on the system. Local enumeration returned credentials that were used to access a local instance of MySQL. This database contained credentials that were then used to SSH onto the machine as a user with sudo privileges to execute a single Python 2 script. Python 2’s input sanitization and library import functionality were exploited to gain root privileges on the system.

Recon

I began recon on this host with a full port scan using nmap with a few arguments to improve the speed of this scan:

nmap -sT --min-rate 5000 --max-retries 1 -p- 10.10.10.64

-sT — TCP connect scan
--min-rate — makes nmap try to keep the sending rate at or above a specified number of packets per second (in this case, 5000 packets per second)
--max-retries — Cap the number of retransmissions
-p- — scan all ports; 1 through 65535

This was able to scan every port in less than 30 seconds! Although noisy, this method is great for quickly returning uncommon ports quickly.

I followed this up with another scan to enumerate Service Versions and run Default Scripts on the 3 open ports, however nmap was unable to fingerprint ports 80 and 8080. Whenever this happens, nmap will return the responses from multiple requests in raw html to the terminal in order to present the user with results to manually identify the services. It clutters up the scan results, so I’ve redacted it with in the following output:

nmap -sV -sC -p22,80,8080 10.10.10.64

-sV — Service Version scan
-sC — run default scripts
-p — specify ports

This scan was able to return a Debian host from the SSH service on port 22. The web services were a little more difficult to fingerprint. From here, I visited the homepages of the web services on port 80 and 8080 and they appeared to be the same:

Navigating to the ‘Get Started’ links returned a page that simply said “Site under construction. Please check back later.”… So I needed to look for something else on the server.

From here I began enumerating the web directories using gobuster on both port 80 and 8080. These returned the same results.

gobuster -u http://10.10.10.64 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

This scan returned two web directories: /manager and /Monitoring. The /manager directory was a password-protected Tomcat admin page. Since we didn’t have any creds at this point, it wasn’t super useful but it was helpful to now know this was running Apache Tomcat.

The second directory was a little more interesting, /Monitoring actually redirected to /Monitoring/example/Welcome.action. This page also had links to sign on or register an account. However, like the “Getting Started” links on the homepage, these only returned a message: “This feature is under construction. Please try again in the next iteration.”

Navigating around this page returned the following files:

http://10.10.10.64/Monitoring/example/Welcome.action
http://10.10.10.64/Monitoring/example/Login_input.action
http://10.10.10.64/Monitoring/example/Register.action

Each webpage file had a .action extension. This was not something that I had seen too often. I began looking into what this extension could indicate and found Apache Struts documentation that touched on this naming convention and concept.

Combining the theme of the website as a credit monitoring service and the web framework of Apache Struts, I was immediately reminded of Equifax’s data breach that leveraged a flaw in the Apache Struts framework.

In order to validate this, I was able to find an nmap script that checks for this vulnerability:

nmap -p80 --script http-vuln-cve2017–5638 --script-args path=/Monitoring/example/Welcome.action 10.10.10.64

This scan was able to successfully validate that the server was vulnerable to CVE 2017–5638: Apache Struts Remote Code Execution Vulnerability.

Exploit

Now that the vulnerability has been successfully identified, I used searchsploit to look for exploit scripts that could be leveraged against this vulnerability. There were many scripts available in the results and I found this script accomplished what I needed. As part of searchsploit, it was already located in Kali at the full path:

/usr/share/exploitdb/exploits/linux/webapps/41570.py

Running the script requires two arguments, the vulnerable webpage, and a command. Proof of concept:

Now we have Remote Code Execution on the server!

Local Enumeration

From here I spent a lot of time trying to get a reverse shell only to find there were very strict firewall rules in place that limited this option very effectively. Instead of fighting with this, I chose to stick it out with the Remote Code Execution script and gather my information manually.

I was able to recover credentials in a file at /var/lib/tomcat8/db_connect:

I was also able to validate that a MySQL instance was running on a local-only connection:

I was able to work my way through the databases and dump the user database which contained only the single entry for Richard F. Smith with a cleartext password:

Looking at the accounts in /etc/passwd that can login to /bin/bash returned richard as a user!

The credentials could then be used to SSH into the server.

Privilege Escalation

Once on the machine and since we had Richard’s password, enumeration began with sudo -l to see if this user could run anything with elevated privileges. Sure enough:

Richard was able to run a python script in his home directory. However, we only had read and execute privileges on the script. The contents were:

I will admit that I unfortunately wasted my time cracking all of the hashes in this script. It was a learning experience — I had never even heard of BLAKE2b 256 until this challenge. However, this was a rabbit hole. There is no /root/success.py.

Although the script starts with #!/usr/bin/python3, we can run any version of python installed on the machine for this script with sudo privileges. This led me to look into python2 vulnerabilities that are no longer present in python3. This led me to this writeup about python2’s vulnerabe input() function which is present in this script. I was able to leverage this for a fully interactive root shell:

In researching python vulnerabilities, I also found a second approach that works on python3 as well. This method focuses on Python Library Hijacking which leverages the hierarchy of directories in which python looks for libraries to import. The first place python checks is the local directory.

Since hashlib is imported in line 2 of test.py, we can write a simple script named hashlib.py that will be imported and executed whenever test.py is ran! Proof of concept:

And that’s how I found two ways to gain fully interactive root shells through python scripts that can be executed as sudo!

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Mitch Moser

Written by

digital brain | analog heart

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade