This is my write-up for the box “Academy” from HackTheBox. The box was created by egre55 and mrb3n.
Enumeration
Initial Nmap scan
Nmap shows ports 22, 80 and 33060 open.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Nmap 7.91 scan initiated Sat Nov 7 19:18:21 2020 as: nmap -p22,80,33060 -sV -sC -Pn -T4 -oA 10.129.20.51 10.129.20.51
Nmap scan report for 10.129.20.51
Host is up (0.083s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 c0:90:a3:d8:35:25:6f:fa:33:06:cf:80:13:a0:a5:53 (RSA)
| 256 2a:d5:4b:d0:46:f0:ed:c9:3c:8d:f6:5d:ab:ae:77:96 (ECDSA)
|_ 256 e1:64:14:c3:cc:51:b2:3b:a6:28:a7:b1:ae:5f:45:35 (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Did not follow redirect to http://academy.htb/
33060/tcp open mysqlx?
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port33060-TCP:V=7.91%I=7%D=11/7%Time=5FA6F308%P=x86_64-pc-linux-gnu%r(G
SF:enericLines,9,"\x05\0\0\0\x0b\x08\x05\x1a\0")%r(Help,9,"\x05\0\0\0\x0b\
SF:x08\x05\x1a\0");
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Nov 7 19:21:06 2020 -- 1 IP address (1 host up) scanned in 164.67 seconds
Looking at port 80 in the browser while burp is running shows the following:
Fixing name resolution by adding hostname to resolve in /etc/hosts
In most HackTheBox machines it’s a good idea to add the name of the box to your /etc/hosts file. The format is usually boxname.htb and adding it is as simple as putting the IP and name of the box on the same line.
With that done, we can move onto capturing requests from the browser through burp suite to see what the website is doing under the hood.
The website is a mirror of the HackTheBox Academy training website and has a login and register button on the frontpage.
Directory searching with FeroxBuster
Looking for existing directories/resources on a website by hand can become cumbersome real quickly. Fortunately there are tools like gobuster, dirsearch or in this case feroxbuster, all of which make directory searching a breeze. Running the feroxbuster -u http://academy.htb -x php command yields a number of interesting results. With the -x option specified, feroxbuster is searching for files with a .php extension. The two results that stand out are home.php and admin.php. While the admin page only shows a login page, the home.php endpoint gives direct access to the academy page. Interestingly the user egre55 is logged in on the home page and the logout function doesn’t work.
Foothold
After some light enumeration and clicking around I’ve noticed that the request sent during the registration process includes an extra parameter that isn’t normally accessible by the user. Registering a new user sends the following POST request to the server:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
POST /register.php HTTP/1.1
Host: academy.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 51
Origin: http://academy.htb
Connection: close
Referer: http://academy.htb/register.php
Cookie: PHPSESSID=3p2jugl39733dq11i2medo05b4
Upgrade-Insecure-Requests: 1
uid=tux&password=password&confirm=password&roleid=0
Notice the roleid=0 parameter at the end of the request. This got me curious, so I changed it from 0 to 1 while registering a new user. With this trick, it’s possible to register an “admin” user and so logging in at the admin.php page shows the following “Academy Launch Planner”:
The chart lists a number of tasks being done and one pending. Supposedly there is an issue with something called dev-staging-01.academy.htb . This piece of string is a domain name and it looks very similar to the one we added to the /etc/hosts at the beginning. Adding it to the file enables our browser to reach the site located at dev-staging-01 subdomain.
The dev-staging page shows some kind of laravel debug information. After searching for exploits, I’ve found that metasploit has a module for gaining access via laravel. The module is called laravel_token_unserialize_exec and it exploits a vulnerability in the PHP Laravel Framework to achieve remote command execution. For the exploit to succeed we need an APP key. Fortunately the key is exposed on the laravel page, so getting a shell on the machine is just a matter of setting the correct options within metasploit:
- API_KEY =
<key_from_the_laravel_debug_page> - LHOST =
<Attacker-IP> - VHOST =
dev-staging-01.academy.htb
The result is a semi-stable shell on the machine as www-user
Lateral movement
After a lot of enumeration and falling for rabbit holes, I’ve found a pair of database credentials in the /var/www/html/academy/.env file. These credentials can be used to login to the user cry0l1t3.
Lateral movement #2
The cry0l1t3 user is part of the adm group, which means it has access to the /var/log folder. This is a place to enumerate. Now this step took me a very long time. I looked through every log file line by line and couldn’t find anything. After a lot of googling, I stumbled on the following blog:
A specific command is mentioned in the blog that can be used to look at linux login logs and see who tried to login with what password. Running aureport --tty shows mrb3n user’s password. With that password we can move onto the mrb3n user.
Privesc
mrb3n is capable of running /usr/bin/composer as root. This program is part of GTFObins and it’s very easy to exploit.
Following the GTFObins website, getting root privileges is only a matter of running a couple commands:
1
2
3
TF=$(mktemp -d)
echo '{"scripts":{"x":"/bin/sh -i 0<&3 1>&3 2>&3"}}' >$TF/composer.json
sudo composer --working-dir=$TF run-script x