HackTheBox Sherlock And Meerkat Writeup A Comprehensive Walkthrough

1. Introduction
2. Reconnaissance
   • Nmap Scan
3. Enumeration
   • Web Enumeration
   • Directory Busting
   • Examining robots.txt
   • Nikto Scan
4. Exploitation
   • Exploiting Grafana Vulnerability
5. Privilege Escalation
   • Enumerating Docker Socket Group Membership
   • Exploiting Docker Socket
6. Conclusion

Introduction

This writeup details the process of solving the HackTheBox machine named Sherlock, which also involves the related machine Meerkat. HackTheBox is an online platform that offers a variety of virtual machines to practice penetration testing skills. The Sherlock and Meerkat machines are designed to simulate real-world security vulnerabilities and require a methodical approach to identify and exploit them. This walkthrough will cover each stage of the penetration testing process, from initial reconnaissance to gaining root access. Understanding the methodology and techniques used in this writeup is essential for cybersecurity enthusiasts and professionals alike, as it provides practical insights into vulnerability assessment and exploitation.

Reconnaissance

The first step in any penetration test is reconnaissance. This phase involves gathering as much information as possible about the target. This information helps in identifying potential entry points and vulnerabilities. Reconnaissance typically includes network scanning, service enumeration, and identifying open ports. We begin by using Nmap, a popular network scanning tool, to identify the services running on the target machine.

Nmap Scan

Nmap (Network Mapper) is a versatile tool used for network discovery and security auditing. It works by sending packets to the target machine and analyzing the responses. This allows us to identify open ports, services, and even the operating system running on the target. A basic Nmap scan can provide a quick overview of the target, while more advanced scans can uncover detailed information about the services and applications running on the machine. In our case, we use Nmap to scan the target machine (Sherlock) to identify open ports and running services. The command we use is as follows:

nmap -sV -sC -oN sherlock.nmap 10.10.11.204

• -sV: This option tells Nmap to perform service version detection, which identifies the software and versions running on open ports.
• -sC: This option runs Nmap's default script scan, which executes a set of scripts to identify common vulnerabilities and misconfigurations.
• -oN sherlock.nmap: This option saves the Nmap output in normal format to a file named sherlock.nmap.
• 10.10.11.204: This is the IP address of the target machine (Sherlock).

The Nmap scan results reveal several open ports, indicating the services running on the machine. Key findings from the Nmap scan include:

• Port 22: SSH (Secure Shell) is running, which allows for secure remote access to the machine.
• Port 80: HTTP (Hypertext Transfer Protocol) is running, suggesting a web server is active.
• Port 3000: An unknown service is running, which requires further investigation. It is essential to understand the services running on the target machine as they often represent potential entry points for exploitation. The identification of these ports and services is a critical step in the reconnaissance phase, guiding the subsequent steps of enumeration and exploitation.

Enumeration

After the reconnaissance phase, the next crucial step is enumeration. Enumeration involves gathering detailed information about the identified services and applications. This includes identifying usernames, software versions, and potential vulnerabilities. The more information gathered, the better the chances of finding a vulnerability that can be exploited. In this phase, we will focus on enumerating the web service running on port 80 and the unknown service running on port 3000. Comprehensive enumeration is critical for identifying potential attack vectors and understanding the target's security posture.

Web Enumeration

Web enumeration involves examining the web server and its applications to identify potential vulnerabilities. This can include looking at the website's content, structure, and technologies used. Web servers often have publicly accessible files and directories that can provide valuable information about the system. Tools like web browsers, directory busters, and vulnerability scanners are commonly used in this process. Our initial approach to web enumeration involves browsing the website on port 80 and using directory busting tools to discover hidden files and directories.

By navigating to the web server on port 80, we find a default Apache page, indicating that the web server is running but not hosting any specific content. This suggests that the web service might not be the primary attack vector, but it's still worth investigating further for any potential misconfigurations or hidden files. Examining the default Apache page helps us understand the basic setup of the web server, which can be useful in later stages of the assessment. This preliminary check ensures that we do not overlook any obvious vulnerabilities or misconfigurations.

Directory Busting

Directory busting is a technique used to discover hidden files and directories on a web server. Directory busting tools use wordlists to guess common file and directory names, sending requests to the server and analyzing the responses. This method can reveal sensitive information or administrative interfaces that are not publicly linked. Tools like gobuster and dirb are popular choices for this task. We use gobuster with a common wordlist to enumerate the web server on port 80. The command we use is as follows:

gobuster dir -u http://10.10.11.204 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 40

• gobuster dir: This specifies that we are using the directory busting mode of Gobuster.
• -u http://10.10.11.204: This sets the target URL to the web server's address.
• -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt: This specifies the wordlist to use for guessing directory names.
• -t 40: This sets the number of concurrent threads to 40, speeding up the scan.

The results of the gobuster scan are unremarkable, indicating that there are no easily discoverable hidden directories or files on the web server. This suggests that we need to look at other services or techniques to find a way into the system. The lack of results from directory busting is an important finding, guiding us to focus on other potential attack vectors, such as the service running on port 3000 or other identified vulnerabilities.

Examining robots.txt

The robots.txt file is a standard text file used by websites to communicate with web crawlers and other web robots. It specifies which parts of the website should not be processed or scanned. However, it can also inadvertently reveal sensitive directories or files that the website administrators want to keep hidden from search engines. Examining robots.txt is a quick and easy way to potentially uncover hidden paths or files that might be vulnerable. By accessing http://10.10.11.204/robots.txt, we can view the contents of the file and identify any disallowed paths.

In this case, the robots.txt file does not exist, returning a 404 Not Found error. This means that there are no directives in place to guide web crawlers, and we need to continue exploring other avenues for enumeration. The absence of robots.txt doesn't necessarily indicate a security vulnerability, but it does eliminate one potential source of information and directs our attention to other enumeration techniques.

Nikto Scan

Nikto is a web server scanner that performs comprehensive tests against web servers for multiple types of vulnerabilities, including dangerous files/CGIs, outdated server software, and other problems. Nikto scans are useful for identifying common web server misconfigurations and vulnerabilities that might be missed by manual inspection or other enumeration techniques. We use Nikto to scan the web server on port 80 to identify any potential issues. The command we use is as follows:

nikto -h 10.10.11.204

• -h 10.10.11.204: This specifies the target host to scan.

The Nikto scan results do not reveal any significant vulnerabilities or misconfigurations. This further reinforces the idea that the web server on port 80 is not the primary attack vector. The clean Nikto scan suggests that we need to shift our focus to other services, such as the one running on port 3000, to identify potential vulnerabilities and entry points into the system.

Exploitation

After thorough enumeration, the next step is exploitation. Exploitation involves leveraging identified vulnerabilities to gain unauthorized access to the system. This may involve using known exploits, crafting custom payloads, or exploiting misconfigurations. The key is to use the information gathered during enumeration to identify a weakness that can be exploited. In this case, we will focus on exploiting the service running on port 3000, which Nmap identified as Grafana.

Exploiting Grafana Vulnerability

Port 3000 is running Grafana, a popular open-source data visualization and monitoring tool. Grafana is used to create dashboards and visualizations from various data sources. However, like any software, Grafana can have vulnerabilities that can be exploited. We need to research known vulnerabilities in the Grafana version running on the target machine. By searching for Grafana vulnerabilities, we come across a critical vulnerability that allows for arbitrary file read. This vulnerability is particularly significant because it allows us to read sensitive files on the server, potentially including configuration files or credentials. The discovery of this vulnerability is a turning point in our exploitation phase, providing a clear path to gaining unauthorized access to the system.

The vulnerability we identified is related to a path traversal issue in Grafana's plugin installation functionality. By crafting a specific request, we can read any file on the server that the Grafana process has access to. This is a severe vulnerability that can lead to significant security breaches. The path traversal vulnerability allows us to bypass security checks and access files that should not be publicly accessible. To exploit this vulnerability, we can use the following steps:

1. Identify the Grafana version running on the target.
2. Craft a malicious HTTP request to exploit the path traversal vulnerability.
3. Use the vulnerability to read sensitive files, such as configuration files.

By sending the following HTTP request, we can exploit the vulnerability to read the /etc/passwd file:

curl -k -v --path-as-is 'http://10.10.11.204:3000/public/plugins//../../../../../../../../../../../../etc/passwd'

The response contains the contents of the /etc/passwd file, which includes a list of users on the system. This confirms the presence of the vulnerability and demonstrates the ability to read sensitive files. Reading /etc/passwd is a significant step, as it provides us with a list of potential user accounts, which can be useful in later stages of the attack. This also confirms the successful exploitation of the Grafana vulnerability.

Next, we target the Grafana configuration file, which may contain sensitive information such as API keys, database credentials, or other secrets. By reading the Grafana configuration file, we can potentially gain further access to the system or other connected services. The configuration file is typically located at /etc/grafana/grafana.ini. We use the same path traversal vulnerability to read this file:

curl -k -v --path-as-is 'http://10.10.11.204:3000/public/plugins//../../../../../../../../../../../../etc/grafana/grafana.ini'

The response contains the contents of the grafana.ini file, which includes several important pieces of information. Among the contents, we find the [security] section, which contains the admin_password. This is the administrator password for the Grafana web interface. Obtaining the admin_password is a major breakthrough, as it allows us to log in to the Grafana web interface with administrative privileges. This provides us with a powerful foothold on the system.

With the administrator password, we can log in to the Grafana web interface and explore the available features and settings. This access can potentially lead to further exploitation opportunities, such as uploading malicious plugins or modifying system settings. Logging in to the Grafana web interface as an administrator provides us with extensive control over the Grafana instance, opening up new avenues for exploitation and privilege escalation.

Privilege Escalation

After gaining initial access to the system, the next goal is privilege escalation. Privilege escalation is the process of gaining higher-level access, such as root or administrator privileges. This often involves exploiting system misconfigurations, vulnerabilities in the operating system, or weaknesses in installed applications. In this case, we will leverage our access to Grafana to identify and exploit a privilege escalation vulnerability. We begin by examining the Grafana environment for potential weaknesses that can be exploited to gain higher privileges. Identifying the right privilege escalation path is crucial for achieving root access and fully compromising the system.

Enumerating Docker Socket Group Membership

After logging into the Grafana interface, we can enumerate the system further. One interesting finding is the presence of a Docker socket. The Docker socket (/var/run/docker.sock) is a Unix domain socket that Docker uses to communicate with the Docker daemon. If a user or group has access to this socket, they can control the Docker daemon and potentially the entire system. Access to the Docker socket is equivalent to root access on the system, as it allows for the creation and execution of containers with elevated privileges. We need to determine if the Grafana user has access to the Docker socket.

To check the group memberships of the Grafana user, we can use the getent command. This command retrieves entries from administrative database files, including group information. We can use it to check if the Grafana user is a member of the docker group. If the Grafana user is a member of the docker group, it has access to the Docker socket. Checking group memberships is a key step in identifying potential privilege escalation paths, as membership in certain groups can grant access to sensitive resources or capabilities.

We execute the following command within a Grafana plugin (for example, by exploiting the plugin upload functionality, if available, or via an API call that allows command execution) to check the group memberships:

getent group docker

The output of this command reveals that the Grafana user is indeed a member of the docker group. This is a significant finding, as it means we can use the Docker socket to escalate our privileges to root. Membership in the docker group is a clear indicator of a potential privilege escalation vulnerability, as it provides direct access to the Docker daemon and its powerful capabilities.

Exploiting Docker Socket

Since we have confirmed that the Grafana user is a member of the docker group, we can exploit the Docker socket to gain root access. Exploiting the Docker socket involves using the Docker API to create a container that mounts the host's root filesystem and executes a command within that container. This allows us to modify files on the host system as root. We can use this capability to add a new user with root privileges or modify the /etc/passwd file to grant root access to an existing user. This method is a common and effective technique for privilege escalation on systems with misconfigured Docker permissions. The power of the Docker socket in privilege escalation scenarios cannot be overstated, as it provides a direct pathway to gaining root access on the host system.

To exploit the Docker socket, we can use the following steps:

1. Create a Docker container that mounts the host's root filesystem.
2. Execute a command within the container that adds a new user with root privileges.
3. Log in as the new user via SSH.

We can use the following command to create a Docker container that mounts the host's root filesystem:

docker run -it --rm -v /:/mnt alpine chroot /mnt

• docker run: This is the Docker command to run a new container.
• -it: This allocates a pseudo-TTY and keeps STDIN open, allowing us to interact with the container.
• --rm: This automatically removes the container when it exits.
• -v /:/mnt: This mounts the host's root filesystem to the /mnt directory within the container.
• alpine: This specifies the Alpine Linux image to use for the container.
• chroot /mnt: This changes the root directory to /mnt, effectively giving us access to the host's filesystem.

Inside the container, we can now modify the host's filesystem as root. We can add a new user with root privileges by modifying the /etc/passwd and /etc/shadow files. Alternatively, we can add our SSH key to the authorized_keys file for the root user. Modifying the host's filesystem from within the container allows us to make persistent changes to the system, effectively granting us root access even after the container is terminated. This is a powerful technique for privilege escalation and system compromise.

To add our SSH key to the authorized_keys file for the root user, we can use the following commands within the container:

mkdir -p /mnt/root/.ssh
echo