Silver Platter
Can you breach the server?
Recon
We start with an Nmap scan and find three open ports. Port 22 on which we have SSH available, port 80 to an nginx web server and port 8080 to another web server.
While enumerating directories with Feroxbuster on the web server running on port 80, we did not discover any notable or useful results.
On the web server running on port 8080, we discover two directories: /website and /console. Both seem intriguing, but /console redirects to a static nodirect.html page, and /website redirects to /website/, which is restricted with a "Forbidden" error.
We look at the page manually on port 80.
Under the Contact section, we identify a potential user listed as the project manager for Silverpeas.
On the website on port 8080 we find nothing on the index page and /website redirects us to /website/, which is forbidden.
Multiple 403 bypass techniques and automated scripts proved ineffective. Given the username and a hint of potential brute-forcing in the room description, we attempted basic authentication brute-forcing using Hydra, but this also failed.
Initial Access
However, the contact form reference to Silverpeas proves useful. Entering it as a directory at http://silverplatter.thm:8080/ results in a hit—a Silverpeas login page. While there are known CVEs for Silverpeas, they are not required for this challenge.
Now we capture a log in request to craft our hydra command.
We forward the intercepted login request to capture the server's invalid response message, which can help us identify any clues or patterns to fine-tune our brute-force attack.
We are able to log in as scr1ptkiddy at Silverpeas.
After logging in as scr1ptkiddy, we notice a single notification displayed on the dashboard.
In the personal workspace, we can inspect our notifications.
Shell as Tim
We intercept the request of inspecting the message and see that an ID is queried, here ID 5.
Upon discovering an IDOR (Insecure Direct Object Reference), we exploit it to inspect the messages of other users. In particular, we find that the message with ID 6 contains the SSH credentials for the user tim.
Next, we use those credentials to log in via SSH.
We find the user flag in the home directory of the user tim.
Privilege Escalation
By examining Tim's group memberships, we find that he is part of the adm group, which grants him access to view logs located in /var/logs. This could potentially contain sensitive information that might help us escalate privileges further.
There is also the user tyler.
Shell as Tyler
So lets search for entries of the user tyler.
And we do find some database credentials. Maybe they are reused.
We successfully switched to the user tyler using those credentials.
The user is granted permission to run any command as root without a password. We use sudo su to switch to root, navigate to the root directory, and find the final flag.
Last updated
Was this helpful?