Penetration Testing - ISACA...

PwC

Penetration TestingConceptos generales y situación actualA/S Rodrigo Guirado, CISA, CGEITSenior Manager – Advisory [email protected]

Agenda / Contenido

MotivaciónDefiniciones GeneralesUsos RecomendadosDefinición de EscenariosEtapas Usuales Cambios en los Últimos AñosVulnerabilidades en Aplicativos Web

Penetration Testing – Conceptos generales y situación actual


PricewaterhouseCoopersAbril 2009

Diapositiva 4Penetration Testing – Conceptos generales y situación actual

La práctica actual de Penetration Testing

• Cada vez más considerada como “un recurso más” dentro de las tareas usuales de seguridad de una organización

• Se está viendo como un requerimiento formal en muchos casos (e.g. normas PCI)

• Ha adquirido un mayor grado de formalización en los últimos años (incluyendo publicación de códigos de ética asociados)

• No obstante lo anterior, existen servicios de Penetration Testing de alcance muy diferente por lo cual es importante conocer sus diferencias y usos adecuados

• Si bien en general las actualizaciones automáticas del software de base han mejorado (hasta cierto punto) la situación general en cuanto a vulnerabilidades de infraestructura, por otra parte las aplicaciones web (en muchos casos críticas) siguen presentando problemas graves

Motivación



Terminología

• Penetration Testing

- “Método para evaluar la seguridad de un sistema o red informática simulando un ataque de origen hostil” (Wikipedia)

- “Una prueba de seguridad con un objetivo específico que termina cuando dicho objetivo se obtiene o se acaba el tiempo disponible”(OSSTMM – “Open Source Security Testing Methodology Manual”)

- “Prueba de seguridad donde los evaluadores copian ataques reales para subvertir las funciones de seguridad de un aplicativo, sistema o red” (NIST – “National Institute of Standards and Technology”)

• Lo más relevante a destacar es que un Penetration Testing es un conjunto de pruebas con el objetivo de detectar vulnerabilidades en un sistema – en otras palabras, nunca puede considerarse como una certificación de que un sistema es “seguro” o “inviolable”

Definiciones Generales



Terminología

• Variantes de Penetration Testing

- “Black Box” / “Blind”: el consultor no cuenta con ninguna información del sistema/red que debe analizar

- “White Box” / “Full Disclosure”: el consultor tiene acceso a toda la información (incluyendo datos internos, código fuente, etc.) del sistema/red que debe analizar

- “Gray Box” / “Partial Disclosure”: cualquier caso intermedio a los anteriores (e.g. el consultor cuenta con un mapa de la red y lossegmentos de direcciones relevantes, pero no con el código fuente de los aplicativos disponible)

• En este caso es importante considerar que cada variante simuladiferentes situaciones de la realidad y por lo tanto la elección de la variante correcta puede afectar significativamente el valor de la prueba

Definiciones Generales



¿Cuándo utilizar un Penetration Testing?

• Los dos conceptos principales a analizar son la adecuación de las técnicas para el objetivo de prueba específico y luego la relación costo-beneficio

• Algunas consideraciones sobre los Penetration Testing:

- No son un reemplazo para una correcta revisión / auditoría de la configuración de cierta infraestructura

- No analizan las prácticas operativas asociadas a determinado ambiente (que pueden acarrear sus propios problemas de seguridad)

- Son acotados en el tiempo y reflejan la situación en un momento específico (“foto” de la realidad)

- Las técnicas que puede aplicar el consultor posiblemente no puedan llegar hasta los límites de lo que haría un atacante

Usos Recomendados



¿Cuándo utilizar un Penetration Testing?

• Los mejores usos para un Penetration Testing podrían incluir:

- Confirmar / verificar los resultados de una revisión / auditoría de configuración

- Cumplir con requerimientos internos / externos

- Como alternativa más económica y rápida a una auditoría de código en aplicativos críticos

• En cualquiera de los casos, es importante exigir en cualquier servicio de este tipo garantías al proveedor en cuanto a la privacidad de cualquier hallazgo y la ética del personal que trabajará en el proyecto

• Para lograr adecuadamente los objetivos anteriores es importantedefinir adecuadamente la variante metodológica a utilizar según se mencionaba previamente (black/gray/white box)

Usos Recomendados



Ventajas y desventajas de cada modalidad

• Black Box

- Ventajas

• El consultor no recibe ninguna información ni acceso autorizado a los sistemas o aplicativos

• Es típicamente el más rápido y barato de los servicios (en algunos casos, el servicio es enteramente automático)

- Desventajas

• Tiene la menor probabilidad de detectar vulnerabilidades

• Es común que el foco sea exclusivamente la infraestructura y se ignoren los aplicativos

• Simula solamente el “mejor caso” para la organización por lo cual puede generar un falso nivel de confianza

Usos Recomendados




• White Box

- Ventajas• Tiene la mayor probabilidad de detectar vulnerabilidades

• Suele incluir un foco importante en los aplicativos (donde usualmente se presentan más problemas)

• Simula el “peor caso” para la organización lo cual ofrece un nivel importante de confianza

- Desventajas

• Tiene una duración mayor (más horas de consultor en comparación a herramientas automáticas) y mayor costo

• Requiere de un nivel importante de confianza en el consultor queva a recibir todos los detalles de la instalación

Usos Recomendados




• Gray Box

- Según las características particulares del proyecto, se combinan las ventajas y desventajas de los dos casos anteriores

- Si los escenarios de prueba son definidos adecuadamente, es en general la modalidad que ofrece la mejor relación costo-beneficio, dado que para cada vulnerabilidad detectada se puede estimar quéatacantes tendrían mayor probabilidad de explotarla y de este modo definir un plan preventivo razonable

- Debería ser la primer modalidad a considerar al solicitar un servicio de Penetration Testing (excepto que existan argumentos de gran peso para elegir una de las otras)

Usos Recomendados



Aspectos básicos a considerar

Definición de Escenarios

Determinar

blancos

Seleccionar

agentes

Determinar

Oportunidades

Determinar medio

de ataque

Determinar

motivación

Escenario

Macro

Determinar

Pruebas

Determinar blancos

y amenazas

Analizar agentes

y métodos

Definir pruebas

Pruebas de plata-

formas específicas

Pruebas de

Acceso Interno

Pruebas de

Acceso Externo

Pruebas sobre

Aplicaciones




• Agentes

- En general es difícil prever quien puede ser el agente que ejecute un determinado ataque aunque dependiendo de las operaciones de la organización se pueden hacer suposiciones

- Es preferible siempre asumir que el atacante cuenta con conocimientos significativos (particularmente si en el análisis previo no se logró acotar demasiado la lista de posibles agentes)

- Es importante recordar que los agentes internos a una organización son en general los responsables del mayor porcentaje de ataques efectivos





• Objetivo

- Algunos posibles objetivos (que suelen requerir diferentes niveles de acceso / compromiso de la instalación) incluyen:

• “Defacing” (dañar la imagen del sitio como protesta o demostración de habilidades)

• Denegación de servicios (como protesta o para crear una disrupción en las operaciones de un competidor)

• Obtención de información sensitiva (datos privados, listas de clientes, números de tarjeta de crédito, etc.)

• Introducción de transacciones no autorizadas

• Utilización del sitio para futuros ataques (“zombies”)

- Es importante considerar el concepto de materialidad cuando se realiza el análisis de los objetivos





• Recursos

- Es preferible asumir que el atacante cuenta con información detallada sobre los protocolos y mecanismos de seguridad utilizados (el concepto de “security through obscurity” es en general sumamente débil, particularmente contra ataques internos)

- También debe considerarse que el atacante pueda lograr cierto nivel de acceso básico al ambiente a atacar, particularmente en sitios públicos o de clientela masiva (e.g. home banking) o través de técnicas de ingeniería social

- Si se asume que el atacante cuenta con recursos significativos (e.g. acceso a una “botnet” de tamaño importante) entonces pueden existir determinados ataques (e.g. denegación de servicios, ataques de fuerza bruta contra claves criptográficas de largo insuficiente) que serán automáticamente exitosos




Etapas de un ataque

• En general cualquier ataque sobre la infraestructura consistirá de las siguientes etapas (con algunas opcionales dependiendo del escenario específico)

- Detección de equipos- Detección del “mapa” de la red

- Detección de servicios y versiones

- Detección de debilidades

- Obtención de algún nivel de acceso inicial

- Escalamiento de privilegios

• A lo anterior se agregan todos los ataques específicos sobre las aplicaciones que residan en dicha infraestructura que no tienen que seguir un orden particular y que se discutirán más adelante

Etapas Usuales



Detección de equipos y estructura de red

• El agente buscará en esta etapa detectar la mayor parte de componentes posibles de la red a atacar

• No solamente los servidores, sino además el resto del equipamiento de comunicaciones (routers, switches, etc.) y seguridad (firewalls, IDS, etc.) podrán ser blancos importantes

• La detección de la estructura de la red no siempre es estrictamente necesaria, pero le puede dar al agente un nivel adicional de información para la realización de ataques

• Por ejemplo, conocer si hay segmentos de red con diferente nivel de protección o cuales son los equipos de comunicación en determinadas rutas

Etapas Usuales



Detección de equipos y estructura de red

• Técnicas de detección de equipos y rutas

- Servidores de nombre (DNS)- “Ping” (típicamente sobre segmentos secuenciales de IPs)

• ICMP

• TCP

• UDP

• Paquetes preparados específicamente (que pueden en algunos casos permitir conocer la configuración de firewalls intermedios)

- “Traceroute” (y sus variantes)

- Simple Network Management Protocol (SNMP)

• Dependiendo de la configuración de las herramientas utilizadas por el atacante, es muy posible que esta etapa pase inadvertida

Etapas Usuales



Detección de servicios y versiones

• En esta etapa suelen aparecer indicios de que la red está bajo ataque

• El agente buscará determinar cuáles son los servicios corriendo (http, telnet, smtp, bases de datos, dns, etc.), los sistemas operativos que los soportan, y las versiones de dichas componentes

• “Port Scanning” (recorrida de puertos en forma secuencial/aleatoria)

- La técnica mas básica es intentar realizar una conexión estándar de TCP con el puerto específico

- Por velocidad y para evitar logs en ciertas configuraciones se utiliza el llamado “Stealth Scan” (o “Half-Open”) enviando paquetes SYN construidos especialmente

- Hay otras técnicas similares (FIN, XMAS-Tree, Null, ACK) que intentan pasar los controles del firewall y analizar la respuesta de los equipos a “errores” de conexión

Etapas Usuales



Detección de debilidades

• En esta etapa el agente buscará determinar vulnerabilidades en los servicios instalados

• Típicamente se utilizarán herramientas automatizadas que cuentan con bases de datos actualizadas periódicamente para hacer el análisis, aunque en algunos casos el atacante podrá interactuar directamente con los servicios

• Algunas de las vulnerabilidades (“exploits”) más usuales incluyen:

- “Buffer overflows” / “Dangling Pointers” / “Off-by-one”

- “Directory Traversal” / “Source Disclosure”

- “MIME exploits”

Etapas Usuales



Obtención / escalamiento de acceso

• Si en la etapa anterior el agente encuentra algún servicio que incluye vulnerabilidades, puede intentar utilizar dicho servicio para obtener algún nivel de acceso al servidor donde el mismo ejecuta

• Dependiendo de sus objetivos, este nivel de acceso puede o no ser suficiente, lo cual depende en general de los privilegios con los que corra el servicio

• En el caso de que necesite un mayor nivel, el atacante normalmente intentará escalar sus privilegios a través de nuevos ataques (e.g. ataques locales)

• Es importante notar que en el caso de detectarse que un atacanteobtuvo cierto nivel de acceso a un equipo (especialmente con perfiles de alto nivel de privilegio), puede resultar muy difícil determinar quéinformación fue accedida o qué otros componentes del servidor pueden estar comprometidos

Etapas Usuales



Escenarios de ataque en la actualidad

• Hace algunos años la existencia de servidores en producción con vulnerabilidades significativas no era una ocurrencia del todo extraña, principalmente por las siguientes razones:

- Falta de conocimiento/especialización en seguridad de los administradores

- Falta de procedimientos adecuados de seguimiento de vulnerabilidades y actualización de versiones

- Demoras significativas de los proveedores entre la aparición de una vulnerabilidad y la liberación del “patch” correspondiente

- Falta de criterios claros dentro de la comunidad de seguridad sobre el relacionamiento con los proveedores de tecnología y la publicación de las debilidades detectadas

Cambios en los Últimos Años



Escenarios de ataque en la actualidad

• En la actualidad varias de esas situaciones han sido corregidas (e.g. mayor velocidad de los proveedores, actualizaciones automáticas, “códigos” aceptados para la publicación de vulnerabilidades) y por consiguiente la seguridad a nivel de infraestructura ha mejoradosignificativamente (al menos en redes externas)

• Al mismo tiempo, han adquirido gran popularidad los desarrollos “de tipo web” para toda clase de aplicativos (ya sean de uso interno como externo) con implicaciones absolutamente críticas en cuanto a seguridad

• Finalmente, cada vez más se aprecia un objetivo delictivo en la utilización de vulnerabilidades informáticas (los “script kiddies” de principios de década han ido dejando su lugar a organizaciones criminales asociadas a fraudes, robo de secretos y extorsión)




Servicios actuales de Penetration Testing

• En virtud de lo anterior, es importante que un servicio actual de Penetration Testing esté correctamente planificado y se enfoque en aquellos aspectos que le puedan producir los mayores riesgos a la organización

• Los servicios de tipo “Black Box” o solamente basados en infraestructura, si bien pueden tener algún lugar dentro de una estrategia general de pruebas de seguridad, difícilmente puedan considerarse como suficientes excepto en los escenarios más simples (e.g. sitio institucional sin aplicativos o contenido dinámico)

• La orientación a escenarios presentada previamente ofrece un mecanismo simple para determinar los requerimientos mínimos que debería tener un servicio de Penetration Testing en la actualidad y quéaspectos deben ser complementados con otros mecanismos (revisión de configuraciones y procedimientos, auditoría de aplicativos, etc.)




Principales vulnerabilidades existentes

• Tanto a efectos de indicar aquellos aspectos que deberían considerarse dentro de un Penetration Testing que incluya a los aplicativos como para que sirva de “recordatorio” (ya sea para desarrolladores, auditores u oficiales de seguridad) a continuación se mencionarán las principales debilidades que usualmente se observan en aplicaciones web

• Si bien la lista de “principales debilidades” claramente puede ser objeto de debate y es responsabilidad de cada organización realizar su propio análisis y toma de decisiones, para facilitar la discusión se utilizará la lista denominada “Top Ten 2007” de la OWASP (“Open Web Application Security Project” – www.owasp.org)

Vulnerabilidades en Aplicativos Web



OWASP – “Top Ten 2007”

• Cross Site Scripting (XSS)

• Injection Flaws• Malicious File Execution

• Insecure Direct Object Reference

• Cross Site Request Forgery (CSRF)

• Information Leakage and Improper Error Handling

• Broken Authentication and Session Management• Insecure Cryptographic Storage

• Insecure Communications

• Failure to Restrict URL Access




Algunas recomendaciones

• Además de las recomendaciones básicas asociadas a cualquier proyecto de desarrollo tendientes a mejorar la calidad del producto final, se pueden hacer algunos comentarios sobre el tema seguridad

• El diseño de la seguridad de un sistema (e.g. un módulo centralizado) debe ser considerado desde el inicio del proyecto

• Puede ser interesante hacer un análisis de riesgos durante el diseño (similar a la definición de escenarios de ataque) para entender como el diseño de la seguridad debe atender a los mismos en función de la clasificación de los datos que se manejen

• Los controles no pueden ser algo “a agregar” luego de obtener cierta funcionalidad básica ni deberían estar “distribuidos” dentro de la aplicación (e.g. como parte del código de transacciones específicas)

• Evitar la falsa competencia “seguridad vs. usabilidad”




Algunas recomendaciones

• Recordar que cualquier elemento que se ejecute en el cliente (e.g. un control en javascript) no debe nunca considerarse como una parte relevante del esquema de seguridad

• Dentro de las especificaciones de los planes de prueba para la aplicación se debe incluir el tema de la seguridad

• Debería establecerse como un objetivo a probar que el sistema sea tolerante (o idealmente inmune) a determinadas clases de ataques, mediante técnicas similares a las de un Penetration Testing

• Un tema adicional a considerar (particularmente durante el Análisis de Riesgos) es la seguridad de cualquier tipo de datos confidenciales o privados de terceros que los sistemas manejen, para evitar contingencias legales



Diapositiva 35XBRL - Conceptos Generales y Ejemplos de Utilización

Nuestra VisiónSer la Firma líder en servicios profesionales, reconocida por ser diferente en su enfoque innovador, comportamiento ético, calidad, multidisciplinariedad, integración en torno al cliente y su aporte al desarrollo de la comunidad, que se caracteriza por relacionamientos profesionales de largo plazo, con rentabilidad sostenida en el tiempo y por la satisfacción y compromiso de sus talentos.

© 2009 PricewaterhouseCoopers. Todos los derechos reservados. PricewaterhouseCoopers hace referencia a la red de firmas miembro de PricewaterhouseCoopers International Limited, siendo cada una de ellas una entidad legal separada e independiente.*connectedthinking es una marca registrada de PricewaterhouseCoopers LLP (US).

PwC

Penetration Testing - ISACA...

Documents

Transcript of Penetration Testing - ISACA...