Silentium - CTF Writeup
Silentium - CTF Writeup
Reconnaissance
A full TCP scan exposed SSH and an nginx web server. The web server redirected to the virtual host silentium.htb.
1 | nmap -T4 -A -sS -sV -p- 10.129.9.0 |
| Port | Service | Version | Notes |
|---|---|---|---|
22/tcp |
SSH | OpenSSH 9.6p1 Ubuntu 3ubuntu13.15 | Ubuntu host |
80/tcp |
HTTP | nginx 1.24.0 | Redirects to silentium.htb |
Virtual host enumeration revealed another application:
1 | staging.silentium.htb |
Web Enumeration
The password reset flow on the staging host returned a useful backend error:
1 | Transaction is not started yet, start transaction before commiting or rolling it back |
The main site exposed a user named Ben, which gave a likely email address:
1 | ben@silentium.htb |
The staging application was running Flowise 3.0.5. This version is affected by CVE-2025-58434, where the password reset endpoint exposes a valid tempToken in the response. Using the leaked token, I reset Ben’s password and authenticated to the staging application.
Initial Access
After logging in to Flowise, I used the public Flowise 3.0.5 exploit to get command execution:
1 | python3 exploit.py \ |
The container did not have bash, so the shell had to be stabilized with ash:
1 | python3 -c 'import pty; pty.spawn("/bin/ash")' |
Container Enumeration
The full environment and database dumps were noisy. The important finding was that the container exposed SMTP credentials for the ben account:
1 | FLOWISE_USERNAME=ben |
The SMTP password was reused for SSH, which gave a stable shell as ben:
1 | ssh ben@silentium.htb |
Internal Services
From the host, several services were only listening locally:
| Address | Service | Notes |
|---|---|---|
127.0.0.1:3000 |
Flowise | Internal Flowise service |
127.0.0.1:3001 |
Gogs | Internal Git service |
127.0.0.1:1025 |
SMTP | MailHog SMTP |
127.0.0.1:8025 |
HTTP | MailHog web UI |
The Gogs configuration was readable from:
1 | /opt/gogs/gogs/custom/conf/app.ini |
The relevant settings were:
1 | RUN_USER = root |
The key detail is that Gogs runs as root and stores repositories under /root/gogs-repositories.
Privilege Escalation
After adding a public key through Gogs, SSH authentication as root reached the Gogs git shell instead of an interactive shell:
1 | Hi there, You've successfully authenticated, but Gogs does not provide shell access. |
That confirmed the key path was being handled by Gogs, but it did not directly provide root access.
The useful escalation path is the Gogs PutContents symlink issue tracked as CVE-2025-8110. With an authenticated Gogs user, the vulnerable API can be abused to write through a repository symlink. Because this instance runs as root, that write can target root-owned paths such as /root/.ssh/authorized_keys.
Useful target details:
1 | Gogs URL: http://staging-v2-code.dev.silentium.htb/ |
References: