HackTheBox: Academy

HackTheBox: Academy

Can you compromise the Academy?

·

4 min read

Introduction

Academy is rated as an Easy difficulty box on HackTheBox created by egre55 and mrb3n. In no particular order; key points of this box include authentication bypass, a couple cases of sensitive data exposure, excessive user permissions, and taking advantage of a vulnerable WebApp framework. So without much further ado lets get into it!

Machine link here:: app.hackthebox.eu/machines/297

Enumeration

With our initial nmap scan we uncover two open ports; SSH on 22 and Apache on 80

001.png

However I also started up a full port scan set to run after the initial scan completes.. For the initial full port scan we don't run any scripts or try to fingerprint the service, we're just looking for open ports.

nmap -p- --min-rate=3000 --max-retries=5 -vv -oN allPorts.nmap <IP_Address>

After that runs we see another open port on 33060. Now that we don't have to run through all 35565 possible ports we can use the default scripts and versioning to fingerprint the open port on 33060.

Nmap thinks its some kind of mysql but that doesn't seem correct. It does manage to pull out some readable strings that seem pretty interesting.. After a bit of googling it becomes clear that we may be looking at a DNS over TLS (DoT) service on this port 33060.

002.png

Initial Compromise

When inspecting the requests for user registration(which is one of the few things on this site that actually appears functional) we notice a role parameter that wasn't obvious from the page itself. So just for fun we try increasing our roleid to 1 and registering a new user.

003.png

There's no perceptible change at first but now when we try logging in through /admin.php we actually get through.

004.png

So we add in dev-staging-01.academy.htb to our /etc/hosts file. We're instantly greeted with a number of errors, seemingly relating to improper permissions to a laravel.log file. More interestingly we also get a glimpse at number of environmental variables for the webserver..looks like we're running in the PHP framework known as Laravel.

005.png

Checking searchsploit it looks like there's a metasploit module that leads to RCE that may be worth checking out

006.png

007.png

Lateral Movement

Using the Metasploit module we're able to gain a shell on the target machine as www-data. Now that we're on the box as a service account its time to move to a user account.

It looks like cry0l1t3 is definitely one of our targets since they have the user.txt flag. We can't access it yet but this does help us focus our efforts.

008.png

While sifting through the linpeas results we spot a possible credential.

009.png

At this point we're still trying to get the mysql service to allow us to login so we try that first but without any luck..

Afterwards we try switching user to cry0l1t3 using these creds and it actually works. Password spray ftw!

Lateral Movement 2

We can now loot the user.txt flag and we also notice that we're a part of the adm group. This is not a group for regular users to be added to since they can now check out the contents of things like syslog, access logs, and error logs..but this is great for us as an attacker.

010.png

When we first start looking through /var/log there's a lot of data to sift through. Most of the logs have been polluted through our own automated enumeration techniques with feroxbuster and the like..

011.png

It can even be used to check the keystrokes used on tty terminals like this: aureport --tty

012.png

NOTE: As a more targeted method we can also use ausearch -c su where the -c switch allows us to specify a command line name. The data is the a hex-encoded representation of the user input that we can decrypt using xxd -p -r We can also tell by the uid=1002 that this was a command performed by our current user cry0l1t3 Either way if we can access logs we can look back in time to see what types of commands have been run on this system.

013.png

NOTE: You can also run the ausearch command with the -i flag and it will automatically ‘interpret’ the hex for you.

014.png

Anyhow, we try switching user to mrb3n and we succeed! Not only that but we find mrb3n can run composer as anyone...even root.

015.png

Privilege Escalation to root

A quick trip to gtfobins later and we have an escalation path to root with the following:: It's basically just gonna make a temp directory to call later, inject an interactive shell into a composer.json file and then call that file with sudo composer while specifying it's location.

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

After executing the above commands we can about wrap it up because we've got root. Now to do some final cleanup, answer some lingering questions and write our report.

016.png