Con el objetivo de mitigar posibles fallos en diferentes entornos o sistemas de la red, desde los últimos años, las empresas se han visto obligadas a realizar pruebas periódicamente a sus propias infraestructuras para corregir anomalías y agujeros que pongan en peligro la integridad, la disponibilidad la confidencialidad de sus activos. Este conjunto de pruebas es lo que se llama pentesting “penetration testing”.
La filosofía del pentesting se basa en identificar las vulnerabilidades y los puntos débiles de un sistema antes de que lo hagan entidades de terceros con intenciones maliciosas.
Pero, ¿cómo se hace un pentest? Esta pregunta no tiene una respuesta aplicable para todos los casos, puesto que en cada pentest se trabaja en un ambiente diferente (infraestructura, software…). Sin embargo, sí podemos extraer una metodología aplicable en la gran parte de pentests.
Esta metodología se explica a continuación con un ejemplo basado en un servidor propiedad de HackTheBox, una organización que diseña máquinas muy realistas, con el objetivo de formar a personas en el ámbito de la ciberseguridad. Cabe remarcar que en ningún momento se ha querido realizar una guía de cómo completar esta máquina, se han omitido ciertos pasos importantes para centrarse en el proceso general del pentest.
Pre-Engagement Interactions
En esta primera fase de un pentest el cliente indica cuáles son los objetivos y el área de ataque. Dependiendo de la información recibida por parte del cliente, se tratará de un pentest de caja negra (si no se conoce nada del sistema al que se atacará), un pentest de caja blanca (si se conoce todo sobre el sistema que se atacará) o un pentest de caja gris (si sólo se conocen algunos datos sobre el sistema a atacar).
Information Gathering
Proceso que se basa en obtener la mayor información posible para poder generar un perfil preciso del objetivo.
A continuación, se muestran ejemplos de una de las herramientas más utilizadas durante esta fase: Nmap, que es un escáner de puertos con muchas funcionalidades.
sudo nmap -p- <IP> orden que lista los puertos abiertos mediante TCP en un sistema.
Se muestra que los puertos 22 y 80 están abiertos mediante TCP. Además nos indica qué servicio suele acudir a cada puerto.
A continuación, un ejemplo para escanear los puertos abiertos del sistema que utilizan el protocolo UDP.
sudo nmap -sU -oN nmap/udp.nmap <IP>
Podemos observar que los puertos 161 y 3389 están abiertos, como dato interesante el puerto 161 maneja SNMP.
En este caso, se prioriza la investigación del puerto 161, un puerto crítico que no debería ser accesible desde el exterior. Debido a una mala configuración, se pueden obtener unas credenciales que nos permiten saber que el servidor utiliza una versión de Pandora en local en el puerto 80, a la que se puede acceder redirigiendo los puertos.
En la parte inferior de la página se ve que la versión de Pandora es la v7.0NG.742_FIX_PERL2020, una versión con vulnerabilidades conocidas.
Exploiting
Esta fase se basa en explotar las vulnerabilidades encontradas previamente y, en caso de encontrar más y ver hasta dónde se puede llegar.
Dentro de las vulnerabilidades conocidas de la versión v7.0NG.742_FIX_PERL2020 de Pandora, existe una inyección de SQL, documentada en Mitre (CVE-2021-32099).
Una inyección SQL es una vulnerabilidad que se basa en inyectar código SQL en un campo determinado para conseguir llamadas arbitrarias a una base de datos. Esto se debe a que no se comprueban correctamente los datos que introduce un usuario en un campo determinado.
Así pues, obtenemos las credenciales del formulario necesarias enviando una petición POST a la ubicación mencionada en la descripción del CVE con un parámetro session_id malicioso, que nos permite saltarnos la autenticación del servidor:
session_id=666' UNION SELECT 1,2,data FROM tsessions_php WHERE data LIKE '%user%' -- xxx
Una vez dentro de la interfaz explotaremos otra vulnerabilidad, también documentada en Mitre (CVE-2020-13851), un RCE (Remote Code Execution), que permite ejecutar comandos de forma remota. Se utiliza esta vulnerabilidad para generar una Reverse Shell y obtener acceso al sistema como usuario raso.
Una vez se ha conseguido acceder al sistema, mediante un script de enumeración llamado linPEAS, se puede observar lo siguiente:
En la última línea se puede ver información muy interesante, un archivo que tiene permisos de SUID, y que también puede ser ejecutado por el usuario que hemos conseguido.
Un binario con permisos SUID puede cambiar sus privilegios por los del propietario del archivo. Por tanto, si lo ejecutamos con el usuario que hemos conseguido anteriormente, el binario podrá obtener permisos de administrador, ya que root es el propietario del archivo.
Al examinar las llamadas de sistema que ejecuta, se puede ver que se llama el binario tar sin el path absoluto. Esto significa que si se modifica la variable de entorno $PATH y se crea un archivo llamado “tar”, se podrá ejecutar este archivo con privilegios de administrador.
Los siguientes comandos hacen esto mismo y ejecutan el binario:
export PATH=.:$PATH echo '/bin/bash' > tar chmod +x tar /usr/bin/pandora_backup
Éste es un ejemplo de escalado de privilegios, obteniendo permisos de administrador y, en consecuencia, el control total del servidor.
Por último, es necesario aclarar que un pentest no se basa únicamente en obtener acceso a una máquina, sino que consiste en intentar encontrar todas las vulnerabilidades o malas configuraciones que pueden poner en peligro la seguridad e integridad de un servicio.
Reporting
Esta fase final, se basa en agrupar todo lo que se ha encontrado y documentado para poder explicarlo todo de manera clara y fija. El documento final debe tener una recopilación de todas las vulnerabilidades encontradas, las respectivas mitigaciones y la manera en que las primeras se han encontrado. De esta forma, a la hora de que los desarrolladores tengan que arreglar las vulnerabilidades, serán capaces de replicarlas para asegurarse de que se han resuelto correctamente.