Exploring the IPS Hack the Box: A Journey of Web App Enumeration

When it comes to hacking and exploiting vulnerabilities, understanding web applications is crucial. In this article, we will take a closer look at the IPS machine from Hack the Box. This machine proved to be an engaging challenge, involving multiple web apps and various techniques.

Learning Prototype Pollution and PHP Photo Chains

One of the highlights of the IPS machine was its utilization of Prototype Pollution, leveraging an old vulnerable library. However, before encountering this technique, I stumbled upon a relatively new approach to Local File Inclusion (LFI) and PHP - the PHP filter chain gadgets developed by Synactiv. This technique allows for executing code directly from URL parameters without the need to write files to disk. It significantly simplifies the exploitation process and makes understanding LFI vulnerabilities even more critical.

Diving into Web Apps and Blind XXE File Exfiltration

Apart from the interesting techniques mentioned above, the IPS machine housed several web applications, adding complexity to the enumeration process. One particular technique that caught my attention was the blind XXE file exfiltration. This unique method required careful navigation and understanding of XML External Entity (XXE) vulnerabilities.

Initial Reconnaissance with Nmap

Beginning any hacking endeavor, it is crucial to gather information about the target machine. Here, I started with an Nmap scan to identify open ports and services. Using the command nmap -sC -sV -O -oA pollution 10.10.11.192, I discovered that only two ports were open - SSH on port 22 and HTTP on port 80. Moreover, the HTTP banner indicated that the server was running Debian and Apache, with a PHP session cookie ID hinting towards a PHP-based website.

Exploring the PHP Website and Gobuster Scans

With the initial scan providing limited information, my focus shifted to the PHP website on port 80. Visiting the website, I noticed a navigation bar leading to various pages, and the content seemed to revolve around "collect" instead of the expected "pollution." As a best practice, I added the potential hostname, collect.htb, to my hosts file for convenience.

To further uncover hidden directories, I employed GoBuster with the command gobuster dir -u http://10.10.11.192 -w /path/to/wordlist.txt -o root.gobuster. While running the scan, I explored the website's features, including a contact form and a reference to an upcoming pollution monitoring API. Additionally, the website hinted at the possibility of PHP scripts being inaccessible directly.

Investigating User Registration and Forums

Taking advantage of user interaction, I attempted to register on the PHP website using the username "ipsec" and the password "password." Upon successful registration, I logged in and examined the site's features. Notably, a section called "Form" mentioned an API being developed to monitor pollution, piquing my interest.

To enhance my recon process, I ran another GoBuster scan specific to the collect.htb domain using the command gobuster -u http://collect.htb -w /path/to/wordlist.txt -o vhost.gobuster. Surprisingly, this scan quickly revealed a hit - a forum accessible at form.collect.htb. Excited to explore further, I updated my hosts file and accessed the forum.

Unearthing Proxy History and Forum Discoveries

Within the forum, I dived into the various threads and posts, hoping to find any hints or vulnerabilities. Although most threads were unrelated to my goal, one post caught my eye - "Pollution API Problems" by Victor. The admin requested those facing API issues to provide details, and interestingly, there was a downloaded file named proxyhistory.txt.

To access the file, I needed to log in. Utilizing my newly created account, I successfully logged in and downloaded the proxyhistory.txt file. Unfortunately, I lacked the Burp Suite Pro to load the file directly. However, copying the content to a text file revealed valuable information, including base64-encoded requests and proxy actions.

Analyzing Proxy Requests

When working with Rip Suite, I encountered a limitation with respect to loading requests off a disk. This particular feature seems to be a paid feature of Rip Suite, which means it is not available for our use in this scenario. As a workaround, I decided to copy all the request data and save it in a text file named proxyrequest.txt.

Decoding Base64 Data

Before proceeding further, I wanted to understand the content of the proxyrequest.txt file. To do this, I used the Echo command with the -n flag followed by the base64 -d command. This allowed me to decode the base64-encoded data and view its actual contents.

I noticed that the decoded data consisted of headers for the request, indicating that it contained relevant information about the domain. Additionally, I identified another section of the data that appeared to be the response for the request.

Extracting URLs

To gain more insight into the data, I decided to extract the URLs present in the proxyrequest.txt file. By searching for "collect.htb", I was able to identify a particular URL of interest. Taking a closer look at the request related to this URL, I found that it involved a POST request to set the role of an admin. The presence of "auth login" indicated the possibility of a local web server on the domain.

Attempting to Set Role as Admin

With the goal of testing whether we could make ourselves an admin, I recreated the request to set the role as admin. Upon executing the request, I observed that without the token, the response was a redirect to "/home". However, when the request included the token, the response redirected to "/admin".

Exploring the Admin Panel

As the request successfully redirected to the admin panel, I proceeded to examine its contents. The admin panel showcased a registration form that piqued my interest. To further investigate, I submitted the form with dummy credentials to see the resulting request. I noticed that the request was sent to an API and received an XML response.

Upon repeating the request, I received an error indicating that the user already existed. Although we were able to send requests to the API, we were unsure of how to log into it without the proper credentials.

Attempting XML Injection

To explore potential avenues for exploiting the XML data being used, I decided to attempt XML injection, a common technique when working with XML-based applications. Taking the blind approach, I tested an injection payload with the credentials "ipsec2". Unfortunately, this attempt did not yield any responsive data.

Exploiting XXE Vulnerability

Considering the possibility of an XXE vulnerability, I performed a search for "hacktrix xxe" and found an interesting payload to test. This payload utilized a document type definition (DTD) technique to include external files, such as Excel files, into the XML data.

I created an external DTD file and configured it to exfiltrate the hostname to my server. Upon sending the request again, it successfully attempted to download the external DTD file; however, it failed to send the exfiltrated data.

Utilizing a PHP Filter

In order to resolve the issue with sending the exfiltrated data, I opted to use a PHP filter, specifically the convert.base64-encode filter. This filter would encode the exfiltrated data to a base64 format, making it more URL-friendly. Unfortunately, the attempt resulted in an error due to potential invalid data.

Creating a Custom Script

To simplify and automate the process of fetching multiple files and accessing the server's host file, I developed a custom script named "blind-xxe.py". This allows for easier manipulation of files and eliminates the need for manual editing. The script is available on my GitHub repository under "CTF-Scripts" for reference.

Please note that a detailed video tutorial for creating the script is also available in the same repository.

Exploiting XML External Entity (XXE) Vulnerabilities

In this section, we will explore the process of exploiting XML External Entity (XXE) vulnerabilities and how they can be leveraged to gain unauthorized access to sensitive information. We will walk through a step-by-step guide on how to exploit such vulnerabilities using a repository on GitHub and a sample script.

Setting up the Environment

To begin with, we need the XXE script to carry out the exploitation. The script is available in a repository named "CTF Dash scripts" on GitHub. After cloning the repository, we can download the blind XXE script from the repository.

The script requires a request file as an argument. We can generate the request file using Burp Suite by copying the request to a file named xxe.request. The request file will be used to provide the necessary input to the XXE script.

Exploiting the XXE Vulnerability

Once the environment is set up, we can proceed to exploit the XXE vulnerability. To do this, we need to run the XXE script with the xxe.request file as input. The script will attempt to retrieve information from the target system using the XXE vulnerability.

After running the script, we may encounter some issues in obtaining the desired results. One possible reason could be that the XXE script expects the base64 payload to be passed as a specific parameter, but it was not set up properly initially.

To resolve this issue, we modify the payload by including the desired base64 payload in the specified format. This modification can be made directly in the xxe.request file and saved before rerunning the script.

Once the payload is correctly set, we can execute the script again. This time, we should get the expected output, which may include information such as the hostname and other system files.

Expanding the Exploitation

Having successfully exploited the XXE vulnerability, we can now further explore the target system to gather more information. For instance, we can examine files in the /etc directory to retrieve valuable data.

One interesting file to retrieve is the Apache configuration file located at /etc/apache2/sites-enabled. By accessing this file, we can identify virtual hosts and potentially discover additional vulnerabilities.

Another file worth exploring is the developers.collect.hdb file. This file may contain sensitive information such as usernames and passwords, which can be exploited to gain unauthorized access to the system.

By leveraging the XXE vulnerability, we can retrieve the password for the developers user from the developers.collect.hdb file. Armed with this password, we can attempt to crack it using tools like Hashcat and gain access to the system as the developers user.

Furthermore, by accessing the application code and exploring its source files (e.g., index.php), we can potentially identify weaknesses or vulnerabilities that can be further exploited to gain more control over the target system.

Exploiting a Cookie Vulnerability

The cookie vulnerability we discovered in the index.php file has the potential to allow unauthorized access to the server. In this section, we will discuss the details of the vulnerability and explore possible exploitation techniques.

Understanding the Cookie

Upon examining the code, we noticed that a session cookie named tk1 is being used for authentication. The server expects this cookie to have a specific value in order to confirm the user's login status. Initially, we attempted to manipulate the value of the cookie directly as a string. However, we realized that this approach was not effective as the server was performing type juggling.

Leveraging Type Juggling

To bypass the type juggling protection and exploit the vulnerability, we decided to change the value of the cookie to a Boolean. In PHP, the 0b prefix can be used to indicate a binary representation, with 0b1 representing true. By encoding the value as Boolean 1, we were able to pass the authentication check.

Resolving Redirect Issues

Next, we encountered a redirect issue while accessing index.php. Upon closer inspection, we discovered that the authentication cookie was getting erased when the page was refreshed. After reviewing the code, we realized that the issue was related to the lack of a semicolon at the end of the cookie value. By ensuring that the value ended with a semicolon, we were able to successfully log in.

Exploiting the LFI Vulnerability for Code Execution

Upon logging in and examining the application further, we identified a Local File Inclusion (LFI) vulnerability in the login.php page. This vulnerability allowed us to include files from the server. While the LFI vulnerability was not initially powerful enough to achieve code execution, we were able to leverage PHP filters to execute arbitrary commands.

We used a PHP filter chain generator to create a chain of PHP filters that would execute our desired code. By injecting this chain into the page parameter of the request, we were able to execute commands on the server. We were cautious to ensure that we did not drop any files onto the server, opting for a temporary file instead.

In order to achieve code execution, we composed a PHP command to spawn a reverse shell on our attacker machine. Although initially unsuccessful, we eventually discovered that we needed to set the full path of the command for it to work properly. Ultimately, this exploit granted us a shell on the target server.

Exploring the Node.js Application

With the shell access, we moved on to exploring the services running on localhost. We discovered that there was a service listening on port 3000, indicating the presence of a Node.js application. By inspecting the request made by the application, we were able to identify the authentication mechanism used for login. It became clear that there was a need to gain access to this Node.js application to further exploit the server.

In the next section, we will delve deeper into the Node.js application and discuss the tactics to exploit its vulnerabilities for complete control over the server.

Note: For a more detailed explanation of the steps and code snippets, consider referencing the accompanying video tutorial provided by Up Down.

Exploiting the Pollution API: Uncovering Vulnerabilities

Introduction

In this article, we will delve into the process of identifying and exploiting vulnerabilities in an application called Pollution API. By carefully analyzing the code and conducting various assessments, we aim to demonstrate the importance of secure coding practices and the impact of outdated libraries.

Assessing the Initial Setup

Upon attempting to gain access to the application, we encountered an "invalid password" error. It became apparent that the username used in the password being passed was incorrect. We decided to investigate further to determine the root cause of this issue.

The first step was to analyze the response received from the application. Upon sending a GET request to the base64-d parameters, we received a "parameters not found" response. Noticing that the application was built using Express and assuming that it was a Node.js application, we proceeded to inspect it further.

By curling the localhost on port 3000, we confirmed the presence of the application with a slash ("/") documentation route. Additionally, we discovered that there was another port, 9000, listening on localhost. Curiosity piqued, we decided to investigate port 9000 as well.

Curling the localhost on port 9000 resulted in a "connection reset by peer" response. To gather more information about this port, we performed a grep search on the Etsy directory, using "grep -R 9000 on Etsy". This search revealed that 9000 was associated with the php81-fpm pool manager process.

Further analysis of the php81-fpm process and socket interaction revealed that it was possible to inject PHP code into this process. Upon successfully injecting the code, we would be able to gain a shell as the user, Victor.

Exploiting php81-fpm to Gain Shell Access

To exploit php81-fpm, we referred to the Hacktricks website for insights and guidance. After inspecting an associated bash script, we decided to employ a Python script instead, as it offered greater flexibility in handling the task.

We created a Python script named fcgi.py and appended the retrieved code to it. This code would allow us to execute system commands, essentially granting us access to a shell. By executing the script, we successfully directed php81-fpm to execute the desired commands, gaining shell access as Victor.

Analyzing the Pollution API Application

With shell access granted, we turned our attention to the Pollution API application itself. Upon examination, we discovered a package.json file, confirming our suspicions that this was indeed the Node.js application we were looking for. However, before delving further into the application, we deemed it necessary to confirm if there were any unique vulnerabilities we could exploit.

Running an "sslntp" command to check the processes listening on port 3000 did not yield any results. We could also confirm that the root user was executing the index.js file, which suggested that the application on port 3000 was owned by root. It also appeared to be a duplicate of the application found in Victor's folder.

Exploiting Vulnerabilities and Navigating the Code

To facilitate analysis and code navigation, we decided to open the Pollution API application in Visual Studio Code. This allowed us to conveniently explore the code and scan for any vulnerabilities using the Sneak plugin.

After a thorough examination, we found several vulnerabilities in the application, including prototype pollution and outdated libraries such as modash and Json web token. The presence of these vulnerabilities highlighted the significance of implementing secure coding practices and regularly updating libraries.

One specific vulnerability piqued our interest. The POC mentioned command injection, accompanied by a provided working proof of concept (POC) code. This particular vulnerability required further investigation to understand its implications fully.

Vulnerabilities in the Application

In this section, we will discuss the various vulnerabilities found in the application. The vulnerabilities identified include hardcoded secrets in jwt.js and cipher key, and a regular expression denial of service (ReDoS) vulnerability in index.js.

Hardcoded Secrets in jwt.js

The jwt.js file contains hardcoded secrets that should be stored in environment variables for enhanced security. Hardcoding secrets in the code makes them easily accessible to attackers. It is recommended to store secrets in environment variables to prevent unauthorized access.

Regular Expression Denial of Service (ReDoS) in index.js

The index.js file has a regular expression denial of service vulnerability. This type of vulnerability can cause a significant slowdown or even a complete denial of service, leading to a loss of availability. It is crucial to address this vulnerability by implementing proper input validation and using efficient regular expressions to avoid potential exploitation.

Prototype Pollution in message-send.js

The main vulnerability in the application lies in the usage of an outdated library called loadash. This library is vulnerable to prototype pollution, which allows attackers to modify the behavior of objects and potentially execute arbitrary code.

To exploit this vulnerability, an attacker can inject a JavaScript prototype into the message body, specifically during the merge operation. By manipulating the prototype, the attacker gains control over future objects created in the JavaScript runtime environment.

Understanding Prototype Pollution

Prototype pollution is a security weakness that enables attackers to inject malicious properties into existing objects or change the behavior of fundamental JavaScript objects. By manipulating prototypes, attackers can overwrite functions or modify object properties.

In this case, the vulnerability arises when the application merges the message body into the message object. By injecting a JavaScript prototype into the message, an attacker can set default behavior for future objects and potentially execute harmful actions.

Exploiting the Prototype Pollution Vulnerability

To exploit this vulnerability, the attacker needs to gain control over the JavaScript prototype and overwrite essential functions. One approach is to manipulate the shell option within the child_process module in Node.js.

By default, the shell option points to bin/sh. However, since the attackers have access to the shell on the target system, they can create files and redirect the shell option to execute arbitrary commands. This provides them with a pathway to execute commands and potentially gain unauthorized access.

To execute the commands, the attacker needs to find a way to call the message-send function. By investigating the documentation.js file, we discovered an admin route named admin/message-send. This route allows administrators to send messages.

To send a POST request to the admin/message-send route, we can use tools like Burp Suite to intercept and modify the request. However, authentication is required for this route. By examining the authentication process, we noticed that it utilizes a JSON Web Token (JWT).

Analyzing Authentication and Authorization

To gain access as an administrator, we need to modify the role assigned to our user account. By using the MySQL credentials obtained earlier through other vulnerabilities, we accessed the users table and updated the role for the ipsec user to "admin."

By changing the role to "admin," we can now generate a JWT token with the admin role. We utilized the /auth/login route to create a new token. With the modified token, we made a POST request to the admin/message-send route, including the token in the x-access-token header.

Despite having the necessary authentication, we encountered an error regarding missing parameters. Further analysis revealed that we needed to include the request body parameter text with our desired message content.

Exploiting the Prototype Pollution vulnerability, we injected a JavaScript prototype and set the shell option to execute arbitrary commands. By including the payload within the text parameter, we achieved code execution on the target system.

Rooting the Box: A Deep Dive into Prototype Pollution

In this article, we will explore the concept of prototype pollution and demonstrate how it can be used to gain root access to a system. Prototype pollution is a relatively new vulnerability that allows attackers to modify the behavior of JavaScript objects at runtime by manipulating their prototypes. By injecting malicious code into an application, an attacker can exploit this vulnerability to execute arbitrary commands and potentially take full control of the system.

Setting up the Exploit

To demonstrate the process, we'll start by running a simple script that drops a file and initiates a callback. While this method is effective, it assumes that we already have a shell on the target system. In reality, this may not always be the case. To overcome this limitation, we can leverage a technique called "blitz.js prototype pollution."

Setting up Blitz.js Prototype Pollution

To begin, we need to modify our script to use blitz.js prototype pollution instead of the traditional method. This technique allows us to execute arbitrary code without needing a pre-existing shell on the target system.

The first step is to change the shell command to /proc/self/exe and set ARGV0 to our desired code. In the example we found during our research, the code prints "pwned" to the console. However, we can customize this code to execute any JavaScript command we want.

Let's update our script to include the necessary changes:

#!/bin/bash
TCP10101489001ROOTOBJECT="console.log('pwned');"

Exploiting the Vulnerability

With our modified script in place, we can now execute it to launch our attack. However, before we proceed, let's create a web server to receive the callback from the exploited system. We'll use Python's built-in HTTP server to do this:

python3-mhttp.server9001

Once the web server is up and running, we can execute our exploit script:

./exploit.sh

If everything is set up correctly, we should see a hit on our web server indicating that the exploited system has executed our custom JavaScript code.

Understanding the Prototype Pollution

Prototype pollution exploits the way objects are instantiated in JavaScript by modifying the default object behavior. By poisoning the prototype of an object, we can ensure that all future objects instantiated from it will inherit our malicious code.

In our example, we inject code into the default object to achieve this behavior. This means that any new objects created after our injection will have the same prototype with our injected code. As a result, we gain control over the entire system, allowing us to execute arbitrary commands and potentially compromise the system further.

Validating the Persistence of the Exploit

To validate the persistence of our exploit, let's reset the system by killing the existing Node.js process and restarting it. We should observe that the exploit still works even after the system reboot.

kill<node_pid>
nclvmp9001

This demonstrates the long-term impact of prototype pollution. Even after system restarts, the poisoned prototype remains intact, allowing us to retain control over the system.

Through initial reconnaissance, browsing the php website, and exploring the forum, i uncovered intriguing aspects of the ips machine on hack the box. this article serves as a foundation for further investigation and exploitation, highlighting the importance of understanding web application vulnerabilities and utilizing various techniques to overcome challenges.

in the next part of this series, we will delve deeper into the proxy history and analyze the base64-encoded requests, unlocking more secrets and potential vulnerabilities on this exciting journey. stay tuned for the upcoming article!
In this section, we explored the process of exploiting xml external entity (xxe) vulnerabilities and how they can be used to gain unauthorized access to sensitive information. by effectively utilizing the xxe script and properly manipulating the payload, we were able to retrieve valuable data from the target system. additionally, we expanded our exploitation efforts by examining apache configuration files and application source codes, which provided us with further avenues for exploitation.
In the next section, we will focus on exploiting the identified vulnerabilities and understanding their impact. by doing so, we aim to shed light on the importance of proactive security measures and provide insights for both developers and security professionals in securing their applications effectively.
The identified vulnerabilities in the application highlight potential security risks and underscore the importance of regular security audits and proactive vulnerability management. it is crucial to address vulnerabilities promptly by updating libraries, implementing secure coding practices, and regularly testing applications for potential weaknesses. by following these practices, organizations can enhance the overall security posture of their applications and protect sensitive information from potential exploits.

In this article, we delved into the world of prototype pollution and its implications in gaining root access to a system. We examined the traditional method of exploiting prototype pollution as well as explored a new technique called blitz.js prototype pollution. By leveraging this vulnerability, attackers can execute arbitrary commands on a system and potentially take full control.

Understanding the mechanisms behind such vulnerabilities is crucial for both security researchers and developers. By staying informed about emerging threats and vulnerabilities, we can strengthen our security posture and ensure the safe usage of JavaScript in our applications.

Stay vigilant and remember to regularly update and patch your systems to protect against such exploits.