author: IppSec

Stalker: A Journey Through the Hack the Box Machine

Introduction

In this article, we will explore the Stalker machine from Hack the Box. Stalker is an interesting machine that presents us with various challenges such as virtual host enumeration, SQL injection, and PDF manipulation. Join me as we navigate through these challenges and gain root access.

Enumeration

To begin our journey, we start with a thorough enumeration of the Stalker machine. Let's use nmap to scan the machine with the following command:

nmap-sC-sV-oAstalker10.10.11.196

After analyzing the results, we discover that there are two open ports on the machine. Port 22 is running SSH on an Ubuntu Server, and port 80 is running HTTP with an engine X server also on Ubuntu.

Virtual Host Enumeration

Upon visiting the website at http://10.10.11.196, we are redirected to stalker.htb. As we delve deeper into the machine, we begin to suspect that there might be a development version of the website with potential vulnerabilities.

To confirm our suspicions, we conduct a virtual host enumeration using GoBuster. We use the following command:

gobustervhost-uhttp://stalker.htb-w/path/to/wordlist

This enumeration helps us uncover the development version of the website at dev.stalker.htb. We add this subdomain to our host file and access it through the browser.

SQL Injection Vulnerability

Upon visiting the development website, we are presented with a login prompt. Our initial analysis suggests that this login form might be vulnerable to SQL injection, particularly NoSQL injection.

We use Burp Suite to intercept the login request and examine the headers and cookies. By tampering with the request, we test various SQL injection payloads such as or 1=1, username != 'ipsec', and password != 'ipsec'. Eventually, we discover that we can bypass the authentication using the JSON payload {"username": "ipsec", "password": "ipsec"}.

Online Store and PDF Manipulation

Once successfully logged in, we gain access to an online store. After adding an item to the cart, we discover that the application generates a PDF for our order confirmation. The interesting aspect is that we can include HTML code in the item's description, allowing us to manipulate the PDF-generation process.

We modify the item description to include a link to a local file on the server. This enables us to leak configuration files that inadvertently expose a password. Armed with this information, we log into the server and proceed to escalate our privileges.

Exploiting the GTFO Bin

With access to the server, we explore our surroundings to escalate our privileges to root. After some investigation, we come across a GTFO bin that allows us to execute commands as the root user.

Exploring the Order Generation Process and Extracting a PDF

In our investigation, we come across a unique order ID that does not seem to follow the UUID format. The absence of dashes leads us to believe that it is not a UUID. To validate our assumption, we copy the order ID and proceed to view our cart and make a purchase attempt. Surprisingly, we encounter a similar but not identical order ID. Upon closer inspection, we notice that the first few digits remain the same, followed by some variations. This discrepancy suggests that the order IDs are not randomly generated, leaving room for potential brute-force attacks.

Curiosity piqued, we decided to delve deeper by examining the response when viewing a purchase. Our investigation reveals that the response is a PDF file. To gain further insights, we save the page and analyze its metadata using the exif tool. The producer is identified as "Gaia PDF m108." This information gives us a hint to explore 'skia' on exploitdb.com for potential vulnerabilities. However, our search does not yield any conclusive results. Consequently, we turn to Google, conducting a general search for PDF exploits. Unfortunately, we do not come across any specific exploits that target the PDF producer mentioned earlier.

Not discouraged, we decide to experiment with injecting HTML into the PDF. We realize that attempting to inject HTML is a logical step when dealing with a PDF. However, before proceeding, we consider inspecting the PDF library and its potential vulnerabilities. As no vulnerabilities are found, we proceed with trying to inject JavaScript or random HTML into the PDF.

Investigating the Content and Structure of the PDF

We intercept the request when clicking on "View Cart" to examine the data being sent. This intercepted data likely helps in generating the PDF. Our next step is to inject an <iframe> tag with a source of file://Etsy/passwd to test if HTML injection is possible. Upon reloading the page, we discover that the injected code leads us to the passwd file, confirming our successful HTML injection.

Further investigating, we examine other aspects, such as accessing the /proc directory and the Environ file. Unfortunately, we do not find any useful information from these attempts. However, we notice that invalid JavaScript injections provide us with a stack trace. This information confirms that the application is running in a development environment using an Engine X server. With this knowledge, we extend our exploration to obtain the Engine X configuration file.

Extracting Source Code and Finding Potential Vulnerabilities

To gain access to the source code, we navigate to the Etsy/nginx/sites-enabled directory. After analyzing the available files, we find one that is likely the default configuration file. We try to view it, realizing that adding a scroll bar to the iframe could be useful. However, since this feature might increase the loading time, we decide to set the height and width attributes of the iframe to a value of 1000.

Upon viewing the generated iframe, we find a snippet of code related to "AndGoose." Intrigued, we attempt to extract an SSH key for "AndGoose" using the command cat ~/.ssh/id_rsa.pub. The SSH key successfully appears, and we proceed to use it to authenticate ourselves as "AndGoose" on the target machine.

As we continue exploring, we find a few dead-ends, such as the blank directories in "AndGoose's" home directory. However, we come across the source code for index.js. While examining it, we notice a to-do comment about configuring loading from .env for production. Additionally, we spot a reference to mongodb, which leads us to consider attempting an attack on MongoDB.

Analyzing MongoDB and Searching for Weaknesses

Based on our prior success in obtaining the passwd file, we attempt to access MongoDB using the AndGoose user's credentials. However, our initial investigation reveals that the Dev user is missing. Nevertheless, recognizing the potential security of MongoDB's passphrase, we try to SSH into the target machine using the password from the passwd file.

To confirm successful authentication, we unauthenticate and send a request. With a "200 OK" response, it becomes apparent that authentication is required for accessing several endpoints. Continuing our exploration, we search for the process of generating order IDs within the source code. We identify a POST request to API/order, where an item is created, saved, and the corresponding order ID is returned. Notably, we discover that the order ID relies on MongoDB's object ID, assuming its randomness.

Exploiting Weaknesses in ID Generation and Potential Security Risks

Upon closer inspection of MongoDB's object ID, we become skeptical of its actual randomness, as fewer digits in the generated hash appear to be unique. This lack of randomness would enable an attacker to potentially access other users' order IDs. Considering the absence of cookie validation, we conclude that this vulnerability poses a potential security risk.

While this vulnerability might not be our immediate focus for obtaining the root.txt file on the Hack The Box machine, it is crucial to highlight such issues during a web penetration test. However, to maintain focus, we will move forward with our primary objective.

In the next section, we will explore the potential weaknesses in the application's file structure and attempt to execute code in the context of the source code.

Understanding MongoDB Object IDs

In this part of the article, we delve into the structure and generation of MongoDB Object IDs. MongoDB Object IDs are unique identifiers used for each document in a MongoDB collection. These IDs are important for various operations, including creating and retrieving documents.

Structure of MongoDB Object IDs

Based on the MongoDB manual, the structure of a MongoDB Object ID consists of three parts:

Four-byte timestamp: The first part of the ID represents a four-byte timestamp that indicates the creation time of the object. This timestamp allows us to estimate when the ID was generated, providing some insight into its uniqueness.
Five-byte random value: The second part of the ID consists of a randomly generated five-byte value. This value adds an element of randomness to the ID, ensuring its uniqueness.
Three-byte incrementing counter: The final part of the ID is a three-byte incrementing counter. This counter ensures that each ID generated within the same second has a unique value.

Examining a Sample MongoDB Object ID

To better understand the structure of a MongoDB Object ID, let's analyze a sample ID. We'll use the hex representation of the ID for ease of visualization. Consider the following ID: 59798e6b7651f63c8b1884d5.

Breaking down the ID into its constituent parts, we find:

Timestamp: 59798e6b (four-byte timestamp)
Random value: 7651f63c8b (five-byte random value)
Incrementing counter: 1884d5 (three-byte incrementing counter)

By analyzing these parts, we can infer some interesting insights about the ID. For instance, the timestamp suggests when the ID was created, which can be useful in tracking temporal information.

Comparing MongoDB Object IDs and UUIDs

It's worth noting that MongoDB Object IDs and UUIDs (Universally Unique Identifiers) serve different purposes. While Object IDs are specifically designed for MongoDB and follow the structure mentioned above, UUIDs have a different structure and are typically 16 bytes long.

UUIDs offer a higher level of randomness, with around 100 characters of randomness compared to the five-byte random value in MongoDB Object IDs. This extra level of randomness can be useful in scenarios where a greater degree of uniqueness is required.

Using Sudo for Root Access

In this section, we will explore the usage of sudo command to gain root access to a system. To demonstrate the process, we will refer to the example provided by the authors.

Firstly, let's examine the sudo command syntax. By running the command sudo, followed by the specific action we want to perform, we can execute commands with elevated privileges.
To gain root access, the authors suggest running the following command:

require'child_process'
spawn'bin/bash'

This command will enable us to execute commands as the root user.

In order to verify if we have successfully obtained root access, the authors recommend running the command ID, which should return the ID of the root user.
With root privileges, we are able to access the root directory and retrieve the file "root.txt".
Moving on, the authors mention that they are unsure about when the "sudo" feature was added. To investigate, they suggest checking the /etc/sudoers file. By executing the command cat /etc/sudoers, we can view the contents of this file.
Additionally, the authors mention the possibility of using regular expressions in the /etc/sudoers file. They suggest a possible version where support for regular expressions might have been added, such as version 1.9.10.
To use regular expressions in the "sudoers" file, the authors outline the new syntax. Instead of using "*" to represent any character, we can use the regular expression syntax, such as A-Z, 0-9, underscore, and dash.
The authors recommend modifying the /etc/sudoers file accordingly to allow for regular expressions, in order to enhance security. By changing the syntax to A-Za-z0-9_-, we can ensure that only appropriate characters are permitted in the file names.
As a precautionary measure, the authors advise setting a secure password to ensure the integrity of the system. They suggest setting the password to "password" for the purpose of demonstration.
By implementing these modifications, the authors explain that the system will deny the execution of any scripts that do not adhere to the updated syntax in the sudoers file. They provide an example by attempting to execute the script schema.js and verifying that it no longer works.
The authors conclude this section by stating that these modifications serve to enhance security and prevent directory traversal attacks. They ensure that the system is now protected and functioning properly.

Exporting MongoDB Data

In addition to discussing the usage of sudo, the authors introduce the process of exporting MongoDB data from the system.

The authors begin by explaining how to access the MongoDB database and export its contents. By running the command mongodump, followed by the appropriate credentials, we can dump the database to a specified location.
The authors recommend navigating to the dev/shm/mongodump directory and executing the command. They suggest using a secure password and copying it into the command prompt when prompted.
Successfully dumping the database serves as an effective method of creating backups or transferring MongoDB data.
However, the generated BSON files cannot be easily viewed. To address this, the authors introduce a tool called bsondump. This tool allows for the proper viewing of BSON files.
The authors demonstrate how to view the BSON files by copying the generated string from the command prompt and using the bsondump tool with the -j flag.
Additionally, the authors mention the possibility of using jq as an alternative tool to view BSON files. However, they note that it may not be available on the system they are using.
Furthermore, the authors state that viewing the BSON files provides insight into the structure and content of the database.
Lastly, the authors highlight their testing scenario by examining the generated BSON files. They share that the data is specific to their system and testing activities, as evidenced by the commands executed and the files exported.

InThe stalker machine from hack the box offers a variety of challenges, from virtual host enumeration to sql injection and pdf manipulation. by exploiting these vulnerabilities, we learn the importance of thorough enumeration and creative thinking in the world of cybersecurity. join me in the next part of this article as we delve deeper into these challenges and conquer the stalker machine. stay tuned!
Understanding the structure and generation process of mongodb object ids provides valuable insights into the identification of documents within a mongodb collection. by breaking down the various parts of the id, developers can harness the power of these ids for efficient document management and retrieval in their applications.

(note: in the next section, we will shift our focus to another topic: analyzing potential vulnerabilities in a mongodb server setup using brip suite.)
, this section details the process of using Sudo for root access and exporting MongoDB data.