Bienvenidos a la segunda parte de este reto, en la primera parte, le dimos solución completa al reto, que consistía en encontrar las dos banderas, una como usuario normal y la siguiente como superusuario (root).
En esta segunda entrada, de manera breve, veremos un par de caminos alternos que se hubieran podido tomar para solucionar este reto.
En la aplicación web que encontramos en el servidor web, pudimos ingresar con el usuario y contraseña por defecto, aún así, realizando una búsqueda en exploit-db, encontramos que la aplicación tiene una vulnerabilidad de inyección SQL, que nos permite ingresar como administradores al panel de la aplicación.
Cuando buscaba la forma de elevar privilegios, encontré que en el servidor se corría otro sitio web, una aplicación llamada inoERP, que también tiene una vulnerabilidad crítica que permite ejecutar comandos y por la cuál también podríamos obtener una shell en el sistema.
Si se preguntan cómo era posible encontrar esto antes de ganar la shell por el método utilizado en la parte uno, la respuesta es sencilla, valiéndonos de esta falla de inyección SQL y explorando la base de datos, encontraremos la URL del sitio:
Por último, si se optara intentar la inyección SQL, se debe tener en cuenta que dentro de la máquina virtual se ejecuta la aplicación fail2ban que detectará el ataque y bloqueará la IP del atacante.
Y bien, con esto doy por cerrado completamente este ejercicio, si tienen alguna duda al respecto, dejen un comentario y lo revisaré lo más pronto posible. Gracias por llegar hasta acá y nos vemos pronto.
En esta entrada daremos solución la máquina virtual INO 1.0.1 de vulnhub, esta es una máquina virtual de nivel fácil y el objetivo es encontrar las dos banderas, una de usuario y otra como superusuario (root). En esta entrada veremos el método que utilicé para completar los objetivos, revisando y analizando varios hallazgos, encontré que hay diferentes formas de cumplir el desafío, así que en otra publicación, revisaremos estos otros caminos y sin extendernos mucho, algunas fomas de abordarlos. Por ahora, comenzarmos con el desarrollo del ejercicio.
Conociendo al objetivo
Para empezar, debemos identificar la IP de la máquina, con nmap:
Ahora con la IP identificada, veremos qué servicios están corriendo sobre la máquina:
Como vemos, hay acceso por SSH y está corriendo un servidor web, así que vamos a ver qué contiene este último:
Podemos observar que es una especie de página web para hacer reservas de lotes, en la imagen he seleccionado algo me llamó la atención, que fue publicado por Sourcecodester, pensé que era una jugarreta del creador de la máquina para añadir algo de realismo al ejercicio, sin embargo decidí visitar la página y encontré que es un sitio que se dedica a compartir código de manera libre, así que pensé que podría bajarme el código y ver si podría encontrar alguna inyección SQL o vulnerabilidad que pudiera aprovechar, sin embargo encontré algo que me facilitó mucho más el trabajo, la URL del panel de administración y el usuario y contraseña por defecto del portal:
Con esa información en mente, quise probar que si funcionaban las credenciales por defecto, como ya lo había contado antes en esta historia, muchos administradores son descuidados y no cambian las contraseñas que vienen predefinidas de las aplicaciones que implementan y como se observa a continuación, funcionó a la perfección:
Ya hemos ganado acceso al panel de administración, pero hasta ahora vamos comenzando. Vayan alistando su café.
Preparativos
Para poder ganar acceso al servidor, usaremos una shell de conexión inversa, personalmente uso esta de pentestmonkey.net, sólo basta con editar los detalles de IP y puerto de conexión, tal como lo indican en su página web:
Por otro lado, en mi máquina, prepararemos el puerto de escucha por el cuál se hará la conexión:
Iniciando el ataque
Lo primero que debemos hacer es encontrar la forma de subir nuestra shell, explorando un poco encontré un escenario que me parece perfecto para esto:
En el caso ideal, este formulario debería poder filtrar el tipo de archivo que se está intentando subir (para que no ocurra lo que va a suceder a continuación) y que sólo permita subir imágenes, sin embargo eso no pasa y acá es donde aparecerá la magia:
Después de cargar la shell, se nos redirigirá al listado de casas modelo y todo se ve aparentemente normal, excepto porque donde escribí shell.php, es donde se ejecuta nuestra shell
Si nos devolvemos a la terminal que preparamos con el puerto 666 a la escucha, veremos que nuestra conexión está establecida con éxito: Como dirían en algunas películas con escenas de hackers: “estamos dentro”.
Antes de continuar, ejecutaremos un comando en python, para tener una shell interactiva:
Obteniendo la bandera de usuario
En la ruta /home/ppp encontramos un archivo llamado local.txt y su contenido es nuestra primera bandera, nada complicado.
Escalando privilegios
Esta parte fue bastante complicada y debo aceptar que logré resolverla por un golpe de suerte, buscando algún ejecutable con el cual pudiera elevar permisos, encontré que usan pppd para trabajar con el protocolo ppp:
Teniendo en cuenta esto, decidí revisar la configuración del demonio en la ruta /etc/ppp y ver si podía leer el archivo que tiene guardadas las credenciales de acceso:
Revisando el archivo chap-secrets tenemos la contraseña del usuario ppp, que coincide con uno de los usuarios que tienen acceso de shell:
Como ya vimos, este administrador del sistema no es muy riguroso con su política de contraseñas, entonces podríamos intentar iniciar sesión con esas credenciales.
Nota importante: al inicio del ejercicio la máquina virtual tenía la IP 192.168.0.130, pero en la imagen aparece la 192.168.0.9, esto pasa porque después de un reinicio de mi ordenador, las direcciones cambiaron.
Estamos próximos a terminar, desde esta sesión veremos si tenemos alguna forma de ejecutar comandos como sudo y en efecto, observamos que sin contraseña nos permite usar el comando useradd, que, como nos dicta la intuición, nos permite agregar un nuevo usuario al sistema:
Dando una mirada a al manual de useradd (man useradd) encontré las opciones que se necesitan para poder ejecutar el comando con éxito:
-m para crear el directorio del usuario
-g el grupo al que se va a añadir al usuario
-p la contraseña (que ya debe venir cifrada con la función crypt)
Para poder cifrar la contraseña, como dice el manual, se debe usar la función crypt, para entender cómo funciona, me apoyé de este blog, la contraseña que hemos elegido para esta importante tarea de (in)seguridad será -irónicamente- la infame 12345678:
Ahora debemos revisar qué grupos hay disponibles, como vemos, nuestro nuevo usuario lo podemos agregar al grupo de usuarios de sudo. Ya podemos ir saboreando la victoria:
Últimos detalles
Agregaremos el usuario con los parámetros que ya hemos definido y después de ejecutar el comando confirmamos que nos haya quedado dentro de la lista de usuarios:
Nos cambiaremos de usuario, digitamos la contraseña y vemos que ya tenemos una sesión con nuestro usuario rebel:
Ahora, elevaremos permisos, digitamos la contraseña del usuario y el símbolo # nos indica que somos superusuarios. (root)
Obteniendo la bandera de root
En la ruta /root tenemos el archivo proof.txt que nos indica que hemos cumplido todos los objetivos de nuestro reto:
Conclusiones
No quiero extenderme mucho más, ha sido bastante largo de desarrollar, escribir y editar esta entrada, sin embargo, hemos podido ver los errores más comunes de un administrador de sistemas, los cuales pueden poner el peligro la seguridad no sólo de un sistema, sino de una red completa.
Nos vemos en la segunda parte de esta publicación, con las observaciones y algunas alternativas de solución de este reto. ¡Hasta la próxima!
