# ¿Qué es el pentesting?
Podemos defenir que son normalmente un conjunto de “tests de penetración” basados en ataques hacia sistemas informáticos con la intencionalidad de encontrar debilidades y/o vulnerabilidades relativas a la seguridad, pudiendo clasificar más determinar el alcance y la repercusión de las mismas.
Grosso modo y a un nivel más practico como visual, quiero hacer referencia a una película de culto denominada Sneakers (Los fisgones) de 1992 dirigida por Phil Alden Robinson y como protagonista principal Robert Redford, donde mediante una de sus escenas iniciales podemos entender de que se trata un pentest a nivel de seguridad física combinando dotes de “ingeniería social” con un background técnico en diferentes áreas por cada pentester y posiblemente en un entorno de “caja negra” (donde no se ofrece ninguna información al pentester sobre la infraestructura, sistemas utilizados, etc).
# Tipos de pentesting
Podemos clasificar las pruebas de penetración de 3 tipos:
- Tests de caja blanca: Se dispone de toda información de la aplicación, sistema y/o arquitectura.
- Tests de caja gris: Se dispone de información parcial de la aplicación, sistema y/o arquitectura.
- Tests de caja negra: No se dispone de ninguna información de la aplicación, sistema y/o arquitectura.
Cada tipo de pentesting normalmente va determinado en base a las condiciones que establece el cliente, donde esas condiciones suelen ir relacionadas con la visibilidad, como por ejemplo simular la visibilidad de un atacante de forma externa, un atacante de forma interna, etc.
Como es lógico, en las pruebas de penetración cuanto menos información dispongamos del objetivo a testear, más complejo nos resultará inicialmente poder realizar el pentesting, dado que existe una fase de recopilación de información (fingerprinting y footprinting) que determinará la visibilidad que tenemos sobre esa aplicación, sistema y/o arquitectura a realizar los tests, por lo que sin información previa tendremos que realizar un esfuerzo grande y bastante meticuloso a la hora de recopilar estos datos si no queremos hacer pruebas y pruebas en vano sin obtener resultados.
# Metodologías de pentesting
A la hora de realizar pentesting disponemos de diversas metodologías las cuales podemos seguir o bien podemos tomar como referencia a la hora de realizar nosotros nuestras propias auditorías, esto ya es según las necesidades de cada uno, pues por requerimientos es posible que haya que cumplir algunas determinadas.
Algunas de las metodologías de pentesting serían:
- ISSAF
- PCI
- PTF
- PTES
- OWASP
- OSSTMM
- Cyber Kill Chain
Si bien hablar en profundidad de todas ellas en un post es básicamente poco viable, ya que por ejemplo ISSAF dispone de la friolera de ~845 páginas, OWASP ~349 páginas, OSSTMM ~213 páginas… si nos centraremos en algunas de ellas donde el objetivo sea recoger ideas interesantes de las mismas para comprender y estructurar como y en que se basa el pentesting.
> PTES
Penetration Testing Execution Standard junto a OWASP (más adelante hablaremos de ella) ya han logrado definir y generar conciencia sobre lo que es realmente una prueba real de tests de penetración. PTES además de ser adoptada por múltiples profesionales altamente reconocidos en el sector ya es un referente inclusive en libros de aprendizaje de referencia de por ejemplo frameworks asociados al pentesting como el conocido Metasploit de Rapid7.
Si bien es cierto, anda algo desactualizada y no es la más utilizada, si dispone de meticulosidad, siendo la misma alta y llegando a tener niveles de detalle también altos como bien definidos, donde la facilidad de implementación de la misma es relativamente sencilla. La misma es aplicable a cualquier aplicativo, sistema y/o arquitectura y es aconsejable combinarla con otras como OWASP.
Dispone de 7 fases que enumeraremos de forma genérica y serían:
1. Fase de toma de requisitos y alcance
Básicamente es la típica toma de requisitos donde se define el alcance de lo que se va a hacer, es decir, las restricciones que habrán de cara a lo que se puede o no hacer durante la prueba del trabajo, ya vengan determinados por tiempos, objetivos, etc.
2. Capturar toda la información posible
Consiste en reunir la máxima información posible sobre lo que se está evaluando, siempre con carácter relativo a la seguridad donde nos pueda ser útil de cara a fases posteriores.
3. Modelando las posibles amenazas antes de atacar
Tras la adquisición de datos de la fase anterior, aquí se procede a realizar un modelado de las amenazas, determinando los posibles ataques que se utilizaran.
4. Analizando las vulnerabilidades de las posibles amenazas
Una vez definido los ataques a realizar, se analizarán en profundidad y correlacionarán con debilidades y/o vulnerabilidades para determinar los ataques finales.
5. Explotando las vulnerabilidades
La fase más “visual”, ya que aquí se lanzaran los ataques hacia el objetivo por medio de determinadas técnicas para lograr el éxito de la penetración.
6. Post-explotación determinando daños y como arreglarlos
Aquí determinaremos el valor y sensibilidad que pueda tener lo que hemos comprometido, así como su utilidad, identificando y documentando desde los datos sensibles, cualquier opción de configuración, relaciones con otros elementos (posibilidad de realizar pivoting), etc.
7. Informe
El informe es el documento que tiene por objetivo definir y dar visibilidad del estado de la seguridad en los elementos tratados en el pentesting. Básicamente es el resultado final, por lo que debe estar lo bien realizado como para darle la visibilidad real y exacta de lo que ha sucedido, como el estado actual de sus aplicaciones, sistemas y/o arquitectura a nivel de seguridad proponiendo las soluciones o medidas correctoras a aplicar.
Podemos encontrar información detallada sobre como aplicar PTES en http://www.pentest-standard.org/index.php/Main_Page.
> OWASP
Enfocada a un contexto de “caja negra”, donde no se nos proporciona información sobre el aplicativo, sistema o arquitectura de la que debemos realizar el pentest. Muchas veces se proporciona un simple dominio donde deberemos ir tirando del hilo hasta conseguir encontrar debilidades y/o vulnerabilidades en todo lo que conforma a las aplicaciones web relacionadas con el propio dominio o cliente.
Bastante actualizada pero centrada principalmente en aplicativos web, dispone de meticulosidad, siendo la misma más alta que la de PTES y llegando a tener niveles de detalle también muy altos como bien definidos, donde la facilidad de implementación de la misma es relativamente sencilla a nivel técnico debido a la extensa documentación disponible.
OWASP está compuesta de 2 fases:
- Pasiva: Realización de tests para la compresión de lógica de lo que se está analizando par determinar la operativa de la aplicación, sistema y/o arquitectura más los posibles vectores de ataques como debilidades y vulnerabilidades de la misma.
- Activa: Realización de un número de procesos determinados por OWASP clasificados en las siguientes categorías:
Dentro de la fase activa disponemos de los siguientes 11 procesos:
1. Recopilación de información
Consiste en la recopilación relativa al objetivo que nos pueda proporcionar cualquier detalle para analizar y barajar la inclusión o utilización de esta información para la pruebas restantes.
2. Pruebas de la configuración y despliegue de la administración
Se trata de una serie de tests relativos a malas configuraciones de la propia aplicación o inclusive server donde está alojada.
3. Pruebas de la gestión de identificaciónSon pruebas que determinan si existen fallos en el manejo y políticas de las identificaciones de los roles, cuentas, usuarios, etc.
4. Pruebas de autenticaciónAquí verificaremos la integridad de el role de cada usuario es quien dice ser durante el flujo de autenticación.
5. Pruebas de autorización
Cualquier autorización, es decir, determinar los recursos que podemos usar se tratará en esta categoría.
6. Pruebas de la gestión de sesiones
Se pretende testear que se controla correctamente las sesión durante todo el flujo.
7. Pruebas de validación de entradaLas pruebas realizadas en este apartado tratan de validar el correcto tratamiento de los datos en la entrada de los mismos, por ejemplo realizando uso de diversas técnicas como XSS, SQL injection, LFI/RFI, etc
8. Pruebas de manejo de erroresEn este apartado se provocan todo tipo de errores de aplicativo, sistema y/o arquitectura donde podamos determinar mediante un comportamiento adecuado el descubrimiento de alguna debilidad y/o vulnerabilidad en el objetivo.
9. Pruebas de cifrado
Aquí verificamos debilidades en todo lo relativo al cifrado, desde la implementación de algoritmos de cifrado hasta vulnerabilidades en los protocolos de capa de transmisión.
10. Pruebas de lógica de negocio
Se realizarán test relativos a un posible mal análisis de la lógica de negocio en la implementación de la aplicación, como podría ser por ejemplo insertar usuarios no validados, alteración de componentes en base a la no validación de campos, etc.
11. Pruebas del lado de cliente
La validación en esta parte irá más enfocada a tipos de ataque en la parte cliente, como podría ser DOM Based XSS, Clickjacking, Client Side URL Redirect, etc
Todos los procesos de cada categoría están definidos ampliamente en el site oficial de OWASP donde podremos ver con detalle de que se trata cada uno para poder realizar los pertinentes test de manera correcta.
Podemos encontrar información detallada sobre como aplicar OWASP en https://www.owasp.org/index.php/Main_Page.
> OSSTMM
Es una metodología abierta orientada a la comprobación de seguridad de:
- Seguridad física
- Seguridad en redes de datos y telecomunicaciones
- Seguridad inalámbrica
- Seguridad de Procesos
- Ingeniería social
- Cumplimiento
Esta metodología tiene gran similitud con la ISO 27001, aunque OSSTMM puede actuar de complemento sin ningún problema o inclusive de forma individual si lo que queremos obtener está más ligado a la obtención de detalles más técnicos y la verificación y prueba de los elementos analizados.
El focus del OSSTMM está más ligado a la rigurosidad de las pruebas, detección y eliminación de falsos positivos, cumplimiento de standards y regulaciones, cuantificación de los resultados obtenidos, capacidad de reproducción de los resultados y asegurar la calidad.
Dispone de varias fases:
- Identificación
- Revelación de datos sensibles
- Análisis de vulnerabilidades y debilidades criptológicas
- Análisis de vulnerabilidades y debilidades en accesos físicos, redes de datos, redes inlámbricas, sistemas, servicios y aplicaciones
- Validación de la confidencialidad en accesos físicos, redes de datos, redes inlámbricas, sistemas, servicios y aplicaciones
- Detalle técnico de los análisis
- Contramedidas
> Cyber Kill Chain
Es una metodología de origen militar basado en Kill Chain e inventada por la compañía multinacional de la industria militar y aeroespacial.
Se tiene tiene como base los pasos seguidos para la ejecución de una amenaza persistente avanzada, por lo que se puede tener una visibilidad más puramente del lado más ofensivo, mostrando a las empresas qué medidas debería establecer en cada una de las fases para garantizar una seguridad.
Dispone de varias fases:
1. Reconocimiento
Se trata de identificar los posibles objetivos e investigarlos.
2. Creación del arma
Desarrollo del arma detonante de la futura explotación, por ejemplo el desarrollo de un troyano con un exploit incrustado sería de lo más común.
3. Entrega
Aqui se define el canal de entrega del posible malware desarrollado, desde un correo electronico, url hasta un simple dispositivo USB.
4. Explotación
En esta fase se buscará la forma de expotar el código malicioso ya sea vía software o por medio de ingeniería social.
5. Instalación
En esta parte generamos persistencia en los sistemas para poder volver entrar a los mismos una vez finalizada nuestra sesión, evitando repetir los pasos anteriores por simple complejidad.
6. C&C
Tras asegurar la fase de instalación, durante la misma se dejará preparada normalmente con funcionalidades de Command & Control, que no es más que capacidad de control remoto de nuestro malware donde podamos establecer comunicación con el mismo de forma remota y ejecutar las ordenes que deseemos, funcionalidad muy común en las botnets.
7. Acciones
Finalmente esta es la fase donde se produce el daño real, desde el cifrado de ficheros, borrado, exfiltración de datos, etc.
Para la revisión 3.0 se incluirá un nueva fase que no es más que de “pivoting”, saltar a otras máquinas logrando expandir y asegurar la entrada.
# Determinar riesgo y evitar la estadística
Es aconsejable, independientemente de la metodología que usemos, determinar antes el riesgo para evitar invertir un tiempo y esfuerzo que no será visible de cara al objetivo real de la entrega.
Muchos equipos de auditoría tienden a realizar una media muestral en sus auditorías, algo que es bastante común y personalmente considero un error garrafal, mayormente porque las aplicaciones, sistemas y/o arquitecturas que auditemos, cualquier pequeño elemento, aunque a simple vista pueda ser común, probablemente no lo sea y este mismo puede ser el que contenta esa debilidad y/o vulnerabilidad que nos permita comprometer todo lo demás.
Una analogía adecuada sin entrar en demagogias podría ser cuando se audita un vehículo, aunque sepamos que todos los componentes son iguales, no por ello deben estar en el mismo estado y no se le da más valor a unos componentes u otros sin más puesto que si nos centramos en auditar muy bien el “motor” del supuesto vehículo pero no la presión de las ruedas, es posible que comentamos un error grave en la auditoría, siendo la misma mediocre o inválida.
Para ello nos apoyaremos en determinar el riesgo, ya que esto es lo correcto y siempre con validación del cliente.
Para determinar el riesgo podemos realizarlo mediante una sencilla regla:
Riesgo = Probabilidad * Impacto
# Recursos para pentesting
Aquí encontraremos una colección de recursos suficientes para poder practicar tests de penetración, desde recursos online, herramientas, libros, base de datos de vulnerabilidades, cursos de seguridad, conferencias, revistas, listas, etc.
