LinkVortex HackTheBox Walkthrough

• Introduction
• Enumeration
• Foothold
• Privilege Escalation

Introduction

OS: Linux
Level: Easy
Machine: LinkVortex

The machine LinkVortex provides an engaging challenge that combines web exploitation, source code analysis, and privilege escalation. The objective is to uncover vulnerabilities through enumeration, leverage misconfigurations to gain initial access, and exploit poorly implemented security controls to escalate privileges to root. Throughout this writeup, we will demonstrate the step-by-step process of enumeration, exploiting an exposed .git directory, analyzing source code for credentials, and escalating privileges using a vulnerable Bash script with sudo permissions.

Enumeration

On our target machine 10.10.11.47 (linkvortex.htb), here is the result of the nmap scan:

By navigating to the web page, we quickly notice that this is a website running on Ghost CMS. After further analysis of the site, including directory fuzzing, CVE checks, and other enumeration, no results were found. I decided to check for potential virtual hosts on this machine.

To do so, I used wfuzz:

This result reveals a new subdomain, dev, which seems interesting.

To access it, I updated the /etc/hosts file with the following configuration:

10.10.11.47 linkvortex.htb dev.linkvortex.htb

Once this was done, here is what the page looked like:

It's a development page, with no links or interactive elements. I continued enumeration using directory fuzzing:

Bingo! It's clear that there's a good chance we can access the entire application's source code. To explain, the .git directory was accidentally left on the web server. This directory exists in every Git repository and contains all the information about the repository, such as:

• Commits
• Source code
• Secrets

And more...

Tools already exist to retrieve an entire Git repository from a web server (even without directory listing). Pretty cool, right?

Exploiting the .git Directory

To retrieve the repository, I decided to use a more modern tool written in Go: Goop.

Once the tool was configured, I executed the following command:

# goop dev.linkvortex.htb

The result was incredibly fast, and I successfully retrieved the entire Git repository:

Now, we can look for more information. The most common objective is to retrieve secrets. I also noticed that the dump contains the repository for Ghost CMS, which is the CMS used on the main domain. This is likely the key to returning to the main domain.

Here's what I did:

I found two potential passwords. We will try them on the Ghost interface.

(I also deduced the email address admin@linkvortex.htb).

Using the password OctopiFociPilfer45, I successfully logged into the Ghost admin interface:

Foothold

At first, I tried multiple potential CVEs for Ghost CMS, but none of them worked.

However, now that we have account access, we can test authenticated vulnerabilities. One CVE stood out:

CVE-2023-40028

Advisory Link:

https://nvd.nist.gov/vuln/detail/CVE-2023-40028

Description:

Ghost is an open-source content management system. Versions prior to 5.59.1 are subject to a vulnerability which allows authenticated users to upload files that are symlinks. This can be exploited to perform an arbitrary file read of any file on the host operating system. Site administrators can check for exploitation of this issue by looking for unknown symlinks within Ghost's content/ folder. Version 5.59.1 contains a fix for this issue. All users are advised to upgrade. There are no known workarounds for this vulnerability.

I decided to use this PoC:

We're close. The vulnerability is confirmed to be present.
But what can we do with this?

Host Access

One option is to retrieve the private SSH key of the node user, if it exists.

However, that wasn't the case. Earlier, when looking at the .git dump, I noticed configuration files related to Ghost CMS that may contain credentials:

After trying them:

This is tricky because in /etc/passwd, there's no mention of the user bob. That's normal! The Ghost instance is running in a container, and these credentials allow us to access the host machine directly!

The credentials bob:fibber-talented-worth worked!

Privilege Escalation

We have sudo privileges on the script /opt/ghost/clean_symlink.sh, as revealed by the following command:

Here the source code of the file:

Critical Section 1: Symbolic Link Check

This line uses sudo to check whether the file specified in the $LINK variable is a symbolic link. However, the $LINK variable is not enclosed in quotes, leaving it vulnerable to injection attacks if special characters or malicious paths are introduced. Additionally, the use of sudo elevates the potential damage of this vulnerability, as any exploitation happens with higher privileges.

Critical Section 2: Symlink Target Validation

Here, the script uses readlink to retrieve the target of the symbolic link. However, there is no verification to ensure that $LINK points to a valid or legitimate file. If an attacker creates a symlink to a sensitive file (e.g., /etc/shadow), the script will fail to detect it unless the path explicitly contains certain keywords (etc or root). If the keywords are absent, the script proceeds without any warnings.

Critical Section 3: File Handling in Quarantine

Once the symbolic link is moved to the quarantine directory, the script checks if the environment variable CHECK_CONTENT is set to true. If so, it uses the cat command to display the content of the file. This is particularly dangerous because if the symbolic link points to a sensitive file (e.g., /etc/shadow), the script will display the file's contents with elevated privileges, allowing an attacker to access sensitive information.

Exploitation

Using these vulnerabilities, I crafted a symbolic link pointing to /etc/shadow. By exploiting the CHECK_CONTENT variable and the script's improper validation of symlinks, I was able to read the contents of the file, leading to privilege escalation.

Result: