Knowing that usually HTB machines fancy some web app on port 80, even before running an nmap scan I check if there is some domain redirect: curl http://10.10.11.20 -v

And we have the results:

Now to explore this web app I added 10.10.11.20 to hosts:

sudo bash -c "echo '10.10.11.20 editorial.htb' >> /etc/hosts"

So now we can explore the web app. And while I do that in the background I still launch an nmap scan, just in case there is something else:

nmap -vv -A -Pn -p- 10.10.11.252 -sV

The web app looks basic, source code doesn't reveal anything that would stand out. What's looks promising is a page http://editorial.htb/upload with a web form. Firing up burp suite and poking about.

The form action that is executed on 'Send book info' doesn't stand out, but the preview load for cover can hold some vulnerabilities. I uploaded an image to see if it's metadata would reveal some vuln like ImageMagic buggy version, but nothing came up.

And there's an input that takes an URL and supposedly it loads an image from the web and shows it's miniature.

After some fruitless experiments I decided to check if this form can fetch me something from the server. Request itself is a multipart form data and when localhost IP is submitted it responds with the placeholder image:

But what if there's some other web app on a different port running?

Since CE burp Intruder is soooo slow it would take forever to fuzz, so I used ffuf to do a quick fuzzing.

I saved raw request to request.txt, generated a file ports.txt for ports from 1 to 65536 on different lines and started the scan:

ffuf -u http://editorial.htb/upload-cover -X POST -request request.txt -w ports.txt

Standard response len is 61

So to filter it out I added a filter to ffuf:

ffuf -u http://editorial.htb/upload-cover -X POST -request request.txt -w ports.txt -fs 61

And it looks like port 5000 is open to localhost-based requests.

Now to check what's there:

Download & open this file, and I got some useful data finally.

Looks like some API response with a list of methods. One of them is particularly useful, because it has some credentials:

Try to ssh in with this l:p and success, we got the user flag:

Sadly but expectedly, user dev doesn't have sudo capabilities.

Privilege escalation

Quick check of apps dir showed that it contains a .git repository, and there is an uncommited change of deleting stuff from that dir. But git remembers everything, so I git log to see previous commits and here they are. Then I checked out to all five commits to scour through the files and look for some more honey, and in /home/dev/apps/app_api/app.py in it's previous version I fount yet another set of creds, now to prod user of this machine.

Now I can ssh or su to prod user, and look for privesc vector there, and it looks promising from the start: prod has some limited sudo usage allowed:

So it seems that user prod can run a python script that copies over a .git repo from remote, and there are some external protocols allowed. Here I did hit a rabbit hole with these protocols, I spent some time fruitlessly trying to make this script use a custom protocol I wrote as per git specs, but this little part in sudo wrecked that plan:

env_reset means that before sudo cmd is executed, environment and $PATH are reset to secure values, and my custom protocol needs to be on the path. Bummer.

So I started to poke around and google versions of stuff I found on the system in hopes that something is outdated and vulnerable. And it is, though not my first choice, I did pip3 list

and see that GitPython 3.1.29? Turns out it has a bug listed as CVE-2022-24439 that allows the attacker to execute arbitrary code like this:

sudo /usr/bin/python3 /opt/internal_apps/clone_changes/clone_prod_change.py 'ext::sh -c cat% /root/root.txt% >% /tmp/root'

% sign is used to escape space char. What it does is this: it sends output of cmd cat /root/root.txt to file /tmp/root, where it can be read by non-privileged users. And that gives the admin flag.

Thx 4 reading!