Difficulty: Easy
Tags: CTF, Web Exploitation, Privilege Escalation, Steganography
Target IP: 10.114.158.7

Objective

Exploit a vulnerable web server to discover two flags, one from the user and the other from the root user.

Reconnaissance & Enumeration

Initial Access

The challenge begins by accessing the web service via the target IP: http://10.114.158.7

Upon visiting the homepage, inspecting the Page Source reveals a critical comment exposing a relevant hint that mentions steganography.

Steganography: the practice of representing information within another message or physical object, in such a manner that the presence of the concealed information would not be evident to an unsuspecting person’s examination.

There is a potential hidden content in the image from the main page.

Scanning Services

Making a quick scan of the web would be useful to get more context of our scenario and to verify which services are available using nmap http://10.114.158.7

Discovered services:

• ftp
• ssh
• http

Exploitation

Credential Discovery

Accessing through ftp service firstly verifying if the anonymous user is available to execute ftp anonymous@10.114.158.7 where usually it does not require any password to login.

The anonymous user is enabled. Exploring if there is any relevant file by executing ls, there is a relevant instance called note_to_jake.txt

Getting the file into the local machine by using get note_to_jake.txt

Following the command cat note_to_jake.txt in our local machine to read the content of the file.

Looks like a potential user to log in within ssh service is jake and his password is weak, therefore a brute-force it might be quick to guess it. Using Hydra, hydra -V -l jake -P /usr/share/wordlists/rockyou.txt 10.114.158.7 ssh

Jake’s password has been guessed (987654321). Let’s proceed by impersonating Jake’s ssh session, ssh jake@10.114.158.7

Alternative Credential Discovery

Downloading the suspicious image that in the page source mentions steganography. Extracting detailed metadata from the image using the command exiftool.

There was nothing relevant. After a quick google search an interesting command steghide was found, steghide extract -sf brooklyn99.jpg

It contains a passphrase. It could be brute forced, therefore, after another quick google search if there is a way to make a brute force attack into an image that hides information. Commandstegcracker was found, stegcracker brooklyn99.jpg /usr/share/wordlists/rockyou.txt

Image has been cracked and a new result file has created, cat brooklyn99.jpg.out

In this path Holt’s password (fluffydog12@ninenine) has been discovered instead of Jake. Logging as Holt, ssh holt@10.114.158.7

Command Execution & Privilege Escalation

Once logged in as jake, the common corroboration of the following command brings more context of the session: pwd and whoami

Step 1: Environment Check (Jake)

Executing basic commands to understand the environment:

• whoami → Returns current user.
• pwd → Returns current working directory.

Step 2: Finding the User Flag

After exploring within Jake’s session there is an interesting file.

Looks like it is a hash value (ee11cbb19052e40b07aac0ca060c23ee), could be Holts hash password, but let’s try if it is the user flag.

User flag: ee11cbb19052e40b07aac0ca060c23ee

Alternative Step 1: Finding the User Flag (Holt)

Proceed by extracting the user flag, ls and cat user.txt

We got the same user flag ee11cbb19052e40b07aac0ca060c23ee

User flag: ee11cbb19052e40b07aac0ca060c23ee

Step 3: Privilege Escalation

After extracting the user flag, the remaining flag is the root user. Verifying the current session privileges using sudo -l

After knowing that the command less can be executed with admin privileges it is time to explore exploits by looking into GTFOBins to accomplish the privilege escalation.

Replicating the steps by executing first sudo less /etc/hosts followed afterwards !/bin/sh and verify that we are actually the root user.

Step 4: Finding the Root Flag

Navigating into the root folder and reading the text file using cat root.txt

Root flag: 63a9f0ea7bb98050796b649e85481845

Conclusion

By scanning the IP, finding credentials via ftp service and steganography techniques, and exploiting a vulnerable shell with sudo privileges for a specific command to escalate privileges to become the root user, we successfully retrieved both flags.

Mitigations and Remediations

To prevent these specific vulnerabilities in a production environment, the following measures should be implemented:

1. Secure Coding Practices: remove all hardcoded credentials and internal paths from source code comments before deployment. Use automated scanning tools to detect secrets in code repositories.
2. Least Privilege Principles: the ssh service should run with the minimum necessary permissions. Specifically, the user running in the service should not have sudo access, especially with NOPASSWD privileges.
3. Hardened Password Policy: enforce the usage of complex password to avoid a feasible brute force attack and restrict the amount of attempts to log in.

Final Answers

1. User flag: ee11cbb19052e40b07aac0ca060c23ee
2. Root flag: 63a9f0ea7bb98050796b649e85481845

Difficulty: Easy
Tags: CTF, Web Exploitation, Privilege Escalation
Target IP: 10.113.133.17

Objective

Act as Bob, a security engineer, to identify the vulnerabilities exploited on the tourism website in the production environment, retrieve the hidden flags, and restore the website to its original state.

Reconnaissance & Enumeration

The challenge begins by accessing the web service via the target IP: http://10.113.133.17

Minified Javascript: the process of removing unnecessary characters from JavaScript code, such as whitespace, comments, and line breaks, without changing its functionality.

By mentioning “minified” it means that the JavaScript code was modified. Inspecting the Page Source reveals several critical clues:

<!-- Rest PHP code and html content -->


<!DOCTYPE html>
<html lang="en">


<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Tourism Website</title>
 
    <script src='/tailwind.min.js'></script> <!-- THIS IS OFFICIAL FILE - DO NOT CHANGE IT -->
  <script src='custom.min.js'></script> <!-- THIS IS CUSTOM JS FILE-->
  <link rel="stylesheet" href="/style.css">
</head>


<body>
  <!-- Navigation Bar -->
  <nav class="bg-gray-900 text-white p-6">
    <div class="flex justify-between items-center">
      <a href="/" class="text-lg font-bold">Tourism MHT </a>
      <ul class="flex items-center gap-5">
	  <!--  <li><a href="https://alexanderroca.dev/img" class="hover:text-gray-300">Logs</a></li>  Please keep all images in this folder -->
      <!--  <li><a href="./logs" class="hover:text-gray-300">Logs</a></li>  DevOps team to check and remove it later on -->


        
              
      </ul>
    </div>
  </nav>

  <!-- Main Content -->
  <main class=" mx-auto py-8  h-[80vh] flex items-center justify-center">

    <div class="rounded overflow-hidden shadow-lg bg-white  p-8 flex ">
		        <h2 class="text-gray-700 text-3xl py-6"> FINALLY HACKED !!! I HATE MINIFIED JAVASCRIPT</h2>
	    </div>

  </main>

  <!-- Footer -->
  <footer class="bg-gray-900 text-white flex items-center justify-center">
    <div class="text-center p-4">
      <p>&copy; 2023 Tourism.mht. All rights reserved.</p>
    </div>
  </footer></body>

</html>

It mentions PHP at the top of the source code. Moreover, there are relevant comments:

• custom.min.js: Custom JS file
• /img: Keeps all the images
• ./logs: To check logs and remove later for DevOps

Service Analysis

Inspecting the Network tab in browser development tools reveals a GET request to custom.min.js

Downloading and examining the file reveals the content is encoded in Hexadecimal (hex)

What type of encoding is used by the hackers to obfuscate the JavaScript file? hex

Using CyberChef to decode the hex string reveals the hidden message DIRECTORY LISTING IS THE ONLY WAY

What is the flag value after deobfuscating the file? DIRECTORY LISTING IS THE ONLY WAY

Directory Enumeration

Following the hints from the source code comments:

1. Image Directory (/img)

Visiting http://10.113.133.17/img reveals an Apache server running on Ubuntu. No immediate flags are found in the images.

2. Logs Directory (/logs)

Visiting http://10.113.133.17/logs reveals a file named email_dump.txt

What is the name of the file containing email dumps? email_dump.txt

Reading the content of email_dump.txt:

From: Bob <bob@tourism.mht>
To: Mark <mark@tourism.mht>
Subject: API Credentials

Hey Mark,

Sorry I had to rush earlier for the holidays, but I have created the directory for you with all the required information for the API.
You loved SSDLC so much, I named the API folder under the name of the first phase of SSDLC.
This page is password protected and can only be opened through the key. THM{100100111}

See ya after the holidays

Bob.

The email mentions the API folder is named after the first phase of SSDLC. The first phase is Planning.

The logs folder contains email logs and has a message for the software team lead. What is the name of the directory that Bob has created? Planning

The email also provides the password/key: THM{100100111}

What is the key file for opening the directory that Bob has created for Mark? THM{100100111}

Exploitation

Credential Discovery & API Abuse

Step 1: Accessing the Planning Directory

Visiting http://10.113.133.17/planning requires a password. Entering the key THM{100100111} grants access.

Step 2: Enumerating Users

Inside, we find instructions for an API endpoint: GET http://MACHINE_IP/api/?customer_id=1

The objective is to find specific user details via the API.

Finding User ID 5: Calling http://10.113.133.17/api/?customer_id=5 returns information for a client:

There is an information from the customer id=5, where the email is john@traverse.com and it is a client user.

What is the email address for ID 5 using the leaked API endpoint? john@traverse.com

Finding the Admin User: Iterating through IDs reveals that id=3 belongs to an administrator. Calling: http://10.113.133.17/api/?customer_id=3 reveals:

What is the ID for the user with admin privileges? 3

It displays the endpoint to get access /realadmin and it reveals an email realadmin@traverse.com, name admin and password admin_key!!!

What is the endpoint for logging in as the admin? Mention the last endpoint instead of the URL. /realadmin

Step 3: Gaining Admin Access

Navigating to http://10.113.133.17/realadmin:

Logging in with the credentials found (realadmin@traverse.com / admin_key!!!) grants access to the admin panel.

Step 4: Environment Check

The admin panel offers options to execute system commands.

• System Owner: output www-data (equivalent to whoami)
• Current Directory output /var/www/html/realadmin (equivalent to pwd)

Using the browser’s Network tab to intercept the POST request, we can modify the payload to execute arbitrary commands.

Sending commands=ls -lsa reveals the directory contents.

Two critical files are identified:

• thm_shell.php: likely the web shell used by the attacker.

Can you find the name of the web shell that the attacker has uploaded? thm_shell.php

• renamed_file_manager.php: a renamed file manager tool

What is the name of the file renamed by the attacker for managing the web server? renamed_file_manager.php

A password for the file manager is also displayed in the output:THM{10101}

Step 5: Restoring the Website

Accessing http://10.113.133.17/realadmin/renamed_file_manager.php with the passwordTHM{10101} opens the file manager.

Locating the index.php, we observe it has been modified to display “FINALLY HACKED” message.

Editing the file to remove the malicious message restores the site.

The final flag of this room is in the file: THM{WEBSITE_RESTORED}

Can you use the file manager to restore the original website by removing the “FINALLY HACKED” message? What is the flag value after restoring the main website? THM{WEBSITE_RESTORED}

Conclusion

By analyzing the source code for hidden comments and obfuscated JavaScript, we identified the encoding method and a hint for directory listing. Leveraging directory enumeration, we found an email dump that revealed the naming convention for a protected directory and the password to access it. Inside, we discovered an insecure API endpoint that allowed us to enumerate users and harvest admin credentials. Finally, using the admin panel to execute commands, we identified the attacker’s web shells, accessed the file manager, and restored the compromised website.

Mitigations and Remediations

To prevent these specific vulnerabilities in a production environment, the following measures should be implemented:

1. Code Review & Sanitization: remove all hardcoded credentials, internal paths, and debug messages from source code before deployment. Avoid leaving comments that hint at hidden directories.
2. Disable Directory Listing: configure the web server (Apache/Nginx) to disable directory listing (Options -Indexes) to prevent attackers from browsing file structures.
3. Secure API Endpoints: implement proper authentication and authorization checks on all API endpoints. Do not expose sensitive user data (emails, passwords) via unauthenticated or poorly secured GET requests.
4. Input Validation & Sandboxing: restrict the ability of web applications to execute system commands. If command execution is necessary, ensure strict input validation and sandboxing to prevent arbitrary code execution.

Final Answers

1. What type of encoding is used by the hackers to obfuscate the JavaScript file? hex
2. What is the flag value after deobfuscating the file? DIRECTORY LISTING IS THE ONLY WAY
3. What is the name of the file containing email dumps? email_dump.txt
4. What is the name of the directory that Bob has created? Planning
5. What is the key file for opening the directory that Bob has created for Mark? THM{100100111}
6. What is the email address for ID 5 using the leaked API endpoint? john@traverse.com
7. What is the ID for the user with admin privileges? 3
8. What is the endpoint for logging in as the admin? Mention the last endpoint instead of the URL. /realadmin
9. Can you find the name of the web shell that the attacker has uploaded? thm_shell.php
10. What is the name of the file renamed by the attacker for managing the web server? renamed_file_manager.php
11. Can you use the file manager to restore the original website by removing the “FINALLY HACKED” message? What is the flag value after restoring the main website? THM{WEBSITE_RESTORED}