Smol
Test your enumeration skills on this boot-to-root machine.
Recon
We begin with an Nmap scan and discover only two open ports: 22 (SSH) and 80 (HTTP).
We have an SSH server running on 22 and a web server on port 80.
Upon accessing the site, we are redirected to www.smol.thm. To proceed, we need to add this domain to our /etc/hosts file.
The page appears minimalistic, featuring only static links. However, as we later discover, it provides all the necessary information to achieve Remote Code Execution (RCE). The topics covered include XSS, SSRF, and RCE.
We attempted to discover additional virtual hosts using ffuf, but none were found.
The Feroxbuster directory scan reveals that the site runs WordPress, as indicated by directories like /wp-content/. Additionally, we discover the Smol plugin, which appears to be the namesake of the room.
We proceed with a WPScan, using an API key to generate a detailed report, including CVEs for detected vulnerabilities. A free API key can be obtained from wpscan.com.
We identify two vulnerabilities in Smol: one allowing XSS and another enabling SSRF to read system data. The WPScan report provides PoC payloads, requiring only minor adjustments to the host.
XSS
SSRF
Initial Access
Using the SSRF payload, we successfully retrieve wp-config.php, which contains database credentials for the user wpuser.
We use those credentials to login as wpuser.
Under Pages we find unpublished pages.
Here, we are dealing with Dolly, a plugin that revises code, it's worth inspecting its source code for potential vulnerabilities or backdoors.
We can examine the original Dolly plugin, which includes a hello.php file. We should search for this file to analyze its contents and identify any potential vulnerabilities or modifications.
We use the SSRF vulnerability again and read the hello.php file.
The eval PHP command stands out immediately, indicating potential security risks. The command is Base64-encoded, likely as an attempt at security through obscurity, which is ineffective. We can decode the Base64 string to analyze its actual functionality.
We decode using Cyberchef and see a part encoded again.
Decoding \143\x6d\144 gives us 'cmd'.
By calling hello_dolly(), we might be able to pass a cmd parameter and achieve remote code execution (RCE). To test this, we prepare a reverse shell using busybox, then encode the payload in Base64 to bypass potential input filtering.
www-data
After some trial and error, we successfully execute commands via index.php?cmd. We pass our Base64-encoded reverse shell, ensuring our listener is set up beforehand. We get a shell back as www-data, but there's no flag in sight yet.
Since we have the database user credentials, we check the database for any useful information.
We extract the hashes and attempt to crack them using hashcat or John the Ripper.
diego
With the cracked password, we switch to the user Diego using su and locate the first flag in Diego's home directory.
Privilege Escalation
think
Checking the home directory permissions, we see that the "internal" group has read access. Since Diego is part of this group, we can read files within other users' home directories.
This allows us to read Think's SSH key, which we can use to switch to their user account.
We copy the key to our machine, adjust the permissions, and use it to log in as Think via SSH.
gege
Since only Gege has read permissions for the zip file, we need to find a way to access its contents. This old WordPress instance might contain useful credentials or configuration files that could help us move laterally.
Since we can switch to Gege using su, we now have access to the zip file in their home directory. The reason behind this unintended privilege escalation is due to a misconfiguration in /etc/pam.d/su.
xavi
Now that we have access as Gege, we can retrieve the wordpress.old.zip file. This archived instance of WordPress might contain old credentials, configuration files, or other sensitive data that could help us escalate further.
This is password encrypted.
We use zip2john to generate a hash.
We can now crack it using john with rockyout.txt.
The old wp-config.php file contains database credentials for the user xavi, who also exists on the system. We can try switching to this user using su .
We can switch to the xavi user using su. Now, we can explore their home directory and check for further privilege escalation opportunities.
root
Since xavi has unrestricted sudo privileges, we can escalate to root by simply running:
Now, we have full control over the system. We navigate to /root and retrieve the final flag.
Last updated
Was this helpful?