HackTheBox — Spectra

Spectra is a retired HackTheBox machine that was ranked as “Easy”. It covered multiple simple vulnerabilities including directory listings, information leakage, clear-text credential leakage, remote code execution via WordPress plugin, and over-privileged sudo abilities.

HackTheBox — Spectra
Spectra HTB

Spectra is a retired HackTheBox machine that was ranked as “Easy”. It covered multiple simple vulnerabilities including directory listings, information leakage, clear-text credential leakage, remote code execution via WordPress plugin, and over-privileged sudo abilities.


Recon/Enum

A quick Nmap scan will show that TCP ports 22 (SSH) and 80 (HTTP) are open externally. Navigating to 80, we are greeted by a pretty rough looking page with two links and some mention about work being done. One leads us to the /testing/index.php page, the other takes us to a functioning WordPress blog at /main/ . Noticing that the URL is not properly hidden on the /testing/ directory, we should check to see if there is listing available.

Directory Listing of /testing

One of the first files that stands out here is wp-config.php.save. This file, if opened, shouldn’t execute the PHP and show us the full file contents. Opening the file provides us with credentials to access a MySQL server as a devtest user with devteam01 as the password. We can try this against the MySQL service exposed but are not successful.

Navigating over to the /main/ directory of the web application, we can see that multiple posts have been created by a single user, administrator. Attempting to log in to the WordPress administrative dashboard with the credentials we found is unsuccessful, however supplying administrator and devteam01 gives us access!


Initial Access

Album: Louis Armstrong — Hello Dolly

Navigating around the WordPress dashboard, you’ll find a couple of plugins installed. One of which is Akismet Anti-Spam, and the other is Hello Dolly. If we go to the Plugin Editor and choose the Hello Dolly plugin we can observe that we have the ability to edit the raw PHP being executed in this plugin.

Simply insert your malicious command in the hello_dolly function, and it will be executed every time a page loads in the admin dashboard workflow. The plugin’s intended function is to give the user a nice lyric from the popular song in the dashboard header area.

Remote Code Execution

Here, we’re using a reverse shell one liner and specifying the socket/file descriptor #5. With a listener active on our attack machine, we go ahead and click the Update File button. Navigating to any page in the admin dashboard will trigger our reverse shell.

Receive your callback

If you are enjoying this article your support would be greatly appreciated!


Privilege Escalation (User)

So, we have execution on the system, but we are restricted to the access granted to the nginx user account. There are many things you can and should do once gaining access to a system to find interesting information. I usually check sudo privileges, check groups, users, look for config files, backups, suid/guid binaries, etc. If you are unhappy with your shell, peeking around for a python binary will net you a better experience. Simply execute the following to get a more interactive shell:

$ /usr/bin/python3 -c "import pty;pty.spawn('/bin/bash');"

With a better shell in hand, hopefully you’ll stumble across the /opt/autologin.conf.orig file, which mentions two file locations. The first is /mnt/stateful_partition/etc/autologin/passwd, the second /etc/autologin/passwd. Checking the latter reveals a password in clear-text. We can use this password to SSH into the machine as the katie user.

autologin.conf.orig Contents

Privilege Escalation (Root)

Now that we have the katie user (grab your flag by the way), it is time to work toward becoming root. One of the first things I like to check for is the current user’s sudo privileges with sudo -l. In this scenario, katie has the ability to execute /sbin/initctl as root without supplying a password via sudo. Some light googling will show plenty of information about escalating privileges with initctl so we won’t spend a lot of time explaining that here. We just need to know which services we have write privileges over.

Enumerating the services in the /etc/init directory shows a collection of test* services that give read/write privileges to the developers group. Checking /etc/groups and filtering on katie reveals that we are indeed a part of the developers group!

Checking Permissions

Now we just need to insert our malicious command into one of these test service definitions and start the service. For simplicity, I added chmod +s /bin/bash to the script block of the definition. This allows for executing bash as the owner of the file, root .

Malicious Service Definition

With the command inserted, we start the service and attempt to call /bin/bash -p to get our escalated shell. Go get your flag!

Root Shell

Final Thoughts

This was a fairly simple machine with a few gotchas along the way. The TCP file descriptor on the reverse shell took some time to iron out. This is a great example of doing basic enumeration and research to reach the goal at hand.