Exploring Health Hack the Box Box - Initial Reconnaissance

Hello, YouTubers! This is Ipsec and today we are going to explore Health, a Hack the Box (HTB) machine. One of my favorite things about this box is that it emphasizes the importance of slowing down and replicating the software you're trying to attack locally. In this article, we will walk through the initial reconnaissance to gain a foothold on the box.

Step 1: Nmap Scan

As always, we begin with an nmap scan of the target machine. The command we used for scanning the target was:

nmap -sC -sV -oA health 10.10.11.176

• -sC: It runs default scripts.
• -sV: It probes open ports to determine the service and its version.
• -oA: It saves the output in all formats.

Running the above command showed three open ports. These included:

• Port 22 (SSH)
• Port 80 (HTTP)
• Filtered Port (unknown)

Step 2: Reconnaissance of the Website

Since HTTP was open, we visited the website health.htb. However, the website did not provide us much information about the target machine. So, we added the website to the host file and then sent a request to monitor the website. However, we received error messages saying the host was not allowed. We tried different ways but could not bypass the firewall.

Step 3: Replicating the GoGgs Locally

We found that the website was built using GoGgs, a web-based Git repository that provides several features similar to other online Git hosting services. However, we could not directly access the GoGgs instance. Thus, we needed to replicate the GoGgs and run it locally in order to build a payload against it. By doing so, we could execute a server-side request forgery (SSRF) attack on the target machine.

Step 4: Extracting the SSH Key of the Box

Using the SSRF attack, we could retrieve the hash of the GoGgs user on the targeted box. After retrieving the hash, we cracked it to log in through SSH. We also explored a second-order type of attack or perhaps just poisoning a MySQL database in order to extract the SSH key of the box.

Exploiting an Old, Vulnerable Version of Gogs

In this article, we will explore the steps required to exploit an old version of Gogs, a self-hosted Git service. The version we will be targeting is 0.5.5, which is almost a decade old. We will be using SQL injection to extract sensitive information from the Gogs database, including salts, password hashes, and email addresses.

Setting Up the Environment

To begin with, we need to set up a local environment where we can stand up our vulnerable version of Gogs. Initially, we download the Linux AMD 64.zip file and unzip it. Once we navigate to the folder and execute Gogs, it starts as a web server and listens on localhost 3000.

Finding the Vulnerable Endpoint

After confirming that the old version of the Gogs server is running correctly, we need to find the endpoint we can exploit. We can search on exploitdb or perform a manual search using Google. The endpoint we are targeting is "API V1 repos/search."

Exploiting the Vulnerability

Now that we have identified the vulnerable endpoint, we can use SQL injection to extract sensitive data from the Gogs database. We construct a Union select statement with the desired fields and dump the information. Specifically, we want salts, password hashes, and email addresses.

To extract this sensitive information, we can use a payload constructed using a concatenation function. In this function, we use pipes as concatenation operators. Once the payload is executed, we obtain the sensitive data.

Additional Considerations

While exploiting vulnerabilities, it is always best to stand up the vulnerable application locally, as it is easier and safer to work with. Further, we can use Burp Suite for easier decoding of the payload code. In case we encounter character sets that are blocked, we can use comments to overcome these restrictions.

Further, to stay up-to-date with exploits, it is best to use updated resources such as "Searchsploit" and to manually search Google for exploits.

Cracking Passwords and Accessing User Accounts in Gogs

In this section, we will discuss the process of cracking Gogs passwords and accessing user accounts by exploiting vulnerabilities.

Understanding the Hashing Format

To crack a password, we first need to understand the hashing format. In this case, we encountered a hash in HEX format. To determine the hashing algorithm used, we browsed through the Gogs Repository. We found the user structure of the application and encoded password field, which revealed that the password is encoded in PK pbk df2 hash. We also identified the iteration count, key length count, and hashing algorithm.

Converting the Hash

As the hash was in HEX format, we needed to convert it to the expected format, which was in base64. To convert it, we used Echo -n and base64 -d commands. However, this resulted in non-printable characters that could not be used for cracking the password.

Cracking the Password

To crack the password, we needed to convert the hash back to its original format. We used Echo -n with xxd -rp command to reverse the HEX encoding, followed by base64 -w0 to convert it to base64. We then used Hashcat to crack the password by providing the correct parameters, including the wordlist. Finally, we were successful in cracking the password and accessing the user account.

Accessing the User Account

To access the user account, we used a combination of SQL injection and cross-site scripting. We set the location to our payload and monitored the URL, which triggered a redirection to our specified location. This enabled us to dump the user and send the user to a particular payload URL. By running a query and specifying the raw output, we were able to obtain the username and password in plaintext, which we then encoded in base64.

Scripting in a Browser: Exploring a Vulnerable Web Application

In this article, we will walk you through our exploration of a vulnerable web application by utilizing browser scripting and SSH connections. We will detail the steps we took to gain access to the system and how we analyzed the code to look for further vulnerabilities.

SSH Connection and Attempted Passwords

Our first step was to SSH into the system using the IP address 10.10.11.176. We attempted to use a password that we had copied, but it was unsuccessful, so we retyped it to ensure it was copied correctly. Through another user, Susan, we were able to successfully log in. Once in the system, we explored the files of the web application.

Examining the Web Application

We began by examining the home directory and found a few config directories but nothing that stood out. We used the command "find . -type f" to list all the files. We noticed that there was a MySQL database and attempted to use a password we found in the web application's source code. We were able to access the database and looked for additional users but found none.

Analyzing the Code

We continued to explore the code and found an interesting file, "console/kernel.php". Through this file, we were able to discover a protected function "schedule" that ran an Artisan command. We traced this command to an HTTP controller's "Health checker" function. This function used a file get contents on a monitored URL that we could potentially manipulate.

Attempting Password Reuse

As we couldn't find any additional users, we attempted to check for password reuse with the MySQL password we had found earlier, but it was unsuccessful.

Using P-spy and IDE

We utilized P-spy to examine the system processes without root access. We also utilized an IDE, VS Code, to examine the web application's source code.

Further Analysis

We continued to dig into the application's source code and found a few interesting cron jobs that ran every minute. We also discovered that the application stored its credentials as environment variables. We tried to access these variables but were unsuccessful.

Exploiting an HTTP Controller's Health Check Function in Laravel

When performing security testing on an application, it's essential to explore and exploit all possible attack vectors. In this article, we will discuss how we were able to exploit an HTTP controller's health check function in Laravel, a popular PHP web application framework.

Benefits of an IDE and Control Click

As we were exploring the application, we noticed that the control-click feature in our IDE wasn't working as expected. Upon further investigation, we found that it was because of the HTTP controller's health check function.

The Check Function and the Monitored URL

The check function simply does a file get contents on the monitored URL. We realized that we could change the monitored URL to be anything we wanted because we had database access. We couldn't do this in the web application because of the filters used, but we were able to do it through the health check function.

Second Order Attack

We were able to pollute the database and conduct a second-order type of attack. We extracted the SQL password and accessed the tasks table, which is what the health check function was getting a task for. We were even able to put our payload URL and have it run every minute using the health check function.

Refresh and Cross-Site Request Forgery Checkers

We noticed some issues like "page expired" and cross-site request forgery checkers when we were recreating certain tasks in the health check function. It's particularly useful for security but can be annoying at times.

Updating the Monitored URL

We updated the monitored URL to the file of our choosing and ran the function. It sent us the file, and we were able to extract it with JQ. This gave us SSH root access to the box, effectively exploiting the vulnerability in the HTTP controller's health check function.

This marks the end of the initial reconnaissance steps of the health box. in the next article, we will progress further and will explore the ssh port. stay tuned to read about advanced recon techniques and more! Sql injection vulnerabilities are a security risk that can give us access to sensitive information. by following the above steps, you can learn how to exploit vulnerable sql injection endpoints and protect your own applications from such vulnerabilities. Cracking passwords and accessing user accounts in gogs requires understanding the hashing format, converting the hash to the expected format, and running the appropriate tools. it also involves exploiting vulnerabilities such as sql injection and cross-site scripting. in this section, we discussed the process of cracking passwords and accessing user accounts in gogs, showcasing the potential security risks associated with the platform. it is essential to implement robust security measures to prevent such vulnerabilities and protect the platform and its users. In conclusion, through our exploration of this vulnerable web application, we were able to utilize browser scripting and ssh connections to gain access to the system. we analyzed the code to look for vulnerabilities and attempted to manipulate monitored urls to gain access to additional information. while we were unsuccessful in finding further vulnerabilities, we were able to gain a deeper understanding of how to explore and analyze a web application for potential weaknesses.

As a penetration tester, it's essential to look at all aspects of an application, including areas that may seem trivial or insignificant. In this case, we were able to exploit the health check function within Laravel to gain root access to the server. Always be thorough and analytical when it comes to security testing an application.