Academy — HackTheBox WalkThrough
This is a practical Walkthrough of “Academy” machine from HackTheBox. Although this machine is marked as easy level, but for me it was kind a medium level. Credit goes to egre55 and mrb3n for making this machine available to us and base points are 20 for this machine.
This walkthrough will be explanatory, because I learned a lot of new things from this machine. So, don’t mind my blabbering.
Passwords, hashes and Flags will be redacted to encourage you to solve those challenges on your own.
Enumeration
We will kick off this machine with enumerating using nmap.
We got two open ports SSH and HTTP and nmap http-title is redirecting to a domain. We need to add that to our hosts file.
I ran nmap again with hostname as target, but unfortunately I got the same result.
Let’s run GoBuster and brute force file/directory.
Aight, we got ‘admin.php’ on target, if we visit that page, then we’d see the login page for admin user and there’s nothing juicy in page source.
If we visit access the HTTP service via browser, then we’d get a web page with Login and Register button.
I even tried robots.txt, but unfortunately it’s not available on server. Even the page source didn't have any juicy information. Let’s visit register page and check its page source.
Aight, we got something juicy. It’s a hidden field with roleID value and it’s hardcoded, so we can change the ID. They might have restricted the permission for user based on roleID. Default value is ‘0’, probably for regular user and if we change it to ‘1’ we might get higher (admin) access.
TL;DR — <input type=”hidden”>
A hidden field let web developers include data that cannot be seen or modified by users when a form is submitted.
A hidden field often stores what database record that needs to be updated when the form is submitted.
Note: While the value is not displayed to the user in the page’s content, it is visible (and can be edited) using any browser’s developer tools or “View Source” functionality. Do not use hidden inputs as a form of security! Source
Let’s fire up BurpSuite and intercept the new registration page.
Now send this to repeater and change the roleid=1 and send send the request to get the reponses.
As you can see, the response code is 200 OK, that means it accepted the roleid which we sent. If it gives you response code 302, the change the ID # and try again.
Now we need to access admin.php page and try our new credentials.
It worked and we got this above planner, where couple project status are done and one is pending, and it’s a virtual host. Initially I though this admin section would lead me to any kind of upload section where I can push webshells to get reverse connection.
Let’s add this virtual host to our hosts file.
Let’s access the virtual host via browser and find what it holds.
This virtual host is dedicated to errors and logs. It’s also showing the environment variables of PHP web framework Laravel. If we scroll through, then we get the application name, APP key and DB creds.
If we just google “Laravel App Key Vulnerability” then we see a lot of results pointing to an RCE which is based on Unserialize Token RCE (CVE-2018–15133).
TL;DR — CVE-2018–15133
In Laravel Framework through 5.5.40 and 5.6.x through 5.6.29, remote code execution might occur as a result of an unserialize call on a potentially untrusted X-XSRF-TOKEN value. This involves the decrypt method in Illuminate/Encryption/Encrypter.php and PendingBroadcast in gadgetchains/Laravel/RCE/3/chain.php in phpggc. The attacker must know the application key, which normally would never occur, but could happen if the attacker previously had privileged access or successfully accomplished a previous attack.
We have the APP Key to try this RCE. On GitHub a lot of PoC code is available, but I’d go with Metasploit as it is stable and tested. Fire up the msfconsole and search for “laravel”.
There’s only one matching exploit module available. Let’s set all the options and run it on target host.
Options to Set in Metasploit
APP_Key
VHOST
RHOSTS
LHOSTS
Aight, we got the reverse shell. Let’s start with home directory and find any user accounts.
We got couple users with their home directory. If we remember “Academy Launch Planner”, they have mentioned two users “cry0l1t3” and “mrb3n”. We will try to enumerate them first.
User flag is inside cry0l1t3 home directory, but access is denied. We have to run PrivEsc enumeration tools. I ran Linpeas and LinEnum on target, but I couldn’t find any juicy information so far. I ran manual search for specific keyword and found some path.
The above command search for “password” keyword in /var/www/ directory, as this directory has many config files which might have saved credentials for any user or database.
The list is huge which consist of “password” keyword. If we read the environment (.env) file we get the DB Password.
It say’s “dev” user, but unfortunately we don’t have that user, but we can do trial and error on those two users which we initially found on planner. That password is of “cry0l1t3” user. Now we need to login via SSH or su.
We got the user flag, now we need to move to root flag. If we run sudo -l command to find if it’s in sudoers file or not.
Now we are in a different user than before, so let’s run Linpeas application and find any juicy information. After going through all the result, I found a user (mrb3n) credentials in an audit log.
Let’s Login using these new found credentials.
Now we need to move from this user to root. Let’s start with sudo -l.
Aight, we have a binary which can be run using sudo and might able to elevate privileges.
Let’s check, GTFOBINS for this binary.
Let’s follow the process.
We got all the flags required to complete this machine.
Thank you for reading this blog. While attempting this challenge I learned so many things. This was unique target with unique vulnerability.
