Athena - TryHackMe
SUMMARY
En este caso debemos encontrar dos banderas ubicadas en la maquina Athenav1.9. Donde a partir del escaneo de puertos de Nmap pude saber que el servicio SMB se está ejecutando en los puertos 139 y 445. Luego, enumerando los recursos compartidos del servidor Samba, pude saber que hay un archivo de texto compartido donde encontré la ruta de un endpoint de una API que ofrece una funcionalidad similar al comando ping. Luego, aprovechando que el endpoint era vulnerable a Command Injection, logre inyectar un comando que genere un reverse Shell. Luego, para la escalada privilegio horizontal, logre encontrar un script en Bash que era ejecutado de manera automatizada y periódica con los privilegios del usuario athena, logrando modificar su contenido y realizar una reverse Shell. Luego, en la escalada vertical, aproveche que athena podía cargar un módulo kernel, que viene a ser un LKM rootkit, con los privilegios del usuario root, logrando analizar su código fuente con Ghidra.
RECONOCIMIENTO ACTIVO
En este caso debemos acceder al sistema destino y obtener las banderas. Para ello empezaremos utilizando el comando openvpn y el archivo de configuración OpenVPN con el fin de establecer una conexión VPN y poder acceder a los laboratorios donde están las máquinas virtuales y vulnerables.
Además, la plataforma de Tryhackme nos muestra la dirección IP de la máquina Athenav1.9.
FASE ESCANEO Y ENUMERACION
Ahora pasaremos a la fase de Escaneo y Enumeración con el fin de poder escanear los puertos del sistema destino. Además, obtendremos los servicios que se han levantado en los puertos abiertos, las versiones de los servicios, y el sistema operativo del sistema destino.
Los resultados que obtenemos son:
- Un programa servidor SSH que se ejecuta en el puerto 22.
- Un programa servidor HTTP que se ejecuta en el puerto 80.
- El servicio Samba que se ejecuta en el puerto 445 y 139.
Debido a que el servicio Samba se esta ejecutando en el sistema destino, lo primero que haremos es enumerar los usuarios locales del sistema destino y los recursos compartidos a traves del servicio Samba, y a los cuales podemos acceder de manera anonima, es decir, sin proveer credenciales.
Podemos observar que logramos encontrar algunos usuarios locales, y un recurso compartido de nombre public y que viene a ser un directorio. Luego, accedimos al recurso compartido de manera anonima. Donde encontramos un archivo de texto, que contiene la ruta de un endpoint de una API con cierta funcionalidad similar al comando ping que conocemos.
Ahora accederemos al endpoint a traves del navegador web.
Podemos observar que la funcionalidad el endpoint de la API consiste en ejecutar el comando ping con 4 mensajes eco Request ICMP y solo debemos proveerlo la dirrecion IP de un sistema.
FASE GANAR ACCESSO O EXPLOTACION
Ahora probaremos diversos payloads para testear si este endpoint es vulnerable a Command Injection.
- 10.8.123.194 ; whoami
- 10.8.123.194 && whoami
- 10.8.123.194
|whoami
- 10.8.123.194
whoami
- 10.8.123.194 $(whoami)
Podemos observar que se ha implementado un blacklist que nos impide ingresar ciertos metacaracteres de Shell como ; o & o |. Pero los comandos de sustitucion como $() o `` si estan permitodos, y los resultados de su ejecucion se estan considerando como parametro del comando ping realizada por la API. Debido a esto es que recibimos un mensaje de error que nos indico que fallo la ejecucion del comando ping pero aun asi se estan ejecutando.Por lo tanto el endpoint si es vulnerable a Command Injection.
Ahora inyectaremos un comando que nos generara una reverse shel a traves del comando de sustitucion en formulario HTML del endpoint vulnerable.
De esta manera logramos obtener acceso al sistema destino siendo el usuario www-data.
Ahora ejecutaremos los siguientes comandos para convertir nuestra reverse Shell más interactiva y estable.
FASE ESCALADA DE PRIVILEGIOS
Ahora buscaremos vectores de escalada de privilegios en el sistema de archivos del sistema destino.
Podemos verificar que si hay dos usuarios locales en el sistema destino que tienen sus directorios home, pero no podemos acceder a ellos.
Ahora enumeraremos los archivos y directorios cuyos grupos primario sean el usuario local athena o ubuntu. Ademas, estos archivos y directorios deben tener el permiso habilitado de lectura para el usuario www-data.
Podemos observar que logramos encontrar un script en Bash que va crear un subdirectorio backup en el directorio home del usuario local athena. Luego, va copiar todo los archivos del subdirectorio notes en el subdirectorio backup. Luego, se realizara una compresion recursiva de todo los subdirectorios y directorios del directorio backup en el archivo notes_backup.zip. Luego, se eliminaran todos los archivos con la extension txt y sh del directorio backup. Luego, se imprime el mensaje Backup completed. Ademas, tenemos el permiso de modificar el contenido del script.
Ahora enumeraremos todos los procesos que se ejecutan en el sistema destino y en tiempo real con el fin de saber si este script viene a ser como una tarea cron que se ejecuta periodicamente con los privilegios de algun usuario local.
Podemos observar que nuestra suposicion estaba en el correcto. Ademas, el script es ejecutado periodicamente con los privilegios del usuario athena.
Ahora modificaremos el contenido del script para que nos genere una reverse shell cons los privilegios del usuario local athena.
De esta manera logramos realizar una escalada privilegio horizontal llegando a ser el usuario athena.
Ahora buscaremos vectores de escalada de privilegio en el sistema de archivos del usuario athena.
Podemos observar que el usuario athena puede cargar un modulo de kernel llamado venom.ko mediante el comando insmod y con el privilegio del usuario root mediante el comando sudo y sin proveer credenciales. Ademas, si enumeramos informacion del modulo de kernel venom.ko, nos daremos cuenta de que el autor es monad y viene a ser un LKM rootkit.
Ahora buscaremos informacin sobre el LKM rootkit y su autor, en en el motor de busqueda de Google.
Podemos observar que logramos enconrar el repositorio Github del usuario monad donde uno de los repositorio llamado Diamorphine, se trata de un LKM rootkit para kernel de ciertas versiones en sistemas basados en Linux. Ademas, este LKM rootkit se compila como un modulo de kernel que va estar invisble, es decir, si intentamos enumerar todos los modulos cargados en el sistema Linux, no aparecera. Esto lo podemos comprobar en la siguiente imagen, pero si lo queremos hacer visible, podemos enviar una señal numero 63 a cualquier pid de cualquier proceso.
Una de las funcionalidades de este LKM rootkit viene a ser una forma de generar persistencia ya que qnos permite ser el usuario root enviando una señal numero 64 a cualquier proceso.
Podemos observar que si envamos una seña numero 64 al proceso con PID igual a 0, se nos cierra automaticamente la sesion de nuestra reverse shell .
Ahora debido a que los modulos de kernel vienen a ser archivos binario compilados, utilizaremos Ghidra para observar el codigo fuente escrito en lenguaje de programacion C, y poder observar la modificacion que se ha hecho en la funcionalidad de ser el usuario root.
Ademas, si observamos el codigo fuente original del script en C que le corresponde a este rootkit en el respositorio Github, podremos observar que la funcionalidad de ser el usuario root esta especificada en la funcion give_root.
Podemos observar que si la variable iVar3 es igual a 0x39, que viene a ser 57 en base decimal, se ejecutara la funcion give_root. Por lo tanto, deberiamos enviar una señal numero 57 para ser el usuario root.
Podemos observar que nuestro uid es igual a 0 por lo que ya somos el usuario root mediante el uso de este LKM rootkit que viene a ser una formar interesante de generar persistencia por el hecho de que el modulo kernel se vuelve invisible cuando se carga al kernel del sistema operativo.
Ahora buscaremos las dos banderas en el sistema de archivos del usuario root.
