After quite a few Reversing challenges, it was time to get back to actual machines. This one was marked as Easy, and as we’ll see, that is mostly true. Note that you’ll need to configure an
/etc/hosts entry to point the machine IP to
spectra.htb for most of this to work.
Joining the machine and heading to the webpage reveals two links: One to an “Issue Tracker” and another to a Testing page. The Issue Tracker is revealed to be a standard Wordpress installation, while navigating to the Testing page gives us a Database Connection Error. It’s apparent that we’re still on a Wordpress page, but it can’t access the underlying database. At this point, it’s a good idea to run a basic
The only interesting thing revealed here is that XML RPC is enabled. We can abuse certain endpoints with the help of Metasploits
auxilliary/scanner/http/wordpress_xmlrpc_login, which allows bruteforcing Wordpress logins using the XML RPC API. On the off chance that the Wordpress installation uses default or easy credentials, I let this run in the background with rockyou.txt.
Moving back to the Testing page, we can actually move back one step into the directory and see that directory listings are enabled:
The directory listing is actually a big deal, because the Wordpress configuration file is sitting right there. Unfortunately, accessing the actual
wp-config.php simply returns a blank page (even on page source). Lucky for us, though, a backup exists right below it:
Looking at the page source of the backup, we can see the credentials for a database test user. We don’t have any way of accessing the underlying MySQL database at this stage, but I did attempt to log in as Wordpress administrator with the newly found password. It worked!
We now have access to the administration area of the Wordpress installation.
Moving from administration area to a reverse shell is very easy, thanks to (again) Metasploit and the
exploit/unix/webapp/wp_admin_shell_upload exploit. Just drop in the username and password of the Wordpress Admin and out comes a Meterpreter shell! Very easy. This drops us in as the
nginx user and we’ll quickly notice that we don’t actually have the flag. Instead, the user
katie has it.
At this point, I decided to drop my public SSH key into the available .ssh folder, creating
authorized_keys inthe process and giving “proper” access to the
nginx user. This was just for convenience, since all of this could be done from inside Meterpreter as well.
Enumeration is, as always, very important. My first choice for this is linPEAS. It immediately flagged the passwd files:
/etc/passwd /etc/autologin/passwd /etc/pam.d/passwd
What sticks out here is the
/etc/autologin/passwd file; this is not part of a standard Linux distribution. Reading it with
cat reveals a password, but no username. It turned out to be katie’s SSH password, which gives us access to our first flag!
Now that we have access to Katie and scored our first flag, we should do two things:
sudo -lto see if we can execute any commands without a password.
- Run linPEAS again to find any interesting files/directories.
sudo -l shows us that we can execute
/sbin/initctl without a password.
initctl is used to initialize a range of scripts residing in
/etc/init; those are normally reserved for root/root. Moving into
/etc/init, however, we can see a lot of
test*.conf files that are part of the
developers group (which we are also a part of). Running
sudo /sbin/initctl list | grep test shows us which of these scripts is running, while
stop allows us to start or stop any execution of the config files.
Getting a shell is as simple as setting our Group ID on
description "Test node.js server" author "katie" start on filesystem or runlevel  stop on shutdown script chmod +s /bin/bash end script
After running whichever test configuration we chose to sacrifice, we should be able to execute
/bin/bash in privileged (-p) mode:
katie@spectra /etc/init $ /bin/bash -p bash-4.3# whoami root
/etc/init configuration file should automatically be reset after it’s been executed. If not, please remove it. I picked up the flag in
tmp/root.txt first time around becauses someone left a dirty configuration file laying about.
True to its name, this machine was very easy. Using LinPEAS on these machines does feel like cheating sometimes, but I guess it’s time to try some Medium/Hard machines at some point.