🎨Creative

License

The following post by anthonyjsaab is licensed under CC BY 4.0arrow-up-right

0 - Introduction

Link to room: https://tryhackme.com/r/room/creativearrow-up-right

This writeup walks you through a room on TryHackMe created by tryhackme and ssaadakhtarr

1 - Scanning

1a - Nmap

1ai - Port Discovery

β”Œβ”€β”€(kaliγ‰Ώkali)-[~/Desktop]
└─$ sudo nmap 10.10.194.114 -sS -T5 -p-
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-04-22 10:11 EEST
Nmap scan report for 10.10.194.114
Host is up (0.11s latency).
Not shown: 65533 filtered tcp ports (no-response)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 130.06 seconds

1aii - Versioning

1aiii - Checking for vulnerabilities

1aiv - OS Fingerprinting

1b - Directory busting

1bi - Fixing /etc/hosts

Before executing a directory busting scan, we have to check if we can access the supposed website on the target machine normally. When we try, we find that the webserver returns this:

Thus, we should do:

Now if we browse the website, we can see this:

Landing page of the target's web server

1bii - Actual dirbusting

Dirbusting does not lead to anything useful

1c - Subdomain enumeration

1d - What we know so far

  • The target machine exposes 2 ports: 22 (ssh) and 80 (http)

  • The CVEs returned seem to be very useful.

  • Subdomain enumeration returned one interesting vhost to checkout

2 - beta.creative.thm

2a - First contact

beta.creative.thm

This webpage is very interesting. I spin up an HTTP server on my Kali machine to see what it really does:

The request log shown above was triggered by manually putting "http://10.11.85.12:8000arrow-up-right" in beta.creative.thm's input field and submitting. Here is the output on the browser:

Output of submitting the URL of my Kali machine in beta.creative.thm

Thus, the target machine seems to work like a forward proxy here.

2b - Python worker

Let us examine the behavior of this page further. Putting a URL to an inexistant file gives us the following:

Usual output from Python's http.server module after receiving a request to an inexistant resource
Output from the target when http://10.11.85.12:8000/foo is given as input to beta
Captured request that originated from the target machine's beta webpage

From the user-agent shown above, and from the difference in beta's behavior when given a good or bad URL, it seems like beta launches a Python worker to download the resource requested. Then, it would send it to us. When the Python worker receives a 404, it crashes or terminates gracefully.

2c - Internal Nmap and Proxy (kinda)

When we submit http://localhost or http://127.0.0.1 in beta, it correctly returns the creative.thm webpage. However, http://localhost:22 will return "Dead".

It means that beta can tell us whether a port is locally open and bound to 127.0.0.1 on the condition that it belongs to an HTTP server. We can use beta as an Nmap for HTTP servers, and the scan is launched from the target machine, not our IP address.

In the above code block, I've generated a list of all possible ports. Then, using a sample request-response pair from beta.creative.thm, I crafted a gobuster incantation that communicates correctly with the endpoint. It sends to the same endpoint 2^32 requests that differ only by the port included in the body. For any particular response, if the length is 13, it means the server returned "Dead". Thus, we excluded this case.

As we can see, we found that an HTTP server is bound to 127.0.0.1:1337 of the target machine.

When we request this page via our forward proxy (aka beta.creative.thm), we get this:

After submitting http://127.0.0.1:1337 to beta's landing page input field

Voila! The HTTP server at 127.0.0.1:1337 returns a directory listing at the root of the filesystem! This is cool. However, each time we want to access a file or change directory, we need to go back to beta's landing page and submit the new path. It is not quite like a shell.

Unfortunately, we cannot access /root/ just yet. However, we can access /home/ and we see this:

After submitting http://127.0.0.1:1337/home to beta's landing page input field
After submitting http://127.0.0.1:1337/home/saad to beta's landing page input field

We have our first flag! user.txt is here and we can access it. Now, to have a decent shell so we can continue to priv esc, we can go to .ssh and retrieve the private keys of the "saad" user.

After submitting http://127.0.0.1:1337/home/saad/.ssh to beta's landing page input field
After submitting http://127.0.0.1:1337/home/saad/.ssh/id_rsa to beta's landing page input field

3 - Foothold using saad account

3a - Trying to login

Using the above SSH private key, we can try to login to the target machine:

We have a small problem. We do not know the SSH key's passphrase. We have to crack it.

3b - Cracking the passphrase

Sweet! We cracked the passphrase.

3c - Foothold

4 - PrivEsc

First of all, we can find the password of the saad account in the bash history:

We can now proceed with some classical manual enumeration commands:

Using ping as root does not help us. However, using ping as root while overwriting the LD_PRELOAD variable effectively lets us run anything as root!

Last updated