04.-Test de intrusión (Pentest)

Un test de intrusión, o penetration testing (abreviado pentest), es una actuación legítima de un hacker que trata de vulnerar los servicios de una empresa para hacerse con su control. Los objetivos y el alcance del test de intrusión se establecen por contrato, que incluye, entre otros aspectos, una cláusula de confidencialidad.

El objetivo del test de intrusión es analizar el estado de seguridad de los servicios de una empresa mediante la búsqueda activa de vulnerabilidades. De este modo, la empresa que contrata el pentest trata de anticiparse y protegerse ante posibles ataques de cibercriminales. Al concluir el test de intrusión se presenta un informe de resultados donde se describen y analizan los problemas de seguridad descubiertos y se proponen soluciones a los mismos.

En Internet se pueden encontrar informes de test de intrusión de empresas y organizaciones que los hacen públicos como medida de transparencia de sus servicios o del software que desarrollan (Repositorios con informes públicos de test de intrusión https://pentestreports.com/ https://github.com/juliocesarfort/public-pentesting-reports/). También se pueden encontrar informes de empresas de auditoría que evalúan la seguridad de ciertos servicios y aplicaciones de forma independiente.

En los siguientes apartados se profundiza en los distintos elementos que caracterizan un test de intrusión.

Tipos de Auditorías en Pentesting¶

El test de intrusión puede realizarse teniendo en cuenta diversos factores. El primero de ellos es el conocimiento que tiene el pentester de los elementos internos de la empresa, como archivos de configuración, código fuente, esquemas de red, políticas de seguridad, etc. Según este conocimiento, se diferencian los siguientes tipos de auditorías:

Auditoría de caja negra: En este caso, el auditor toma el rol de un hacker que no tiene, a priori, ningún conocimiento de la organización.
Auditoría de caja blanca: El auditor tiene acceso total a la información interna de la empresa. Se revisan todos los sistemas, versiones de software y sistemas operativos, configuraciones, políticas, etc. Esta auditoría también puede incluir la revisión del código fuente del software si la empresa se dedica al desarrollo.
Auditoría de caja gris: El auditor dispone de un conocimiento parcial o limitado de la organización. Por ejemplo, la auditoría podría consistir en revisar la seguridad de una aplicación web en la que tendría ciertos permisos, pero sin acceso al código fuente.

Otro factor a considerar al diseñar la auditoría es la posición del pentester con respecto a los recursos de la empresa. En este contexto, se diferencian los siguientes tipos:

Auditoría perimetral: El auditor asume el papel de un hacker que trata de descubrir una vía de entrada a los sistemas internos de la organización, a través del análisis de seguridad del perímetro. Se analizan configuraciones DNS, rangos de direcciones IP y servicios en uso, redes inalámbricas y cualquier información relevante que pueda ayudar a obtener acceso.
Auditoría interna: El auditor toma el rol de un empleado o insider con escasos o nulos privilegios en la organización, o de un invitado que se conecta a la red corporativa. La auditoría se realiza in situ y comienza desde un segmento de red alejado de los servicios críticos.
Auditoría interna con privilegios: Similar a la auditoría interna, pero en este caso el auditor tiene acceso a configuraciones, código fuente, políticas de seguridad, etc.

Por último, según el alcance de los servicios o recursos que se desean auditar, se distinguen los siguientes tipos:

Auditoría web: Evalúa la seguridad de la web. Puede ser de forma externa sin permisos (perimetral), con permisos de un usuario con credenciales (interna) o auditando el código fuente (caja blanca).
Auditoría de aplicaciones móviles: Permite conocer el grado de seguridad de las aplicaciones móviles de la empresa. Se puede realizar a diferentes niveles, como en el caso de la web.
Auditoría wireless y VoIP: Evalúa el estado de seguridad de las comunicaciones inalámbricas y de voz.
Prueba de estrés DoS/DDoS: Se evalúa la fortaleza de la infraestructura ante situaciones de alta carga.

Los distintos tipos de auditorías presentados no están compartimentados; cada test de intrusión definirá un tipo u otro en función de los objetivos que se persigan. Por ejemplo, una organización puede querer evaluar la seguridad de su perímetro frente a amenazas externas desconocidas, por lo que una auditoría perimetral de caja negra sería más apropiada. Otra, en cambio, puede estar interesada en conocer el grado de compromiso ante exempleados o empleados descontentos, por lo que una auditoría interna o perimetral de caja gris sería la más adecuada.

Fases de un Test de Intrusión¶

La realización de un test de intrusión se desarrolla en diferentes fases o etapas, cada una de las cuales tiene un alcance y un objetivo distinto. Existen diferentes propuestas sobre cómo dividir estas etapas, pero de forma general se pueden establecer las siguientes cinco:

Fase de reconocimiento o footprinting
En esta fase se realiza un análisis preliminar del objetivo, recabando toda la información posible utilizando fuentes públicas. Es importante destacar que esta fase no es intrusiva y no implica ninguna ilegalidad, ya que la información recabada está al alcance de cualquiera. Todo lo relacionado con esta fase se estudia en la Unidad 2.
Fase de enumeración o fingerprinting
En esta fase se continúa con la recopilación de información del objetivo, pero de manera activa, lo que significa que se interactúa directamente con el mismo, por lo que es imprescindible disponer de permiso para ello. Dentro de esta fase se realizan acciones como el escaneo de puertos abiertos, el análisis de servicios y el descubrimiento de vulnerabilidades, que se estudian en la Unidad 3.
Fase de explotación
Con la información obtenida en las fases 1 y 2 se dispone de un conocimiento amplio del objetivo. El propósito de esta fase es diseñar un vector de ataque para lograr acceso a los sistemas, aprovechando algún error de configuración, contraseñas débiles, servicios vulnerables, aplicaciones inseguras, etc. Las técnicas relacionadas con los objetivos de esta fase se explican en las Unidades 4, 5 y 7.
Fase de posexplotación
Esta fase comienza tras haber obtenido acceso a los sistemas del objetivo. Una vez dentro, se desarrollan acciones de distintos tipos. Una de ellas es comprobar los privilegios disponibles e intentar elevar o escalar estos hacia un usuario más privilegiado. Otra acción consiste en analizar el entorno de red donde se encuentra el sistema comprometido, estudiando posibles saltos a otros sistemas de mayor interés. Todo esto se estudia en la Unidad 6.
Fase de documentación
En esta última fase del test de intrusión, se debe elaborar un informe que recoja todos los detalles del proceso. A menudo, se suelen realizar dos tipos de informes: un informe ejecutivo para la alta dirección y un informe técnico dirigido al personal de IT.

Los cibercriminales siguen un esquema similar, salvo en la última fase, en la cual ellos tratan de borrar las huellas que hayan podido dejar y garantizar accesos futuros instalando rootkits y herramientas de comando y control (Command & Control - C2) que les permiten manejar y enviar órdenes a los equipos comprometidos de forma remota o exfiltrar información para luego extorsionar a la empresa (Apartado 6.1.1).

El contrato del test de intrusión¶

Los detalles de cómo debe llevarse a cabo el test de intrusión, como los servicios que serán auditados o la duración del test, deben estar acordados previamente con el cliente mediante un contrato firmado por ambas partes. En la bibliografía anglosajona, se refieren a este acuerdo como rules of engagement (reglas de compromiso). Este documento debe dar respuesta a preguntas como:

¿En qué horario debe realizarse el pentest? ¿Existen servicios críticos donde la carga de trabajo no puede superar cierto umbral?
¿Se realizarán pruebas de denegación de servicio?
¿Está permitida la ingeniería social con empleados?
¿El personal de la organización o de IT estará al tanto del test?
¿Está permitido instalar backdoors o utilizar exploits peligrosos?

Resulta difícil encontrar ejemplos de contratos de test de intrusión reales entre corporaciones privadas. Sin embargo, sí se encuentran ejemplos en los pliegos de contrataciones de organismos públicos que deben publicarse en boletines oficiales. Un ejemplo de ello es la contratación de un test de intrusión por parte de Loterías y Apuestas del Estado (Procedimiento de selección de empresas de servicios para la evaluación de vulnerabilidades y test de intrusión).

Metodologías de Pentesting¶

Las fases del test de intrusión pueden variar según la metodología empleada. Una metodología es un documento de referencia que mejora la calidad de los procesos y sirve como guía en las auditorías. No se trata de un documento normativo, sino que cada organización puede adaptarlo según sus necesidades.

Para profundizar en los elementos de una auditoría de seguridad, es recomendable consultar la Web Security Testing Guide (WSTG), desarrollada por OWASP. Aunque está enfocada a aplicaciones web, sus primeras secciones aplican a cualquier auditoría. En particular, la Sección 3.8 revisa las principales metodologías de pentesting.

PTES (Penetration Testing Execution Standard)¶

La metodología PTES (web oficial) fue desarrollada a partir de 2009. Actualmente en la versión 1.0, pronto se espera una versión 2.0 que incluirá el concepto de "niveles" según la sofisticación del adversario. PTES divide el pentest en siete fases:

Interacciones previas (Pre-engagement interactions): Definición del alcance, objetivos, coste y contrato del pentest.
Recopilación de inteligencia (Intelligence gathering): Obtención de información relevante del objetivo en tres niveles: automatizado, combinado con análisis manual, y detallado análisis manual.
Modelado de amenazas (Threat modeling): Identificación de activos críticos, elaborando el modelo con colaboración de la empresa.
Análisis de vulnerabilidades (Vulnerability analysis): Identificación de fallos aprovechables en los sistemas.
Explotación (Exploitation): Acceso a sistemas, identificando puntos de entrada principales para obtener activos valiosos.
Posexplotación (Post-exploitation): Evaluación del sistema comprometido, estudio de relaciones de red y exfiltración de datos.
Informe (Reporting): Elaboración del resumen ejecutivo y del informe técnico detallado para el cliente.

PTES también ofrece una guía de herramientas útiles para cada fase.

OSSTMM (Open Source Security Testing Methodology Manual)¶

La metodología OSSTMM, publicada en 2001 por ISECOM, está en la versión 3.0 desde diciembre de 2010. Incluye la certificación de auditorías mediante el documento STAR (Security Test Audit Report) y utiliza la medida estándar RAV para evaluar la superficie de exposición, que se puede expresar como:

Un valor positivo o negativo, indicando gasto excesivo en controles o insuficiencia de protección.
Un valor logarítmico en base 10, donde 100 indica balance perfecto.

OSSTMM divide la evaluación de seguridad en cinco canales:

Seguridad humana: Incluye interacción social, regulaciones, políticas de seguridad.
Seguridad física: Evaluación de vulnerabilidad de elementos físicos.
Seguridad en comunicaciones inalámbricas: Auditoría de comunicaciones en proximidad.
Seguridad en telecomunicaciones: Análisis de comunicaciones cableadas (analógicas y digitales).
Seguridad en redes de datos: Evaluación de comunicación entre redes y sistemas operativos.

La metodología consta de cuatro fases:

Fase de inducción: Comprensión de requisitos y alcance.
Fase de interacción: Identificación de sistemas e interacciones.
Fase de encuesta: Descubrimiento de información desconocida.
Fase de intervención: Evaluación de penetración en servicios y validación de controles.

Metodologías del OWASP¶

OWASP dispone de tres guías para la evaluación de la seguridad, según el tipo de aplicación:

OWASP Web Security Testing Guide (WSTG): Centrada en aplicaciones web, con 12 apartados que incluyen recolección de información, autenticación, autorización, gestión de sesiones, validación de entradas, manejo de errores, criptografía débil y auditoría de APIs.
OWASP Mobile Application Security Testing Guide (MASTG): Anteriormente MSTG, describe el proceso de pruebas de seguridad en aplicaciones móviles, en alineación con OWASP MASVS.
OWASP Firmware Security Testing Methodology (FSTM): Evaluación de la seguridad del firmware de dispositivos embebidos, con 9 etapas como recolección de información, análisis y explotación binaria.

Otras Metodologías¶

Existen otras metodologías que pueden resultar útiles conocer y estudiar. Algunas de ellas son:

PCIDSS (Payment Card Industry Data Security Standard): Elaborada por el PCI SSC (Security Standards Council), incluye las líneas y requisitos para proteger los datos de sistemas de pago. También elabora otros estándares como el desarrollo de software seguro o sistemas de pago para dispositivos móviles (https://www.pcisecuritystandards.org/document_library/).
PTF (Penetration Testing Framework): Más que un estándar, recopila información de herramientas útiles en cada fase del test de intrusión y presenta posibles escenarios de ataques (http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html).
NIST SP 800-115 (Technical Guide to Information Security and Assessment): Esta guía elaborada por el NIST incluye recomendaciones prácticas para diseñar, implementar y mantener auditorías de seguridad (https://csrc.nist.gov/publications/detail/sp/800-115/final). Además, el NIST está en pleno proceso de publicación de la versión 2.0 del CSF (Cybersecurity Framework), que ha de servir a cualquier organización para garantizar la resiliencia frente a ciberamenazas.
CAF (The Cyber Assessment Framework): Esta guía está diseñada por el NCSC (National Cyber Security Centre) del Reino Unido (https://www.ncsc.gov.uk/collection/caf).

Otras metodologías¶

Existen otras metodologías que pueden resultar útiles conocer y estudiar. Algunas de ellas son:

PCIDSS (Payment Card Industry Data Security Standard). Elaborada por el PCI SSC (Security Standards Council), incluye las líneas y requisitos para proteger los datos de sistemas de pago. También elabora otros estándares como el desarrollo de software seguro o sistemas de pago para dispositivos móviles (https://www.pcisecuritystandards.org/document_library/).
PTF (Penetration Testing Framework). Más que un estándar, recopila información de herramientas útiles en cada fase del test de intrusión y presenta posibles escenarios de ataques (http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html).
NIST SP 800-115 (Technical Guide to Information Security and Assessment). Esta guía elaborada por el NIST incluye recomendaciones prácticas para diseñar, implementar y mantener auditorías de seguridad (https://csrc.nist.gov/publications/detail/sp/800-115/final). Además, el NIST está en pleno proceso de publicación de la versión 2.0 del CSF (Cybersecurity Framework), que ha de servir a cualquier organización para garantizar la resiliencia frente a ciberamenazas.
CAF (The Cyber Assessment Framework). Esta guía está diseñada por el NCSC (National Cyber Security Centre) del Reino Unido (https://www.ncsc.gov.uk/collection/caf).

Equipos de seguridad. Pentesting vs red teaming¶

Habitualmente se distinguen dos tipos de equipos de seguridad:

Red Team (equipo rojo). Realiza labores de seguridad ofensiva, por lo que en ellas se incluyen las acciones de un hacker ético.
Blue Team (equipo azul). Realiza labores de seguridad defensiva como respuesta a incidentes, análisis forense digital, investigación de amenazas (threat hunting), bastionado de sistemas, seguridad operativa (SecOps), etcétera.

A menudo, los términos pentesting y red teaming se confunden o se usan indistintamente, pero hay diferencias importantes entre ellos. Un pentest está orientado a una acción concreta sobre un objetivo y su duración en el tiempo suele ser reducida. En cambio, las labores del Red Team consisten en un ejercicio continuo y constante de prueba de las defensas del objetivo para tratar de superarlas evitando ser descubiertos. Estos ejercicios o simulacros emulan el comportamiento de grupos organizados de ciberdelincuentes, también llamados APT (Advanced Persistent Threat), y cuyo modus operandi se encuentra en la matriz de tácticas, técnicas y procedimientos (TTP) de MITRE Att&ck (Matriz de tácticas, técnicas y procedimientos MITRE Att&ck).

Por tanto, el objetivo del Blue Team será que el Red Team no tenga éxito. La forma tradicional de organizar estos equipos era que trabajasen de forma independiente. Más recientemente aparece el Purple Team, que realiza una puesta en común del trabajo de ambos equipos para analizar las debilidades, establecer mejoras y organizar los siguientes ejercicios.

Para descubrir qué tipos de ejercicios se llevan a cabo por un Red Team es recomendable visionar la charla Red Team como herramienta de protección frente APT (Red Team como herramienta de protección frente a APT (Layakk). XII Jornadas STIC) que la empresa Layakk realizó en las XII Jornadas STIC del CCN-CERT. Además, puede consultarse el Apartado 5.1.5 donde se explican algunas de las técnicas que emplean estos equipos.

Además, en la bibliografía reciente se encuentran referencias a otros equipos de seguridad (orange, green, yellow, white, gold, black...). La Figura 1.6, tomada de un artículo del investigador de seguridad Daniel Miessler, relaciona los conceptos más importantes en lo que él llama la Pirámide BAD (Build, Attack, Defend). Los equipos orange, green y yellow, inicialmente propuestos por April Wright en la charla Orange is the new purple en la conferencia BlackHat 2017, representan la labor de los constructores (builders), como por ejemplo los desarrolladores de software. Resulta recomendable consultar el artículo de Daniel Miessler si se desea profundizar en estos conceptos.

Figura 1.6. Pirámide BAD (Build, Attack, Defend) donde se representan los diferentes equipos de seguridad. (Fuente: https://danielmiessler.com/study/red-blue-purple-teams/).