El objetivo del reto es comprometer el sistema consiguiendo acceso Root.

1. Solución al reto Hackademic.RTB2
@diegorg

2. Averiguo la ip de la máquina objetivo

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

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

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

6. Al acceder al servicio web aparece un formulario de acceso

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

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

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

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

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

12. Realizo un escaneo de directorios.

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

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

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

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

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

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

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

21. Realizo un volcado de joomla.jos_users.

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

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

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

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

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

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

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

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

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

31. Cambio el nombre del backdoor a mibackdoor.php

32. Ahora sí se ha subido bien.

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

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

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

36. Para explotar la vulnerabilidad he encontrado el exploit 14814.c de exploit-db.
Subo el fichero desde mi sistema, compilo, ejecuto y… r00t!

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

38. Copio el archivo al directorio raiz del servicio web, para poder bajarlo por web.
Lo descargo en mi sistema.

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

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

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

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

43. @diegorg