[Write UP]. Solución del Primer Reto Hacker para aprender

En el siguiente artículo muestro todos los pasos que he realizado hasta dar con la solución del Primer del Reto Hacker de este curso que nos ha propuesto por Amador Aparicio y que se publicó hace poco en este blog.

Figura 1: [Write UP]. Solución del Primer Reto Hacker para aprender.

En primer lugar, he procedido a descargar y montar una máquina virtual en VirtualBox a partir del fichero .OVA entregado en el enunciado del Reto Hacker:

Figura 2: Recursos necesarios para la resolución del Reto Hacker.

Creación del Entorno de Pruebas

La configuración para el adaptador de red de la máquina virtual será “modo Red Interna”. A efectos prácticos, cualquier otra máquina virtual con el adaptador de red en “modo Red Interna” estaría en el mismo segmento de red pero sin conexión con otras redes.

Figura 3: Configuración de los adaptadores de red de las máquinas virtuales sobre VirtualBox.

Utilizaré también una máquina virtual Kali Linux para realizar las pruebas necesarias. La dirección IP de esta otra máquina estará dentro de la red 1.0.0.0/24.

Comunicación con “matrix”, la máquina objetivo

Al intentar comunicarnos con la máquina “matrix” a través de peticiones de tipo ICMP (8), vemos que ésta no nos responde. Hacemos un escaneo rápido de tipo SYS con nmap a todos los puertos TCP de la máquina objetivo, “matrix”, y vemos que los resultados son negativos.

Figura 4: Configuración IPv4 de la máquina Kali Linux. Resultados del escaneo de tipo SYS.

Esto nos da a entender que las conexiones a primera vista están bloqueadas por algún tipo de firewall en la máquina “matrix”, muy posiblemente con IPTables. Regla de oro básica en el Hardening de servidores GNU/Linux.

Figura 5: Libro de Hardening de servidores GNU/Linux 3ª Edición.

Vamos a analizar el archivo .pcap con Wireshark para ver si llegamos a alguna conclusión de lo que está sucediendo. Para ello utilizaré el filtro “ip.addr==1.0.0.1” para ver con qué direcciones IPv4 se ha comunicado “tokio”.

Figura 6: Conexión TCP al puerto 22/TCP desde la máquina 1.0.0.254.

Como podemos ver, la maquina ha recibido una conexión TCP al puerto 22/TCP desde otra máquina cuya dirección IP era la 1.0.0.254. Esto nos da a entender que al menos tiene que permitir conexiones al puerto 22/TCP si ponemos esa dirección IPv4 a nuestra máquina. Cambiamos la dirección IPv4 de la máquina Kali Linux asignándole la dirección 1.0.0.254/24 y realizamos las pruebas anteriores.

Figura 7: Cambio de IP en Kali Linux. Nuevo escaneo de tipo SYN.

En efecto, como podemos ver ahora, la maquina objetivo tiene el puerto 22/TCP (servicio SSH) abierto.

Pruebas de acceso a la máquina objetivo, matrix.

Puesto que ya sabemos un nombre de usuario (“tokio”) de esa máquina que tiene permitido el acceso por SSH, realizaremos un ataque de fuerza bruta basado en diccionario desde nuestra máquina de ataque basada en Kali Linux.

Figura 8: Libro de Pentesting con Kali Linux en 0xWord

Para poder realizar un ataque de fuerza bruta lo que se necesita es la herramienta que lo realice, NCrack, y un diccionario de contraseñas para que el programa pueda probar continuamente hasta que dé con una contraseña valida. Como diccionario he utilizado el mismo que usa la herramienta JohnTheRipper.

Figura 9: Diccionario usado por la herramienta JohnTheRipper con 3651 palabras.

En mi caso, el diccionario lo he obtenido de la web https://wiki.skullsecurity.org/Passwords. Con el diccionario ya en nuestro poder podemos proceder a realizar un ataque de fuerza bruta sobre la contraseña sobre el usuario “tokio” del servicio SSH.

Figura 10: Ataque de fuerza bruta con diccionario sobre el servicio SSH para el usuario "tokio".

Sorprendentemente vemos que ha funcionado y nos ha dicho que la contraseña valida es “qwerty”. Hay que decir que, en esta parte, al principio había usado el diccionario de Cain&Abel, que es muchísimo mas grande, pensando que la clave sería más rara, pero tras 5 minutos y solo avanzar un 2% decidí probar paralelamente el diccionario de JohnTheRipper y en 1 minuto dio resultado. A veces  Con el acceso al servidor conseguido procedemos a entrar por SSH:

Figura 11: Acceso al servicio SSH con el usuario tokio.

Ya que estamos dentro y, por mera curiosidad, vamos a ver qué reglas de firewall tiene aplicadas iptables en la configuración de seguridad del tráfico de red.

Figura 12: Reglas de iptables en la máquina matrix.

Efectivamente, por defecto las políticas del firewall bloquean cualquier conexión que no venga de localhost o de la dirección IPv4 1.0.0.254. Por eso en un principio no pudimos conectarnos con otra dirección IP.

En búsqueda de la tabla de la base de datos

Bueno, vamos al lio, y revisar qué encontramos en la base de datos MySQL que tiene instalado el servidor. Vamos a ver si podemos conectarnos con las mismas credenciales.

Figura 13: Conexión al SGBD con un cliente MySQL.

Vemos que se nos permite realizar la conexión con este usuario, así que podemos analizar qué bases de datos tenemos disponibles en este servidor MySQL.

Figura 14: Base de datos disponible para usuario 'tokio'.

Como se puede observar, el usuario tokio no ha creado ninguna base de datos, ya que sólo tiene disponible el diccionario de datos del SGBD. Esto nos quiere decir que este usuario no ha sido el que ha creado la base de datos con la tabla que se propone en el enunciado del reto, pero al menos no la base de datos.

Figura 15: Libro de Linux Exploiting

Aquí he estado atascado un tiempo, hasta que me dio por ver si podía entrar con el usuario root a ver si el tenia otras tablas. Pero para ello habría que conseguir la credencial del usuario root, o bien buscando una vulnerabilidad explotable o bien realizando un ataque de diccionario al usuario root tal y como se ha hecho a tokio. Estando en local, tal vez es posible acceder a inicio de sesión con root.

Escalada de privilegios

Ya que el usuario “tokio” no ha creado ninguna tabla vamos a ver si “root” nos muestra algo diferente, y, el error que nos encontramos es que el usuario tokio y el usuario root comparten la misma contraseña. Probablemente el administrador (root) creo a tokio y no tenía ganas de aprenderse otra contraseña. Un error muy común cuando una persona tiene que gestionar muchas credenciales y no utiliza un gestor de contraseñas - o tiene un 2FA - para protegerlas.

Figura 16: Con su y probando la misma password (password guessing) entramos.

Vemos que el usuario “root” tiene la misma contraseña que el usuario “tokio”, lo cual es muy conveniente para un atacante como yo. Y como he dicho, que no tenga un 2FA ayuda mucho más. Menos mal que no tenían configurado SSH en Paranoid Mode. Vamos a ver si nos deja conectarnos a MySQL para inspeccionar qué bases de datos hay disponibles.

Figura 17: Conexión con el usuario “root” al SGBD.

Interesante, nos deja entrar con el usuario “root” y además vemos que hay una base de datos que se llama “reto1”. Veamos que hay en ella:

Figura 18: Contenido de la tabla "flag".

Bueno bueno, pues vemos que hemos encontrado la “información sensible”. Se ve que esta gente estaba esperando a que alguien entrara a husmear.

Conclusiones

Decir que al principio perdí algo de tiempo pensando que había que descodificar la contraseña de algún modo por la información entregada en el dump del fichero .pcap, pero llegue a la conclusión de que SSHv2 es un protocolo bastante seguro ya que cifra la comunicación entre el cliente y servidor. Cuando ya me dio por probar “a entrar” utilizando fuerza bruta, ya todo empezó a tomar forma, aunque hasta que no conseguí la clave no pensé que fuera ese el método que quería Amador.

Una vez conseguida la contraseña, también me llevo un rato llegar a la conclusión de cambiar al usuario “root”. Pero lo mejor de todo, es que tuve que probar diferentes estrategias y utilizar distintas herramientas de configuración, del sistema y de ataque.

Autor: Rodrigo Díez Fernández (https://diezrofer.es/), estudiante de Administrador de Sistemas Informáticos en Red en Salesianos Villamuriel.