IClean
Last updated
Last updated
Let's start with a nmap scan.
Visiting the site redirects us to http://capiclean.htb/. We should add it to our /etc/hosts. So we can access it and we meet with a webpage for cleaning services.
Directory enumeration revealed quite a few end points of value. Namely:
http://capiclean.htb/login
http://capiclean.htb/choose
http://capiclean.htb/team
http://capiclean.htb/about
http://capiclean.htb/quote
Default passwords did not work in the /login page.
The /quote endpoint, designed for clients to request service quotes, is interesting. Let's check for any potential vulnerabilities. After some testing, we unearthed a blind XSS vulnerability, serving as a potential gateway to exploit the backend user.
Now that we have obtained our session cookie, the next step is to insert it into our browser's session cookies. Once this is done, we can access the admin Dashboard without authentication
As we continue browsing and exploring different pages, the "Generate QR" feature seems interesting. Let's proceed with generating a QR code and capturing the request using Burp Suite. This feature requires an "invoice-id" as input.
During our examination of the generate QR feature in the application, we identified a vulnerability in the "qr_link" parameter. This parameter blindly reflects any input provided back in the response without undergoing proper checks. Through numerous attempts, we determined that we could exploit this vulnerability using Python Jinja2 Server-Side Template Injection (SSTI).
To exploit this vulnerability, we inject specific Jinja2 template code into the "qr_link" parameter. When the application processes our input, it executes the injected code on the server-side. This grants us control over the server's behavior, enabling potential malicious actions.
Payload: {{config.items()}}
In this instance, the payload utilizes the config.items() function, a component of the Jinja2 template engine. Upon injecting this payload into the "qr_link" parameter, the server proceeds to execute the code, incorporating the result into the response.
Injecting the payload utilizing the config.items() function enables retrieval of the server's configuration settings. This presents an opportunity to extract valuable information.
We encounter a scenario where our activities have triggered a security measure implemented by the server. This measure restricts our access and disrupts our testing procedures. The server's response explicitly states that our actions have been detected and restricted.
We managed to find a workaround that allowed us to resume our testing process effectively. This workaround entailed substituting \x5f with _ and \x2E with . in the payloads.
Lets validate if we can execute commands in its shell
To obtain a reverse shell, we'll begin by crafting a bash script. This script will serve as the payload we'll upload to the server. Upon execution, it will establish a connection back to our machine. Let's draft the bash script:
After creating the bash script, you need to make it executable using the command:
Next, we'll upload this script to the server. Once uploaded, we can execute it to initiate the reverse shell connection back to our machine. Let's setup a listener on our machine to catch the incoming connection.
After including the payload in Burp Suite, we can intercept the request to the server.Let's forward the request to execute the reverse shell on the server.
We've got a reverse shell.
After going through app.py file, we uncovered the database credentials embedded within it.
We can proceed with further enumeration by uploading LinPEAS. Running LinPEAS in the reverse shell will allow us to gather more information about the system, potential vulnerabilities, and additional avenues for privilege escalation.
Running LinPEAS revealed activity on port 3306, indicating the presence of a MySQL service. Since we have the credentials obtained from examining the app.py file, we can use them to potentially access the MySQL service and gather more information or perform additional actions.
It looks like the MySQL service is running locally on the target machine, identified by the IP address 127.0.0.1 and port 3306. To access it remotely, we'll set up port forwarding using chisel. Begin by uploading the chisel binaries to the /tmp directory on the target machine.
Navigate to the directory where the chisel binary is located.
Start the reverse tunneling by executing the following command:
Replace PORT_NUMBER with the port number you want to use for the reverse tunnel. This command will start the chisel server in reverse mode, listening on the specified port for incoming connections from the chisel client running on.
Having set up the reverse tunnel on your local machine, the next step is to return to your reverse shell on the target machine and forward the port to your localhost.
In your reverse shell on the target machine, execute the following command:
Replace YOUR_LOCAL_IP with the IP address of your local machine and PORT_NUMBER with the port number you specified when starting the chisel server.
This command will establish a connection to the chisel server running on your local machine and forward traffic from port 3306 on the target machine to port 3306 on your localhost.
Upon execution of the command, the chisel client will establish a connection to the chisel server on your local machine. Any traffic directed to port 3306 on the target machine will be forwarded to port 3306 on your localhost through the established reverse tunnel.
With this setup, you can access the MySQL service running on the target machine through your localhost. You can proceed to interact with the MySQL service as required, performing queries, managing databases, and accessing data.
We can now connect to the database with the credentials we already have
As we navigate through the database, we identify valuable information, particularly user hashes, located in the "capiclean" database.
Crackstation can help us crack this hash. We have a password for the user consuela.
We can SSH into the machine as consuela now that we have the password
We have the user flag.
Now lets move forward to privilege escalation
After more investigation, we discover an email to Consuela regarding PDFs from management. This, coupled with the knowledge that Consuela can execute qpdf as root, suggests a potential avenue for exploitation or privilege escalation.
We can embed another file into a PDF generated using qpdf, then download the PDF from the remote target to our local machine. Next, we'll use binwalk to extract the embedded file, such as the SSH root private key, as demonstrated below.
Now we download it into our local machine with scp.
We now use binwalk to extract the SSH root private key.
We can see that it has created a folder so we go in there and get our SSH key
Now that we have the root ssh key we can now SSH into the machine as root.
We have the root flag.
