Silver
Recon
First thing I did was add the target IP 10.67.149.182 to /etc/hosts as silver.thm, then pinged it to confirm connectivity before doing anything else.
With connectivity confirmed, I kicked off an nmap scan for network recon.
Scan wasn't the most comprehensive, but it gave us what we needed. Three open ports:
- 22/tcp - OpenSSH 8.9p1 (Ubuntu)
- 80/tcp - nginx 1.18.0
- 8080/tcp - http-proxy (unrecognized service)
The port 8080 service returning 404s and some unusual fingerprint data was worth noting for later. I started browsing port 80 and found a contact form that leaked a potential username and a reference to something called Silverpeas. I noted the username and flagged Silverpeas for further investigation.
Directory Enumeration
I ran gobuster against port 80 using the dirb/big.txt wordlist with 50 threads.
Only /assets and /images came back with 301 redirects, nothing that interesting. Still, I kept poking around manually and confirmed that /silverpeas exists as a directory. It returns unauthorized on port 80, but port 8080 has a redirect that makes it accessible. That's where I headed next.
Authentication Bypass - CVE-2024-36042
Browsing to port 8080 brought up a defaultLogin.jsp auth portal for Silverpeas. I looked it up and found a documented auth bypass.
CVE-2024-36042 affects Silverpeas before version 6.3.5. The vulnerability lives in the AuthenticationServlet and allows unauthenticated access by simply omitting the Password field from the POST request, sometimes granting superadmin-level access. Simple and brutal.
I loaded up Burp Suite to intercept the login request.
I entered the valid username discovered earlier with a dummy password, then intercepted the POST request through Burp Proxy.
The intercepted request goes to /silverpeas/AuthenticationServlet on port 8080. The body contains Login=scr1ptkiddy&Password=3333333333&DomainId=0&X-STKN=.... To exploit the bypass, I deleted the value of the Password parameter, leaving it empty (Password=), and forwarded the request. That was it.
We're in as scr1ptkiddy. The landing page also shows a banner for 1 unread notification which I made note of for later.
Enumeration Inside Silverpeas
With access to the portal, I browsed to the Directory section to see what users were registered.
Three users: Manager Manager, scr1ptkiddy scr1ptkiddy, and Administrateur. The admin account lists the email silveradmin@localhost. I now have a confirmed admin username to work with.
IDOR - Accessing Admin Notifications
Going back to that unread notification, I clicked into it and noticed the URL had a parameter with a very low ID value: ID=5. Low entropy like that is a dead giveaway for an Insecure Direct Object Reference vulnerability. I started iterating through adjacent IDs manually.
Changing the ID to 6 pulled up the admin's notification inbox.
The admin left SSH credentials in a notification to another user. The message reads: Username: tim and includes the password in plaintext. ID=3 had another message but nothing useful. Sequential IDs really are fun to play with.
Initial Access - SSH as Tim
I SSH'd into Tim's account using the credentials pulled from the IDOR.
User flag was low-hanging fruit sitting right in ~/user.txt. Now time to work on priv esc.
Privilege Escalation
Transferring LinPEAS
I spun up a Python HTTP server on port 8081 from my local machine's ~/Downloads directory where LinPEAS was stored.
On the target, I used wget from /tmp to pull the script over from my attacking machine at 192.168.206.16.
After downloading, I changed the permissions to make it executable and ran it with -s 2>/dev/null to suppress stderr and keep the output clean, only showing useful findings.
LinPEAS kept failing partway through for some reason, so I moved on to manual enumeration. I checked /etc/passwd for other users on the box and found tyler. That gave me a new target for lateral movement.
Credential Discovery in Auth Logs
I checked the auth logs for anything useful.
The logs showed tyler running a docker run command with -e POSTGRES_PASSWORD=Zd_zx7N823/ passed as an environment variable in plaintext. That's a credential exposure straight out of the sudo history.
People reuse passwords. I tried logging into tyler's account with that postgres password.
Lateral Movement to Tyler
I switched users from tim to tyler using the password pulled from the docker command in the auth logs.
It worked. From there, I ran sudo -l to check what commands tyler could run as root.
Tyler had (ALL : ALL) ALL, meaning full sudo access. I ran sudo cat /root/root.txt and grabbed the root flag.
Summary
This box chained together a few interesting techniques. The Silverpeas auth bypass via CVE-2024-36042 was the entry point, and the IDOR on the notification system handed over SSH credentials without needing to brute force anything. Post-exploitation was straightforward: LinPEAS assisted with enumeration, auth logs leaked a postgres password in plaintext, password reuse got us to tyler, and tyler's unrestricted sudo access closed it out.
| Step | Technique |
|---|---|
| Recon | nmap, gobuster, manual browsing |
| Initial foothold | CVE-2024-36042 auth bypass (Silverpeas) |
| Credential access | IDOR on notification endpoint (ID enumeration) |
| SSH access | Credentials leaked via IDOR |
| Privilege escalation | Plaintext creds in auth logs, password reuse, sudo -l |