Pentesting: Introducción

JS
JS
Nov 6, 2017 · 10 min read

# ¿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).

Sneakers

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

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

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.

Image for post
Image for post

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

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ón

Son 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ón

Aquí 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 entrada

Las 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 errores

En 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

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

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

Black Hat USA 2014

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

Image for post
Image for post

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.

Image for post
Image for post

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

Image for post
Image for post

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.

https://github.com/enaqx/awesome-pentest

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store