LinPEAS versus IA: Cómo usar un Copilot para escalar privilegios en GNU/Linux

Cuando uno se enfrenta al proceso de escalada de privilegios en sistemas GNU/Linux, LinPEAS es una de las herramientas obligatorias para mí. Me gusta por muchos motivos, pero sobre todo por toda la información que nos proporciona y que facilita el encontrar vectores de actuación. Cuando uno está empezando, entender toda la información que verifica y que nos muestra LinPEAS no es sencillo.

Figura 1: LinPEAS versus IA - Cómo usar un Copilot

para escalar privilegios en GNU/Linux

Hay que echarle tiempo y entender todo lo que la herramienta nos está diciendo. Lo más recomendable es entender todo lo que hace “por debajo” y poder usarla para optimizar el tiempo, encontrando un vector o varios que nos puedan llevar a la escalada en un pentest.

Figura 2: GitHub de LinPEAS

En este artículo se enseñará cómo LinPEAS ayuda a identificar vectores potenciales para lograr la escalada en un sistema GNU/Linux y cómo la IA también puede ayudarnos siendo el ayudante operativo que nos ayude a procesar gran cantidad de información. 

Figura 3: "The Art of Pentesting" El nuevo libro de

0xWord para formarse como pentester

Lo ideal es que utilicemos un modelo privado (en local) por temas de que si fuera un pentest real los datos son críticos. Como esto es una demostración, utilizaremos a ChatGPT (y aprovecharemos su potencial). Para el ejemplo, partiremos del siguiente escenario. Vamos allá.

• Tenemos una máquina con dos configuraciones diferentes.

• En la primera configuración, tenemos dos errores que provocarán la escalada de privilegio. Partiendo de un usuario, por ejemplo, ‘pepito’ el cual no es un sudoer, ni tiene privilegio de nada en el sistema. Deberemos pasar al usuario ‘pablo’, el cual sí es un sudoer. Posteriormente, deberemos pasar a root.

• En la segunda configuración pasaremos del usuario ‘pablo’ a root, pero ¿Qué técnicas deberemos utilizar en cada una de las configuraciones?

• El objetivo del ejercicio es ver cómo LinPEAS nos ayuda y cómo un modelo de IA fundacional (y mejor si está especializado en este campo) nos pueden guiar. Incluso, podemos utilizar herramientas clásicas y comprenderlas mejor con el modelo de IA.

Escenario 1: LinPEAS from scratch

En este escenario partimos de que tenemos una shell remota, la cual se puede haber obtenido a través de una explotación remotamente. Ahora, identificamos privilegios en el sistema y se ve que el usuario no pertenece a ningún grupo con privilegio en el sistema. Todo esto, realmente, lo va a poder realizar LinPEAS, por lo que voy a lanzar LinPEAS en el sistema. 

Figura 4: Ejecución de LinPEAS

Ejecutamos a través de la shell remota el siguiente comando:

curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh.

Ahora, toca analizar los resultados que desprende el uso de la herramienta. Lo primero de todo es tener claro la leyenda que nos proporciona LinPEAS. Se puede ver como un RED/YELLOW proporciona un vector de escalada con una probabilidad alta. Los valores en rojo, tal como se ve en la imagen, también hay que tenerlos en cuenta y analizarlos, ya que pueden ayudar a la escalada.

Figura 5: Posibles Vectores de Escalada

Una de las primeras cosas que se enseña que hay que revisar en la escalada son las versiones de las aplicaciones con privilegio, revisar los hotfix instalados y revisar versiones de kernel. Como se puede ver en la imagen, LinPEAS hace uso de una enumeración y análisis para poder identificar posibles vulnerabilidades. Para ello hace uso de Linux Exploit Suggester (hay que recordar también su versión en Windows, llamada Windows Exploit Suggester) y muestra una serie de resultados de la posibilidad de que haya encontrado un vector de explotación.

Figura 6: Linux Exploit Suggester

La salida es muy larga, por lo que no se puede mostrar todo (recomendado probarlo en vuestro laboratorio). Siguiendo hacia abajo se puede encontrar una serie de datos interesantes: son ficheros relacionados con SSH. Una clave pública (y la privada también estaba en el sistema), el fichero de equipos conocidos (es decir, las máquinas a las que se ha conectado el usuario ‘pepito’ (o nopriv) y el fichero de claves autorizadas.

En este caso, se puede ver un dato curioso el valor de authorized_keys del usuario ‘pablo’ es el mismo que el de la clave pública del usuario ‘pepito’. No nos lo dice LinPEAS, pero se puede relacionar viendo el valor de los ficheros. Esto quiere decir que, muy probablemente, el usuario ‘pepito’ puede hacer login como usuario ‘pablo’ a través del uso de clave pública (y la clave privada se encuentra en el home de ‘pepito’.

Figura 7: Claves ssh

Justamente, si seguimos un poco más abajo en la salida de LinPEAS encontramos esto. En efecto, la clave privada se encuentra disponible. El pentester podría llevarse la clave privada a su equipo e intentar acceder como el usuario ‘pablo’ (sin conocer la credencial de éste, ya que la autenticación se realizará por clave pública).

Figura 8: Posibles claves privadas encontradas

En un movimiento un tanto extraño, se puede identificar que el usuario ‘pepito’ (o nopriv en la máquina) puede autenticarse como el usuario ‘pablo’. ¿Será algún tipo de escalada? También LinPEAS nos vuelva toda la información de usuarios y grupos y se puede ver que ‘pablo’ es un usuario de tipo sudoer, por lo que respecto al usuario ‘pepito’ sí hay una escalada (sin llegar a ser root).

Figura 9: Libro de Ethical Hacking 2ª Edición
de Pablo González en 0xWord

Una vez que somos ‘pablo’ a través de una conexión local de SSH (como decía un tanto raro) hay que seguir analizando con LinPEAS. La herramienta marca que el usuario pablo pertenece al grupo sudo. Esto hace pensar que habrá que configurar la configuración de éste.

Figura 10: Usuario pablo en el grupo sudo

En la revisión de la configuración de sudo se puede encontrar la etiqueta NOPASSWD, algo no recomendado de configurar. Se puede ejecutar como sudo y sin contraseña 3 scripts. Esto, a priori, puede no suponer mucho, habrá que estudiar si se puede hacer algo con esos scripts.

Figura 11: Se pueden ejecutar 3 scripts sin password

Por un lado, la etiqueta NOPASSWD sobre 3 scripts y después, LinPEAS, indica que el script /usr/local/bin/echo.sh tiene permisos de escritura para otros usuarios, es decir, podremos modificar el contenido de dicho fichero (o sobrescribirlo completamente). A partir de aquí, se puede ejecutar como sudo y colocando, por ejemplo, una llamada de netcat desde el propio script a un listener que tengamos nosotros y conseguir ser root. 

Figura 12: Script echo.sh con permiso de escritura

Analizando en la siguiente configuración con LinPEAS podemos encontrar algunas cosas interesantes: el bit SUID activo sobre algún binario que no debiera, tareas programadas con permisos débiles, un posible path hijacking, etcétera. LinPEAS nos da mucha información y proporciona un gran número de chequeos, los cuales hay que podar y quedarse con la información de interés.

Figura 13: Más posibles vectores de explotación

En la imagen, se puede la evaluación del bit SUID y como se encuentra un binario interesante. Por otro lado, se recomienda utilizar el proyecto GTFOBins con el que se puede obtener mucha información de los binarios y de los vectores de escalada que se pueden utilizar.

Figura 14: Tareas ejecutadas en el cron como root

Otro punto débil es el cron. Tareas ejecutadas cada minuto como root. Hay que revisar el fichero /deploy.sh.

Escenario 2: El modelo como ayudante de pentester

Ahora, el segundo escenario consiste en dos cosas:

• Evaluar la información que recopila LinPEAS y mostrar las capacidades de un modelo como copiloto.

• Ir desgranando el proceso paso a paso e ir ayudándote del modelo con pequeños trozos de información.

Éstas serían las dos primeras aproximaciones que se pueden llevar a cabo. Para empezar, volcaremos la información sobre el modelo (todo lo que ha recopilado LinPEAS) y le diremos que analice y que nos diga que encuentra. La verdad es que devuelve mucha información. Hay que fijarse que en el punto 4 (de los 10 que nos saca) nos habla de las claves SSH (siempre son un punto a tener en cuenta). De momento es una aproximación y el modelo da algunas pautas y un análisis un poco más superficial de lo que se ha ido encontrando con LinPEAS.

Figura 15: Analizando la salida de LinPEAS

Ahora, le pedimos que haga un análisis del componente de las claves SSH y ficheros relacionados. El resultado nos indica que la clave pública id_rsa.pub y authorized_keys son idénticas y nos sugiere que la clave pública permite al usuario ‘pepito’ (en la máquina usuario ‘nopriv’) autenticarse en el sistema como usuario ‘pablo’ sin necesidad de contraseña. El análisis es correcto por parte del modelo.

También se realiza un análisis de la seguridad de las claves utilizadas en la máquina. Y por último, nos indica el modelo que si la clave privada id_rsa está comprometida (y lo está, ya que tenemos acceso) se puede utilizar para autenticarse en el mismo sistema, por SSH, como el usuario ‘pablo’.

Figura 16:  Análisis del problema de las claves

Este es un buen ejemplo de lo que es un copiloto o ayudante en ciberseguridad y en este caso en pentesting. Ahora, se le indica al modelo que analice toda la salida generada por LinPEAS y el resultado nos indica muchas cosas:

1.- Nos analiza lo que se puede ejecutar con sudo sin contraseña (evalúa la etiqueta NOPASSWD). Además, nos indica que echo.sh es escribible, por lo que nos da un ejemplo de como conseguir una shell con privilegio de root (dicha técnica funcionaría en este ejemplo).

Figura 17: Ejecuciones con sudo sin contraseña

2.- Detecta que el fichero /etc/passwd es escribible, por lo que se puede añadir un usuario al sistema con el UID y GID de 0, siendo root en el sistema.

Figura 18: Fichero /etc/passwd con permisos de escritura

3.- Evalúa ficheros con SUID activo e indica cuál cree que puede ser utilizado. Nos pone en el camino. Aquí es recomendable que el pentester revise junto al proyecto GTFOBins comentado anteriormente. Todo lo que el modelo nos dice tenemos que tratarlo de la forma adecuada. Son ayudas de un ayudante, la palabra final es nuestra como especialistas.

Figura 19: Ficheros con SUID activado

4.-Evalúa el crontab. Nos indica una posibilidad para escalar, siempre y cuando /deploy.sh se pueda modificar. El modelo no tiene información sobre los permisos del fichero deploy.sh, por lo que no puede indicarnos más, pero nos deja el vector marcado.

Figura 20: Análisis del crontab

5.- Aquí está de nuevo el caso de las claves SSH y los ficheros relacionados. Lo explica de nuevo bastante claro, aunque este caso, quizá lo explicó mejor cuando le preguntamos concretamente sobre ello.

Figura 21: Análisis de las claves SSH

Esto es el contexto híbrido. Trabajo como especialista y me ayudo de un ayudante que la IA me proporciona. Importante, hay que tener en cuenta que en muchos campos será necesario utilizar modelos locales que aporten privacidad a los datos manejados. Esto será fundamental, para que los copilotos y ayudantes estén en el día a día de los profesionales de la ciberseguridad. Esto es solo un ejemplo, de lo que puede ayudarnos un modelo, donde no pretendemos que nos haga todo, si no que nos de puntos de vista y ayude en lo que pueda.

Moraleja 

El contexto híbrido y la incursión de la IA en ciertos procesos de la ciberseguridad es obvio. Además, el concepto de copiloto o ayudante será cada vez más utilizado para que entendamos que podemos valernos de estos sistemas que harán nuestro trabajo más eficiente.

Saludos,

Autor: Pablo González Pérez, escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de Telefónica Innovación Digital.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Contactar con Pablo González

Servicios SSH: "Tips" de Auditoría y Fortificación

SSH es uno de los protocolos/servicios más utilizados en la gestión de máquinas y servidores de forma remota. Por esta razón la configuración y fortificación de este protocolo es fundamental. En este artículo vamos a ver algunos consejos para mejorar la seguridad y algunos otros para comprobar dicha seguridad, ya que es uno de los más expuestos y por ende de los más atacados también.

Figura 1: Servicios SSH: "Tips" de Auditoría y Fortificación

Ya hemos visto en los últimos años como ha habido varios problemas con configuraciones SSH, incluso vulnerabilidades. Solo hay que recordar el caso de SSHowDown y los millones de dispositivos IoT afectados y su participación en la botnet Mirai. Algo que obliga a todos los administradores de servidores SSH a tener una extremada precaución en la fortificación de sus servidores.

Figura 2: Libros de Linux Exploiting y de Hardening de Servidores GNU/Linux

Esto nos llevó a realizar un trabajo de fortificación de SSH en Paranoid Mode que hicimos en ElevenPaths en el que utilizamos muchas medidas de protección como Port-Knocking usando Latch para reducir la exposición del servicio a los escaneos de red que los buscan, el uso de Latch Cloud TOTP como 2nd Factor Authorization, y los certificados digitales como mecanismo de autenticación. Todo esto, lo publicamos en el artículo de Cómo configurar tu SSH en Paranoid Mode.


Figura 3: Demo de Port-Knocking + Latch Cloud TOTP & Aut + Lath como 2FA
Por otro lado, para la enumeración de usuarios hemos visto que se podían realizar ataques Time-Based Blind User Enumeration en OpenSSH, de los que hemos tenido que preocuparnos también, lo que deja claro que cualquier pequeño detalle de seguridad puede proporcionar cierta ventaja a un atacante que descubra una mala configuración o una vulnerabilidad de versión.

Figura 4: Ataque de Time-Based Blind User Enumeration a SHH desde Kali Linux

Por esto, revisamos cualquier configuración, como vimos que se podía hacer con la aplicación Lynis, una herramienta más que interesante para evaluar la seguridad de la configuración de nuestro servicio SSH.

Figura 5: Resumen de una auditoría de SSH hecha con Lynis

Hoy queremos hacer un recopilatorio de algunos consejos y trucos que ayudan a la fortificación y lo mismo para que los administradores o miembros de los Blue Team o Red Team puedan comprobar si la fortificación es adecuada.

Tips sobre fortificación de SSH

Existen muchas recomendaciones y debate sobre la fortificación del protocolo SSH. Pero al final se debe seguir un patrón muy sencillo que es la de aplicar los principios de la fortificación de cualquier sistema, es decir aplicar los objetivos de Mínima Superficie de Exposición posible, Mínimo Privilegio Posible y, por supuesto, Defensa en Profundidad, que es significa aplicar cualquier medida de seguridad en cada nivel asumiendo que las medidas anteriores han fallado, siempre y cuando una medida no anule a otra.

Un ejemplo de medida del primer tipo, es decir de conseguir  la Mínima Superficie de Exposición, es la medida que comentamos al inicio de este artículo de utilizar un mecanismo de Port-Knocking para que se habilite el puerto de conexión del servicio SSH. El servicio aparecerá como cerrado hasta que haya una combinación de peticiones previas a un puerto o se haya hecho algún tipo de de autorización para que el servicio SSH se encuentre activo, como explicamos en MySSH en Paranoid Mode.

Figura 6: Port-Knocking realizado con TCP Flags

Esta simple acción pude minimizar mucho el riesgo de la exposición de un servicio a Internet. Es cierto que, para muchos usuarios, será un “ajetreo” tener que realizar alguna acción para habilitar durante X segundos el servicio SSH y conectarse a él. Como todo en la vida, hay que valorar y evaluar los riesgos y la productividad que se necesita. Ni mejor, ni peor. Simplemente una opción que aporta la ciberseguridad y el hardening paranoico.


Figura 7: Demo de Port-Knocking con Latch

Por otro lado, tenemos medidas para conseguir que todo se ejecute en el servidor con el Mínimo Privilegio Posible, para que, en caso de quedar comprometido un módulo, los permisos que haya obtenido el atacante sean los menores posibles. Es decir, en el caso de que un servidor sea vulnerado debemos poner las cosas difíciles por defecto. Si ejecutamos el SSH con el usuario root y éste es comprometido tendremos un grave problema. Si el daemon SSH es vulnerado, pero éste se está ejecutando sin ningún privilegio, el problema es menor, aunque seguimos teniendo un problema.

Además, otra forma de hacer mínimo privilegio posible es que el login que se haga sea el de un usuario sin privilegio. Por ejemplo, el usuario root no puede hacer login con el SSH, pero una vez dentro con el usuario “pepito” se podría pasar al usuario “root” una vez se tiene una consola remota. Es una forma de evitar que mediante fuerza bruta se pueda hacer ataques al servicio SSH y que alguien pueda “adivinar” la contraseña del usuario. En el caso de que un “bot” pueda hacer fuerza bruta contra el servicio debe conocer la existencia de un usuario “pepito” y la contraseña de éste. Si dejamos que root pueda hacer login, ya fijamos una de las dos variables, por lo que la cosa se simplifica, es decir, hacemos que un atacante tenga más fácil el atacarnos.

Figura 8: Fail2Ban

Para evitar los ataques de fuerza bruta debemos contemplar el uso de herramientas como Fail2Ban. Este tipo de herramientas permiten configurar reglas para poder bloquear direcciones IP, usuarios, etcétera, que intenten realizar fuerza bruta en el sistema. Fail2Ban está desarrollada en Python y tiene como función penalizar la conexión de una dirección IP origen que intenta fuerza bruta. Fail2ban se encarga de realizar la búsqueda en los logs de ciertas aplicaciones, no solo en el SSH, pero en este caso se puede utilizar para SSH.

Cuando Fail2ban detecta una serie de intentos fallidos por parte de una dirección IP, la aplicación tomará la acción programada sobre dicha dirección IP. Por supuesto, el administrador puede ser notificado de este evento, por ejemplo, a través del correo electrónico. Además, se puede bloquear puerto o puertos a través del uso del firewall que corresponda de forma automática al ejecutarse una regla de Fail2ban.

Ahora, vamos a recordar consejos básicos de configuración y fortificación de entornos SSH para aplicar medidas de Defensa en Profundidad. Directamente los vamos a enumerar. Todos se habilitan, se deshabilitan o se configuran a través del fichero /etc/ssh/sshd_config:

• El login como root: La directiva es PermitRootLogin. En muchas ocasiones ya viene deshabilitada.

• Número de intentos para hacer login: Esta directiva permite cerrar la conexión tras una serie de intentos de login fallidos. La directiva es MaxAuthTries. Un número bajo de intentos es lo adecuado. Esto hará que una automatización de ataque tenga que realizar una nueva conexión cada vez que se cierra la conexión.

• Tiempo máximo de Login: Esta directiva indica el número de minutos o segundos que tenemos para realizar el login antes de cerrar conexión. La directiva es LoginGraceTime.

• La directiva AllowGroups y AllowUsers: Permiten gestionar que grupos o usuarios pueden hacer login en el servicio a través de SSH. Aquí se puede indicar un patrón del estilo [user]@[host], dónde host puede ser una dirección IP origen, por lo que se aplica un filtro de forma explícita en la conexión. La política contraria es DenyGroups y DenyUsers, las cuales hacen justamente lo contrario, una lista negra de usuarios y grupos que pueden conectarse a través de SSH.

• La directiva ClientAliveInterval y ClientAliveCountMax: son dos directivas que indican que si el servidor no recibe datos de un intervalo X la conexión se cerrará. En el caso de la segunda directiva, se enviarán un máximo de X mensajes, indicados por la directiva, solicitando al cliente datos, si éste no envía nada se cierra la conexión. Son directivas para identificar una conexión que se ha quedado perdida o “muerta”.

• La directiva LogLevel: es una directiva interesante para alimentar el log con información, el cual puede servir a otras herramientas forenses o de fortificación, como Fail2ban.

• La directiva para el tipo de autenticación: La recomendación en el mundo SSH es que la autenticación siempre vaya a través de public-key. Deshabilitar el login mediante password y otros métodos que no son interesantes para la seguridad.

• La directiva Ciphers: Esta directiva indica los tipos de algoritmos que se pueden utilizar entre el cliente y el servidor para fortificar la conexión. Es importante que los algoritmos sean robustos, así como que la versión del protocolo SSH sea la 2.

Todos estos consejos y recomendaciones, y muchas más se puede encontrar en el libro de 0xWord titulado "Hardening a Servidores GNU/Linux", el cual escribí junto a mi compañero Carlos Álvarez, que hemos ido actualizando con el tiempo.

Y ahora, vamos a ver algunos consejos para lo contrario, es decir, para auditar si la configuración de seguridad es la correcta o existe alguna debilidad que pueda ser aprovechado.  En el principio del artículo ya hemos visto algunos vectores de ataque para enumerar usuarios, para realizar fuerza bruta o para verificar la versión y las posibles vulnerabilidades del servicio.

Figura 9: Libro de Ethical Hacking de Pablo González

En esta parte no vamos a reinventar la rueda y lo único que vamos a hacer es enumerar una serie de vectores que pueden ser utilizados en un proyecto de Ethical Hacking o en un ejercicio de Red Team:

• Password guessing / Fuerza bruta: Si se puede fijar un usuario X, porque conocemos de su existencia en el sistema, por ejemplo, con la enumeración de usuarios basados en tiempo de OpenSSH, se puede realizar un ataque de fuerza bruta o de diccionario. Este ejemplo, se puede llevar a cabo con diferentes herramientas, por ejemplo, Metasploit a través del módulo auxiliary/scanner/ssh/ssh_login. Otra de las herramientas que se puede utilizar es Medusa o NCrack.

• Vulnerabilidades sobre la versión del software que implementa el servicio SSH: Uno de los ejemplos más importantes es este CVE-2018-10933, también conocido como LibSSH RCE. En otras palabras, obtener la versión del software de la aplicación del SSH nos puede abrir una superficie de ataque importante, ya que con un exploit conocido, se puede llegar a lograr ejecutar código arbitrario en la máquina. En este punto se abre un abanico enorme, ya que aquí se habla de librería vulnerable, pero si el software no utiliza dicha librería, pero es vulnerable por otra circunstancia también se podría aplicar la vía exploit.

• Aplicación de fuzzing manual y automatizado: Este es otro vector que se puede utilizar, por ejemplo, a través del script sshfuzz.pl. Otra opción que se puede utilizar es un módulo de Metasploit llamado auxiliary/fuzzers/ssh/ssh_version_2. Hay más información sobre este tema en este interesante artículo.

• La herramienta ssh-audit: como hablamos antes de Lynis, es interesante para hacer una pequeña auditoría a la configuración del servidor SSH.

Figura 10: Herramienta ssh-audit

Por supuesto que aquí no acaba el tema. Se puede hacer uso de guidelines para fortificar y atacar servidores SSH. Mozilla proporciona una guía interesante sobre este tema, la cual se recomienda echar un ojo. Por último, respecto al tema del pivoting, una de las técnicas necesarias en las auditorías internas de sistemas, podemos encontrar un listado de técnicas basadas en SSH interesantes. De estas ya iremos hablando, tal y como hablamos de la primera de ella ya en otro artículo, pero toma nota de ellas.

• SSH Local port Forwarding
• SSH Reverse port Forwarding
• SSH Dynamic port Forwartding
• SSH Reverse port Forwarding junto a Proxy SOCKS
• VPN sobre SSH
• Túnel HTTP sobre SSH
• Proxy transparente sobre SSH

Todas ellas son técnicas para estudiar en profundidad, y las iremos desgranando en diferentes artículos, pero tú puedes ir probándolo también. Espero que os sea de utilidad esta lista de "tips" para las dos cosas, para fortificar y para auditar servicios SSH, que hoy nos los encontramos en casi cualquier servidor, y en casi cualquier dispositivo industrial o de IoT.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.
Para consultas puedes usar el Buzón Público para contactar con Pablo González

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