TracebackHTB-WriteUp-ETHCOP

EthicalHCOP
7 min readAug 31, 2020

EthicalHCOP.

A pesar de ser una máquina muy tipo CTF al inicio, la escalación de privilegios de esta máquina ha dejado una enseñanza muy grande y un refresh acerca de conexiones ssh.

Reconocimiento y escaneo.

De entrada, el escaneo nmap solo nos devuelve 2 puertos pertenecientes a los servicios ssh y apache.

Sin embargo, en apache vemos un mensaje diciéndonos que el sitio ya ha sido hackeado.

Si miramos el código fuente de dicho sitio web, encontraremos un mensaje en un comentario que nos dice: “alguna de las mejores web shells que podrías necesitar”

Buscando en internet acerca de este mensaje, encontramos algunas cosas curiosas. Algunas de estas son repositorios y twits del creador de la máquina, por otra parte encontramos un repositorio github que en su título tiene parte del mensaje buscado.

Al ingresar a este repositorio, vemos una buena cantidad de webshells, en su mayoría hechas en php. En este punto de la máquina, lo que se puede hacer es probar una a una manualmente hasta encontrar algo interesante.

En este caso, entre las ultimas web shells, encontramos una web shell llamada smek.php. Al ser abierta, esta solicita un usuario y una contraseña.

Sin embargo, podemos acceder al código fuente desde el repositorio github , ver las configuraciones del archivo e intentar acceder con dichas credenciales.

Al probar las credenciales admin/admin encontradas en el archivo php, accederemos a una web shell en forma de panel de control.

En lo personal, prefiero usar las shells desde la terminal, así que vamos a crear un archivo desde el cual podremos obtener una shell reversa.
Lo primero que haremos es crear un archivo php vacío.

Luego ingresamos el código php ofrecido desde el github de pentestmonkey y modificamos los parámetros de la IP y el puerto.
php-reverse-shell.php

Finalizamos dando click en el botón inferior con los símbolos mayor que (>>)!

Seguido, ponemos nuestra máquina a la escucha en el puerto configurado en el script php y mediante el navegador accedemos al archivo php subido previamente. Esto nos retornará una shell a nuestra máquina a nombre del usuario webmin.

Explotación de Usuario.

Una vez estemos en una shell un poco más interactiva, vemos que en la carpeta home hay 2 usuarios en donde solo podemos acceder a la carpeta del usuario con el que ingresamos al sistema (webadmin)

En el directorio home de este usuario hay un archivo de texto con una nota escrita por el otro usuario (sysadmin), en donde notifica la existencia de una tool para practicar “lua” a la cual tenemos acceso.

Si ejecutamos el comando “sudo -l” para conocer qué podemos ejecutar a nombre de otro usuario o si tenemos permisos de ejecución como root sobre algún programa. En este caso vemos que en la ruta home de sysadmin, hay un binario de nombre luvit.

Buscando acerca de esto, encontramos que luvit es un cli en lua que implementa las mismas API que Node.js!
https://luvit.io/

Ahora, buscaremos alguna forma en la que podamos explotar lua para escalar privilegios al usuario sysadmin.

https://gtfobins.github.io/gtfobins/lua/

https://netsec.ws/?p=337

Y según los sitios anteriores, podemos hacer uso de la librería OS en su función execute para realizar una shell reversa a nuestra máquina mediante netcat.

Así que creamos un archivo que ejecute la función execute de la librería OS, en su interior ingresamos un comando alternativo a la ejecución tradicional de netcat con la bandera -e.
A continuación ejecutamos a nombre de sysadmin, la herramienta de luvit y referenciamos el script de lua anteriormente creado.

Esto nos da como resultado la shell reversa a nombre de sysadmin, dándonos la posibilidad de acceder al archivo con la bandera del usuario.

Explotación de Root.

Una de las cosas a hacer una vez se accede al sistema, es mirar los procesos corriendo en la máquina ya que en su mayoría contienen información interesantes sobre comandos o algún proceso a nombre de root.

Durante la revisión de los procesos, se ve una proceso ejecutado como root el cual copia y pega unos archivos de una ruta a otra. Sin embargo, se ve que el origen de los archivos proviene de una carpeta backup y el destino es una carpeta en el directorio /etc/ y en su nombre están las letras MOTD.

Buscando en google acerca de ello, encontramos que MOTD “Message Of The Day” es un mensaje de bienvenida que se muestra a un usuario sobre el inicio de sesión de terminal si es a través de inicio de sesión SSH remoto o directamente a través de TTY o terminal.
https://linuxconfig.org/how-to-change-welcome-message-motd-on-ubuntu-18-04-server

El mensaje del día es modular, por lo tanto, se divide en varios scripts ejecutados en orden del valor numérico más bajo al más alto como parte del prefijo del nombre del archivo del script. Los siguientes scripts se encuentran dentro del /etc/update-motd.d directorio como parte de la configuración predeterminada del daemon

Si revisamos los permisos de la carpeta origen y de la carpeta destino, vemos que en la primer ruta los archivos pertenecen al usuario root y están en el grupo root, ademas de que los archivos tienen solo permisos de ejecución, lectura y escritura para el propietario de los archivos, para usuarios del grupo y otros solamente están habilitados los permisos de lectura y ejecución . En cambio los archivos de la segunda ruta, a pesar de que pertenecen al usuario root, el grupo a los cuales se asocian es al de sysadmin y tiene permisos de escritura, lectura y ejecución para el propietario y miembros de grupo. Esto se resume en que como sysadmin podemos obtener acceso a la modificación de dichos scripts !

Viendo los archivos un poco más de cerca, vemos que son archivos sh.

Como vimos anteriormente, estos mensajes se ejecutan exitosamente al iniciar sesión en ssh, en alguna tty o en la terminal. A pesar de poder tener acceso por ssh, no tenemos de momento alguna credencial para iniciar sesión en ello.

Pero si miramos en las carpetas ocultas del directorio home del usuario, vemos la existencia de la carpeta .ssh y en este el archivo de llaves autorizadas para ingresar mediante ssh.

Esto nos abre la posibilidad de ingresar nuestras claves públicas ssh al host víctima e ingresar al sistema mediante la llave privada.

https://www.linode.com/docs/security/authentication/use-public-key-authentication-with-ssh/#:~:text=The%20authorized_keys%20File&text=If%20you%20would%20like%20to,inside%20the%20user's%20authorized_keys%20file

Para ello, consultamos nuestra llave pública del sistema leyendo el archivo id_rsa.pub en nuestra maquina.

Luego copiamos este valor y lo agregamos o reemplazamos por el valor existente en las llaves autorizadas.

Por último accedemos al ssh de la maquina victima utilizando nuestra llave privada.

En el mensaje de bienvenida podemos ver el mismo mensaje que se encuentra en el archivo 00-header.

“Welcome to Xh4H land”

ya que es posible colocar algún comando en este archivo sh y ver su respuesta al iniciar sesión con el ssh, colocaremos el comando id en el archivo 00-header para ver a nombre de quien se está ejecutando este archivo.

Al iniciar sesión en ssh, vemos que nos retorna el id del usuario root.

Así que colocaremos al final del archivo el comando netcat utilizado en el archivo lua para obtener una shell reversa a nombre del root.

Una vez modificado el archivo, ingresamos nuevamente al ssh y la terminal se ha quedado cargando pero en nuestro puerto abierto se ha recibido la shell a nombre del root.

--

--