Hacking Insights by Max Bautista

Academy writeup

Box name: Academy

Difficulty: Easy

OS: Linux

Overview: Academy is an easy difficulty Linux machine that features an Apache server hosting a PHP website. The website is found to be the HTB Academy learning platform. Capturing the user registration request in Burp reveals that we are able to modify the Role ID, which allows us to access an admin portal. This reveals a vhost, that is found to be running on Laravel. Laravel debug mode is enabled, the exposed API Key and vulnerable version of Laravel allow us carry out a deserialization attack that results in Remote Code Execution. Examination of the Laravel .env file for another application reveals a password that is found to work for the cry0l1t3 user, who is a member of the adm group. This allows us to read system logs, and the TTY input audit logs reveals the password for the mrb3n user. mrb3n has been granted permission to execute composer as root using sudo, which we can leverage in order to escalate our privileges.

Link: https://app.hackthebox.com/machines/Academy?sort_by=created_at&sort_type=desc

Machine IP: 10.129.39.22

Ran rustscan against the machine.

rustscan -a 10.129.39.22 –ulimit 5000 -b 2000 — -A -Pn 

Added academy.htb to /etc/hosts. Navigated to the site, it looks like an old HTB Academy site. There’s a /login.php and /register.php.

Registered with a test account kami:kami and I could log in. It looks exactly like Academy lol, this might be a sign for me to spend more time in academy.

It’s not quite that interactive though. Ran feroxbuster.

feroxbuster -u http://academy.htb/ -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400

This found a /admin.php for us.

We unfortunately don’t have access. After poking around and reviewing how we register accounts in Burp we can see a role id parameter when creating. Set that to 1 to create another account.

For some reason it wasn’t working through Burp. I sent a curl instead.

curl -s -L -X POST http://academy.htb/register.php -H “Cookie: PHPSESSID=bpumebq1tplvg11mj467c34fd1” -H “Content-Type: application/x-www-form-urlencoded” –data “uid=kami5&password=kami5&confirm=kami5&roleid=1”

And I was able to log in.

This mentions a dev-staging-01.academy.htb. Added it to /etc/hosts and navigated to it.

We can see a mention of Laravel. It looks like we couldn’t yet find a version. In Metasploit I found a possible exploit though.

Looked at the options. It asks for an APP_KEY and we can get that from the site. Filled out the options.

And I got a shell.

After poking around it looks like I found some creds.

Checked out possible users.

I was able to get into cry0l1t3 with that password mySup3rP4s5w0rd!!

It also looks like we are in the adm group which we can read logs.

In the logs we were eventually able to find mrb3n’s creds.

mrb3n:mrb3n_Ac@d3my!

As mrb3n, ran sudo -l for a quick win and we can run /usr/bin/composer as root.

Checked out GTFObins https://gtfobins.org/gtfobins/composer/#shell.

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.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 80 (HTTP), and 33060 (MySQL X Protocol). Added academy.htb to /etc/hosts. Browsed to the site and found a registration and login page modeled after HTB Academy. Ran feroxbuster and discovered an /admin.php endpoint.

rustscan -a 10.129.39.22 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://academy.htb/ -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion

2 – Role ID manipulation and admin access Registered a test account and logged in. Intercepted the registration request in Burp and identified a hidden roleid parameter. Sending roleid=1 during registration created an admin account. Standard Burp interception had issues so used curl to send the modified request directly. Logged in with the admin account and accessed /admin.php which referenced a dev-staging-01.academy.htb vhost.

curl -s -L -X POST http://academy.htb/register.php –data “uid=kami5&password=kami5&confirm=kami5&roleid=1”

3 – Initial Access – Laravel deserialization RCE Added dev-staging-01.academy.htb to /etc/hosts and browsed to it. Found a Laravel application in debug mode exposing the APP_KEY. Identified a Metasploit module for Laravel deserialization. Set the APP_KEY and target options and executed the module to obtain a shell as www-data.

4 – Lateral movement – .env credential reuse Enumerated the filesystem and found a Laravel .env file for another application containing a plaintext password. Checked /etc/passwd for valid users and tried the password on cry0l1t3. Authentication succeeded. Retrieved user.txt and confirmed membership in the adm group allowing log file access.

Credentials recovered: cry0l1t3:mySup3rP4s5w0rd!!

5 – Lateral movement – TTY audit log credential capture Read system logs as a member of the adm group. Found TTY input audit logs containing mrb3n’s password entered on the command line during a previous session.

Credentials recovered: mrb3n:mrb3n_Ac@d3my!

6 – Privilege Escalation – composer sudo abuse Authenticated as mrb3n and ran sudo -l. Found mrb3n could run /usr/bin/composer as root. Used the GTFOBins composer technique to define a malicious script in a temporary composer.json and executed it via sudo to drop into a root shell. Retrieved root.txt.

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

---

Key Takeaways

1. Unvalidated role parameter in registration endpoint – The roleid parameter was accepted from user-supplied POST data with no server-side authorization check, allowing any registering user to grant themselves admin privileges. Role assignment must always be performed server-side based on authenticated context and must never be controlled by client-supplied input.
   
2. Laravel debug mode enabled in a staging environment – CVE-2018-15133 (CVSS 8.1 High) – The dev-staging-01 vhost had Laravel debug mode active, exposing the APP_KEY and detailed error output. The APP_KEY combined with a vulnerable Laravel version enabled a deserialization RCE attack. Debug mode must be disabled in all environments accessible from untrusted networks and APP_KEY must be rotated immediately if exposed.
   
3. Plaintext credentials in a .env file readable after foothold – The Laravel .env file contained a plaintext password that was reused for the cry0l1t3 OS account. Environment files must have restrictive permissions and must be excluded from any directory accessible by the web server process. Credentials in .env files must be unique and not reused for OS accounts.
   
4. Credentials captured in TTY audit logs – mrb3n’s password was captured in audit log files because it was passed on the command line during a previous session. Credentials must never be passed as command-line arguments and audit logs must be restricted to authorized security personnel only.
   
5. composer sudo rule enabling shell escape – mrb3n could run composer as root with no restrictions. GTFOBins documents composer’s scripts functionality as a reliable shell escape path. Sudo rules for package managers and build tools must never be granted as they are universally exploitable for privilege escalation.
   

---

Remediation

[Immediate] Enforce server-side role assignment Remove the roleid parameter from the registration form entirely. Role assignment must be performed server-side using a default unprivileged role for all new registrations. Admin role elevation must require an explicit administrative action by an existing privileged user through a protected endpoint.

[Immediate] Disable Laravel debug mode and rotate the APP_KEY – CVE-2018-15133 (CVSS 8.1 High) Set APP_DEBUG=false in all Laravel .env files across all environments immediately. Generate a new APP_KEY and rotate it across all affected applications. Debug mode must never be enabled on any environment reachable from untrusted networks. Restrict access to staging environments to authorized IP ranges via firewall rules.

[Immediate] Restrict .env file permissions and rotate exposed credentials Set all .env files to mode 600 owned by the application service account. Rotate the credentials found in the .env file immediately and ensure the new credentials are unique to that application. Audit all web application directories for world or group readable environment files.

[Immediate] Remove the composer sudo rule Delete the sudoers entry allowing mrb3n to run composer as root. Package managers, build tools, and script runners must never be granted via sudo as they provide trivial shell escape paths. Audit all sudo configurations against GTFOBins and remove any entries that permit known escalation techniques.

[Short-term] Restrict audit log access and eliminate command-line credential passing Restrict audit log files to authorized security personnel only. Implement a policy and technical controls preventing credentials from being passed as command-line arguments. Use secure credential injection methods such as environment variables set from a secrets manager or interactive prompts that do not appear in logs or process listings.

[Long-term] Implement environment segregation and a secure development lifecycle Staging environments must be treated with the same security controls as production including debug mode enforcement, access restrictions, and credential isolation. Integrate security testing into the development pipeline covering insecure parameter handling, debug mode detection, and .env file exposure. Conduct regular penetration tests covering all web applications and their associated infrastructure.