Solución al reto Hackademic.RTB2

Averiguo la ip de la máquina objetivo

En el escaneo de puertos veo que el puerto 80 está abierto y es un servicio web y el 666 está filtrado.

Realizo un escaneo de directorios y ficheros, además del index.php parece ser que también tenemos un phpmyadmin

Realizo un escaneo con dirbuster, se descubre el directorio index y check y otros directorios pertenecientes a phpmyadmin

Al acceder al servicio web aparece un formulario de acceso

Intento sin éxito obtener las credenciales por fuerza bruta. Tampoco es vulnerable a inyección SQL. No obtengo nada interesante de los directorios index y check.

No consigo explotar ninguna de las vulnerabilidades que tiene esta versión. Tampoco consigo las credenciales de phpmyadmin por fuerza bruta.

Averiguo la versión de phpmyadmin consultando el fichero changelog.php.

Para acceder al directorio setup de phpmyadmin es necesario autenticación. Intento sin éxito conseguir el acceso por fuerza bruta.

Escaneo de nuevo los puertos con distintas opciones, en uno de los escaneos el puerto 666 aparece abierto, después de hacer distintas pruebas me doy cuenta de que al realizar varias veces un escaneo se abre ese puerto. Al final veremos por qué.

Repito el escaneo con más opciones para sacar más información sobre ese puerto. Es un servicio web lo que tenemos a la escucha.

Ha encontrado el fichero robots.txt.

Realizo un escaneo de directorios.

Esto es lo que aparece cuando accedo al servicio web. Se trata del cms Joomla versión 1.5 como se puede ver en la vista y en el código fuente.

Después de dar vueltas por las distintas opciones que presenta, intento sin éxito acceder al directorio administrator.

El directorio tmp está vacío y el resto de directorios no tiene nada interesante o no tengo acceso.

Intento sacar provecho de alguna de las múltiples vulnerabilidades que tiene Joomla 1.5. Después de no conseguir explotar ninguna de ellas, llego a esta opción, el listado de contenidos.

Guardo en el fichero (request.txt) la petición al servidor para luego procesarla con sqlmap y comprobar si es vulnerable a SQLi

El parámetro letter es vulnerable a SQLi. Obtengo las bases de datos.

Obtengo el hash de los usuarios de mysql.users. Intento crackearlos sin éxito.

Realizo un volcado de joomla.jos_users.

Necesito saber cómo genera el hash Joomla para después crackearlo con hashcat.

Se han crackeado dos de los tres hashes. Usuario Password JSmith matrix Btallor victim

Me logueo con uno y otro usuario. No consigo encontrar ninguna vulnerabilidad.

Intento a través de SQLi ejecutar el comando id. Indico que el backdoor de sqlmap lo suba a /var/www (por defecto) o como alternativa al directorio tmp que se descubrió anteriormente. Sin resultado positivo.

Sin embargo, si consulto el directorio sí veo que se ha creado el backdoor aunque sin contenido.

Ejecuto de nuevo sqlmap pero ahora conectado a burpsuite para ver qué pasa.

Quizás la SQLi no esté dando resultados y a lo mejor por eso crea el fichero pero no el contenido.

Repito la petición pero introduciendo un error en la query, a LIMIT le he quitado la M. Obtengo un error que me muestra la sql sobre la que se está ejecutando la SQLi.

Según la sql: SELECT id, title FROM jos_content WHERE state=1 AND UPPER(title) LIKE ‘List of content items…’ LIMIT 1…

La condición state=1 AND UPPER(title) LIKE ‘List of content items…’ no se está cumpliendo. Consulto el contenido de jos_content y veo que hay un registro con title=‘Welcome’ y state=1

Cambio la cadena a buscar por WELCOME en mayúsculas que es como se va a comparar. Lanzo de nuevo la petición y el resultado es que el fichero que se intenta grabar como backdoor ya existe.

Cambio el nombre del backdoor a mibackdoor.php

Ahora sí se ha subido bien.

A través del backdoor subo el webshell r577.php

Echo un vistazo a los directorios, servicios en ejecución, etc, etc…

Desde la webshell hago una conexión a mi sistema para tener una sesión de terminal (me muevo más rápido aquí que en la webshell). Después de algunas vueltas, descubro que la versión del kernel es vulnerable. CVE-2010-2959: Integer overflow in the Controller Area Network (CAN) subsystem when setting up frame content and filtering certain messages. An attacker could send specially crafted CAN traffic to crash the system or gain root privileges.

Para explotar la vulnerabilidad he encontrado el exploit 14814.c de exploit-db.

Subo el fichero desde mi sistema, compilo, ejecuto y… r00t!

Vuelco el contenido del fichero Key.txt, objetivo del reto y me encuentro con que está codificado, al parecer en base 64.

Copio el archivo al directorio raiz del servicio web, para poder bajarlo por web.

Lo descargo en mi sistema.

Decodifico el contenido y veo que se trata de una imagen PNG.

Hago un pequeño script para que lea Key.txt y cree key.png

Abro la imagen, y aquí tengo el contenido del fichero objetivo del reto.

Y ahora queda resolver la incógnita de por qué el puerto 666 inicialmente aparece filtrado y después de varios escaneos de puerto, se muestra entonces abierto. Si se analizan las reglas en iptables, lo que se ha hecho es crear un port knocking. La conexión a los puertos 1001, 1101, 1011 y 1001 otra vez y en este orden abre el puerto 666.