Academy
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.91.177
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-07 04:44 EDT
Stats: 0:00:00 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 10.11% done; ETC: 04:44 (0:00:00 remaining)
Nmap scan report for academy.htb (10.129.91.177)
Host is up (0.0092s latency).
Not shown: 65532 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
33060/tcp open mysqlxWe have to add academy.htb to our /etc/hosts file to visit the HTTP site.
Port 80
This box was created to introduce HTB Academy I think:
There is a Login and Register page. We can try to register a user since we don't have credentials. While intercepting responses, we can see the HTTP request for registering:
There's a roleid parameter which we can change to 1 and see what happens. When logged in, it shows a lot of HTB Academy related content:
This was a PHP site, so I started a gobuster scan to enumerate the possible directories:
Because of the changed roleid parameter earlier, we can access the admin.php page:
There was another subdomain present on the site.
Laravel RCE
When we visit the new domain, we are greeted with a Laravel debuggin issue:
On this page, we can find a load of information, even the APP_KEY used for the website:
Googling the term 'Laravel exploit with APP_KEY' returned this Github Repo:
This CVE works!
We can then get an easy reverse shell as www-data.
Privilege Escalation
Credentials
There were a lot of users present on this machine:
The cry0l1t3 user had the user flag, which we could not read yet. While checking the /var/www/html/academy directory, we can find a .env file:
Within it, there were some credentials.
We can su to cry0l1t3 with this password and grab the user flag.
Audit Logs
This user was the only user part of the adm group.
This means we have permissions to read logs within the /var/log directory. Within that directory, I used grep to check for words like password and bash, as there might be logs where the user executed commands.
The audit directory is not an original Linux log file. Within the audit.log file, I found that the user mrb3n was executing commands:
There are also some commands that are encoded in hex for some reason. While looking at audit.log.3, I found this command:
When decoded, this gives a password:
We can then su to mrb3n.
Composer SUID
When checking sudo privileges for mrb3n, we find out that composer can be run as root.
Based on GTFOBins, we can run this to get a root shell:
Rooted!