BlueWings - HackingHub

I recently completed the BlueWings hub on hackinghub and decided to post a writeup about it as I used these misconfigurations multiple times on multiple bug bounty targets and during several penetration tests.

BlueWings is an innovative energy drink designed to keep hackers energized and focused late into the night! However, there has been a misconfiguration, leaving two Tomcat servers exposed, with one of them running Jolokia.

Scope:

• *.fh23w51c.bluewings.ctfio.com

Upon browsing to http://fh23w51c.bluewings.ctfio.com/, we see the following page.

Upon looking in BurpSuite, we see the Server header indicating nginx/1.18.0 (Ubuntu)

Upon inspecting the functionality on the website, we find a link to Staff Login which links to http://fh23w51c.bluewings.ctfio.com/staff. Upon visiting this, we are greeted with the following page.

This presents us some kind of login panel. After trying to access directories that may behind the login panel such as /staff/members, we are greeted with a 404-page that reveals the Tomcat version, namely 9.0.82.

Note that this also could have been detected by using this Nuclei template.

Since this is Tomcat, a well-known way to get remote code execution is by uploading a malicious .war file in the Tomcat Manager interface (often exposed at /manager/html). But since only the requests to the /staff/ directory seem to be handled by Tomcat, we have to traverse directories in order to be able to reach /manager/html. Upon reading HackTricks’ Tomcat page, I noticed a path traversal chapter. It stated the following:

In some vulnerable configurations of Tomcat you can gain access to protected directories in Tomcat using the path: /..;/

Web servers and reverse proxies normalize the request path. For example, the path /image/../image/ is normalized to /images/. When Apache Tomcat is used together with a reverse proxy such as nginx (as is the case here) there potentially is a normalization inconsistency. Tomcat will threat the sequence /..;/ as /../ and normalize the path while reverse proxies will not normalize this sequence and send it to Apache Tomcat as it is. This allows an attacker to access Apache Tomcat resources that are not normally accessible via the reverse proxy mapping. This can remediated by configuring the reverse proxy to reject paths that contain the Tomcat path parameter character ;.

This can also be identified using this Nuclei template.

The next step is trying to access the manager interface by going to http://fh23w51c.bluewings.ctfio.com/staff/..;/manager/html. As shown in the image below, this appears to be working as we are greeted with a login dialog.

I then wrote the following Python script that tried the default credentials listed by HackTricks’ Tomcat page.

import base64
import requests
import sys


def do_login(username, password):
    url = "http://7kjo02z1.bluewings.ctfio.com:80/staff/..;/manager/html"

    basic_auth = f"{username}:{password}"
    b64_basic_auth = base64.b64encode(basic_auth.encode("utf-8")).decode()

    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0",
        "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
        "Accept-Language": "en-US,en;q=0.5",
        "Accept-Encoding": "gzip, deflate, br",
        "Connection": "close",
        "Upgrade-Insecure-Requests": "1",
        "Authorization": f"Basic {b64_basic_auth}"
    }

    r = requests.get(url, headers=headers)

    if r.status_code != 401:
        print(f"[+] Logged in Successfully with username: {username} and password: {password}")
        sys.exit()
    else:
        print(f"[!] Log in failed with username: {username} and password: {password}")


def main():
    usernames = ["admin", "tomcat", "tomcatgui"]
    passwords = ["admin", "", "tomcat", "s3cr3t"]

    for username in usernames:
        for password in passwords:
            do_login(username, password)

  
if __name__ == "__main__":
    main()

But unfortunately, none of the default credentials seemed to be working.

I then resorted to enumerating web directories using ffuf. I personally used quickhits.txt from SecLists

ffuf -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0" -w quickhits.txt -u http://fh23w51c.bluewings.ctfio.com:80/staff/..\;/FUZZ

This revealed a new, and potentially interesting, web directory named jolokia.

Upon inspecting this, I got the following response, which is a typical response for Jolokia:

Jolokia is a JMX-HTTP bridge giving an alternative to JSR-160 connectors. It is an agent based approach with support for many platforms. In addition to basic JMX operations it enhances JMX remoting with unique features like bulk requests and fine grained security policies.

Upon Googling for vulnerabilities related to Jolokia, I bumped into the Jolokia Exploitation Toolkit. This contained a folder named exploits, which contained descriptions and proof of concepts of Exploits against Jolokia. I tried the first one which tries to load a new compiler directive. The result will be a “Bad format for file X” error message, while the content is included in this error message. Using this, I was able to read the /etc/passwd file.

Notice that this could also be verified using the following Nuclei template.

Although reading /etc/passwd is nice, our goal is to gain a shell on the hackinghub. Since we are able to reach /manager/html via the /..;/ sequence, we can try and read the tomcat-users.xml file. This file is known for containing roles, usernames and passwords for Tomcat users.

But since we do not know the exact location of this file, I decided to pull a Tomcat Docker image to inspect the filesystem.

After pulling the image, we start a container running our Tomcat instance.

We then list all Docker containers to identify our Tomcat container, and gain a root shell into it by executing the following command:

docker exec -it <CONTAINER ID> bash

After doing this, we land in the /usr/local/tomcat directory. Doing a ls reveals the conf directory which contains our target, namely tomcat-users.xml.

We can then try reading this file using the Jolokia exploit we identified earlier. Which appears to be working as we get the xml file containing usernames and passwords back.

With the exposed password for tomcatgui, I was able to login to the Tomcat Manager.

A known way to get command execution is by uploading a malicious WAR file in the Tomcat manager. I decided to create a WAR file containing a webshell.

If we try uploading the webshell directly from the manager interface, we get an error. If we intercept this request with Burpsuite, we quickly identify the problem. The upload points to /manager/html, while we need to use our /..;/ sequence to reach the manager.

So we need to update the request path to look like the following.

After doing this, our malicious WAR file gets uploaded successfully.

We can then browse to it, and use it to execute commands. It appears that this Tomcat instance is running as root, meaning we completely compromised this hackinghub.