Hack The Box: Resource Machine Walkthrough – Hard Difficulty

Introduction to Resource:

In this write-up, we will explore the “Resource” machine from Hack The Box, which is categorized as a Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

The objective of the Resource machine:

The goal of this walkthrough is to complete the “Resource” machine from Hack The Box by achieving the following objectives:

User Flag:

Accessing machine via SSH Key Signing

This scenario revolves around an IT resource centre for a large company where SSH key signing responsibilities have been transferred to a different department. The process begins by creating a ticket with a zip attachment and leveraging a PHAR filter to execute a web shell from that attachment. This provides access to the ITRC container. Once inside, the ticket database is accessed, revealing a .har file containing credentials. These credentials belong to a user with access to the old SSH certificate signing key, which remains valid on the server and grants root access.

Root Flag:

Gaining Root Access via SSH Certificate Generation

As root, I locate a script that interacts with the IT API to generate SSH certificates, allowing me to sign an SSH key and gain access to the main host. On this host, I identify the principal name, which enables me to pivot to another user and generate a certificate using the API under that user’s credentials. This user can execute a bash script as root to create certificates, but there’s a check in place to prevent the server’s key from being used. I exploited a bashglob vulnerability to leak the server’s key, allowing me to generate an SSH certificate that grants root access to the IT server.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

     nmap -sC -sV -oN nmap_initial.txt 10.10.11.27

Nmap Output:

┌─[darknite@parrot]─[~/Documents/htb/Resource]
└──╼ $cat initial.nmap 
# Nmap 7.94SVN scan initiated Fri Nov 22 18:03:41 2024 as: nmap -sC -sV -oA initial 10.10.11.27
Nmap scan report for 10.10.11.27
Host is up (0.016s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey: 
|   256 78:1e:3b:85:12:64:a1:f6:df:52:41:ad:8f:52:97:c0 (ECDSA)
|_  256 e1:1a:b5:0e:87:a4:a1:81:69:94:9d:d4:d4:a3:8a:f9 (ED25519)
80/tcp   open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://itrc.ssg.htb/
2222/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 f2:a6:83:b9:90:6b:6c:54:32:22:ec:af:17:04:bd:16 (ECDSA)
|_  256 0c:c3:9c:10:f5:7f:d3:e4:a8:28:6a:51:ad:1a:e1:bf (ED25519)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Nov 22 18:03:49 2024 -- 1 IP address (1 host up) scanned in 7.90 seconds

Analysis:

• Port 22 (SSH): OpenSSH 9.2p1 on Debian 2+deb12u3 (protocol 2.0) is running, providing remote access through Secure Shell. The server uses both ECDSA and ED25519 host keys for authentication.
• Port 80 (HTTP): Nginx 1.18.0 on Ubuntu is serving HTTP traffic. The server attempted a redirect, but it was not followed, pointing to http://itrc.ssg.htb/.
• Port 2222 (SSH): OpenSSH 8.9p1 on Ubuntu 3ubuntu0.10 (protocol 2.0) is open, offering another SSH access point. Similar to port 22, it uses both ECDSA and ED25519 host keys for secure connections.

Web Enumeration:

Perform web enumeration to discover potentially exploitable directories and files.

Web Application Exploration:

I’ve attempted to enumerate the website, but nothing useful turned up.

I’ll try creating an account to see what insights it might reveal.

Let’s log in to the dashboard using the credentials we created earlier.

The dashboard appears as shown above.

An error is displayed when I upload an empty file with a .zip extension.

The ticket we created will appear as shown above.

I noticed a potential vulnerability, which could allow for a Local File Inclusion (LFI) attack. For instance, to access create_ticket.php, users are redirected to itrc.ssg.htb/?page=create_ticket. Leveraging this behaviour, we could potentially redirect the website to a PHP reverse shell uploaded in the uploads directory. The uploaded ZIP file can be found at uploads/<randomname>.zip.

Therefore, let’s use ffuf for enumeration, as it’s more efficient than Gobuster.

Let’s navigate to the /admin directory, where we are redirected to a page similar to the one shown above.

Therefore, let’s ping our machine to trigger a recall.

It seems to work, but the output feels a bit strange.

Let’s create a simple PHP one-liner to attempt to regain the connection.

As usual, we need to zip the PHP file as demonstrated above.

Let’s upload the malicious file to the target machine.

The interface will appear similar to the one above.

The ticket request will include details as shown above.

Command Injection on the Resource Machine

After clicking the file link, we can see that the file has been encoded, aside from the name we uploaded.

It appears to be functioning for the command injection.

The command “id” is functioning as expected.

Let’s inject our Bash shell command.

We have successfully established a reverse shell connection.

We managed to identify 3 users that execute bash commands.

db.php looks promising; it might contain MySQL passwords. Perhaps we can exploit this to gain xp_cmdshell access on the MySQL server.

I’ve found a user, jj:ugEG5rR5SG8uPd. Let’s attempt to connect to MySQL. The command `mysql -u jj -p -h db` didn’t work. I think we should explore other avenues.

There’s a file named ‘itrc.ssh.htb.har’ which looks intriguing. I can read the entire file content, but as far as I can see, it’s a log file. Let’s search for strings within it.

I managed to find the username and password while reading the file.

Enumerate the machine as Msainristil user access

Let’s use the credentials we found earlier to access the machine.

Decommission_old_ca enumeration

What is Decommission_old_ca?

When a Certification Authority (CA) is uninstalled, the certificates it issued typically remain outstanding, but they may no longer be usable. If these outstanding certificates are processed by Public Key Infrastructure (PKI) client computers, validation will fail, preventing their use.

This guide explains how to revoke outstanding certificates and complete the necessary tasks for successfully uninstalling a CA. It also covers utilities that help remove CA objects from the domain.

We discovered two files in the decommission_old_ca directory: ca-itrc and ca-itrc.pub.

Their primary purpose is to sign the public keys of other users, generating certificates that validate user identities. This facilitates secure authentication in systems that trust the certificate authority (CA).

Download both files to our machine.

We possess certificate authorization files, essential for signing and authorizing keys. If you’re unfamiliar with their purpose, consider learning about them before proceeding. These files facilitate secure authentication. First, we generate an RSA key pair using -t (type), -b (bits), and -f (file) options, creating a 2048-bit RSA key saved as darknite and darknite.pub. Next, we sign the darknite.pub file using the certificate authority (ca-itrc). The -s option specifies the signer, -n defines the target user, and -I provides an identifier (optional). After generating the signed key, we transfer these files to our system. With the keypair files ready, we can securely log in to SSH using them.

Unfortunately, it does not function on our machine.

Therefore, let’s run the previous command on the victim’s machine.

You can view the user flag by executing the command cat user.txt.

Escalate to Root Privileges Access

Privilege Escalation:

A bash script is available that could potentially be used for privilege escalation.

This API is used for signing public keys. From the Nmap scan, we identified two SSH ports: 22 (Docker) and 2222 (host machine). The API likely operates outside Docker, as there’s no var/www/signserv directory. To simplify the process, I’ll download the bash script and use it on my Kali machine.

If you’re unsure about any new users on the machine, there is a support user available.

The ssh-rsa-cert can be copied and pasted into a file on your system.

We can log into the machine as the support user.

SSH to Root access on Resource Machine

We should follow the same steps as done previously.

This script runs with root privileges, allowing it to access the Certificate Authorization (CA) file, but we cannot modify the script itself. It’s important to exercise caution here, as the script reads the original CA file content and compares it. If the contents match, it returns an error code of 1. While this presents a potential vulnerability for brute-forcing the CA, the length of the key makes brute-forcing practically infeasible. However, we can leverage Bash’s wildcard comparison functionality to gain a significant advantage in this situation.

Let’s obtain root access using the same SSH command.

You can view the root flag by executing the command cat root.txt.