Español | English
rss facebook linkedin Twitter

CAPEC

Continuando con la misma línea de publicaciones y sin salirme de los estándares definidos por y para SCAP, hoy le toca el turno a CAPEC: Common Attack Pattern Enumeration and Classification. Los patrones de ataque (que completan la definición de una amenaza) conforman la descripción de los métodos utilizados para la explotación del software/hardware, con la desviación particular (desde el punto de vista de diseño) que los orienta a un objetivo relativamente “destructivo” y que son un elemento clave para identificar y comprender las diferentes perspectivas en las que una amenaza se puede convertir en una vulnerabilidad.

¿Qué es un patrón de ataque?

Para comprender mejor la diferencia entre un “patrón de ataque” y una vulnerabilidad, analicemos el siguiente ejemplo: “Explotar la confianza del software en el cliente”, es decir, confiar parte de la seguridad (o sin ser estrictamente seguridad, cualquier control de validación) de la aplicación en el hecho de que el cliente que se conecta es realmente el cliente, en lugar de suponer que puede ser cualquier otro software (automático o manual). En otras palabras, que a lo mejor el navegador no es el navegador sino alguien con un proxy, o un script o… Mediante este patrón es posible manipular la información transmitida al servidor, realizar una suplantación de identidad, y explotar otra serie de vulnerabilidades.

¿Qué nos aporta el patrón de ataque?

Básicamente nos ayuda a determinar que vulnerabilidades pueden afectar a nuestro elemento. En este caso concreto, no debemos preocuparnos si nuestra aplicación no se compone de una estructura cliente servidor.


CAPEC tiene como objetivo ofrecer una lista de patrones de ataque, así como toda la información relacionada que permite comprender así como ordenar una taxonomía de este tipo. La versión disponible actualmente es la 1.1, que pude ser visualizada online en forma de árbol aquí o descargada desde aquí aunque la sección de descargas sea esta: http://capec.mitre.org/about/documents.html

La siguiente imagen muestra un pequeño detalle de la lista expandida de CAPEC 1.1 donde pueden apreciarse diferentes patrones de ataque.





Como post para el blog ya tengo el 5, ahora a intentar subir nota..

Estructura de CAPEC

En primer lugar, no como estructura de datos sino como visualización de la publicación, CAPEC ofrece diferentes tipos de vistas para su taxonomía (ver “Pattern abstraction Slides”). De hecho, en un principio CAPEC era mucho más grande de lo que es ahora, pero han conseguido separar los patrones de las amenazas, vulnerabilidades y debilidades (cosa complicada) por lo que el diccionario se ha reducido considerablemente.

Aunque a primera vista puede parecer que un patrón de ataque es un campo más en la lista de atributos de una vulnerabilidad y que no aporta nada más que una descripción, en realidad desde un punto de vista menos técnico ofrece información que permite determinar factores de riesgo, evaluaciones de impacto, detección proactiva de ataques, apoyo en las decisiones de seguridad, etc…

Vamos a centrarnos en un ejemplo para comprender la importancia y validez de la información que ofrece esta taxonomía (Nota: la traducción utilizada en esta explicación no es literal): Accessing Functionality Not Properly Constrained by ACLs

Título: “Acceso no restringido correctamente por Listas de Control de Acceso”
ID patrón de ataque: 1
Severidad Típica: Alta

Comentario: Hasta aquí, información para la impresora y el respositorio, nada útil ni práctico.

Descripción:
En aplicaciones principalmente Web, el acceso a funcionalidades es permitido por el framework de autorización, cuyo trabajo es relacionar ACLs con elementos de la funcionalidad de la aplicación, principalmente URLS de la aplicación web. En caso de que alguna de estas ACLS no sea especificada para un elemento cualquiera, un atacante podría acceder a éste sin impedimento. Un atacante que pueda acceder a funcionalidad no controlada por la ACL podría obtener información sensible, y posiblemente comprometer la aplicación en caso de que pudiese acceder a recursos que solo debieran estar disponibles para usuarios privilegiados, como secciones de gestión, etc...

Comentario: Leyendo este sumario ahora es posible determinar que las amenazas a las que se refiere este patrón de ataque pueden generarse y deberían mitigarse durante la fase de desarrollo.

A continuación se analizan los pasos utilizados habitualmente para completar este patrón de ataque.

Flujo de ejecución del ataque: describe el flujo de ejecución del atacante según este patrón.

Mediante Exploración

Estudio: El atacante trata de identificar elementos de la aplicación mediante su estudio, posiblemente como usuario válido autenticado.
Técnicas utilizadas
  1. Spidering del sitios web y enlaces disponibles (entornos web principalmente)
  2. Averiguar recursos (directorios, archivos, accesos) mediante fuerza bruta
  3. Averiguar nombres de usuario/credenciales mediante fuerza bruta
  4. Averiguar acciones o nombres de función mediante fuerza bruta.

comentario: Bien, si observamos cualquiera de estas irregularidades en el uso de la aplicación es posible que no estén intentando atacar, y ahora podemos determinar que quizá estén intentando acceder a recursos privilegiados de la aplicación.

Indicadores de susceptibilidad
  1. Se han observado ACL o mecanismos de control en la aplicación
  2. Existen identificadores de usuario o credenciales en la aplicación
  3. Se han observado diferentes modos de operación según privilegios
Comentario: egún esta lista de susceptibilidad, si en nuestra aplicación mostramos estos “indicadores” es probable que antes o después recibamos un patrón de ataque de este tipo, ya que son claras pistas de que existe un mecanismo de control de acceso.

Identificación de funcionalidad: en cada paso el atacante es sujeto a un control de funcionalidad utilizado en algunas de las acciones

  1. Uso del inventariado Web de todos los formularios y aplicación de ataques a todas sus entradas.
  2. Registro y análisis de tráfico de red de la comunicación
  3. Ejecución de aplicación en entorno controlado que permite visualizar la información utilizada en las API de sistema.
Comentario: AKA: Prueba y error, consiste en ir probando diferentes aspectos de la aplicación para ver si aparece algún error. Al menos desde el punto de vista del desarrollador es posible aplicar algún tipo de control que evite la repetición de acciones, o que la limite en el tiempo.

Experimentación

Evaluación de las capacidades de acceso: Probablemente como usuario válido, el atacante intentará realizar todas las acciones posibles en la aplicación para comprobar la extensión de la gestión de acceso.

  1. Fuzzy de parámetros de API o solicitudes (parámetros URL, parámetros API de sistema, parámetros de protocolo, etc…)

Indicadores de susceptibilidad

  1. Intento de crear un listado de mecanismos de acceso y resultados de su control, para determinar aquellos en los que no se realiza de forma correcta.

Comentario: Si encontramos un usuario que intenta determinar todos los controles de acceso aplicados, obviamente no puede ser nada bueno.


Prerequisitos del ataque

La aplicación debe ser accesible en un modo en que se asocien sus elementos (secciones, acciones, etc..) con ACLs. Algunos recursos, como URLs de acceso deben estar accesibles para usuarios para que se cumpla su descubrimiento. Deben existir recursos no asociados a ACLs, o bien durante el desarrollo o durante el despliegue de la aplicación.

Comentario: Sin estos requisitos, ya sabemos que aunque observemos este patrón de ataque, su finalización no será exitosa... ehem...


Propensión a ser explotable: Muy alta
Métodos de ataque: análisis y fuerza bruta.

Comentario: Con estos criterios, ya podemos determinar que si desde un origen se detecta mucho tráfico es posible que estén analizando la aplicación o realizando un ataque de fuerza bruta.


Hasta aquí podríamos resumir como análisis básico. Existen bastantes criterios que pueden ser considerados además de los expuestos, y de todos ellos es posible extraer un poquito más de información acerca del tipo de ataque podríamos recibir. Claro que también es posible realizar la consulta inversa, es decir, como responsable de seguridad mi misión es mantener un entorno de trabajo seguro. Puedo evaluar el hecho de que limitando en el tiempo el número de conexiones posibles desde un único origen reduce la posibilidad de éxito de patrones de ataque como éste (y otros), o por ejemplo, demostrar empíricamente a la dirección que un firewall no va a proteger la aplicación de este tipo de ataques. Cuando además el escenario se conoce al 100%, es posible determinar cuáles de las vulnerabilidades (relación CVE – CAPEC) a las que estoy expuesto según el último informe de la auditoría son explotables de forma remota o mediante que tipos de ataque, por lo que puedo excluir aquellas que sé no son accesibles desde el exterior.

Finalmente, otra de las aportaciones de CAPEC es el hecho de que como repositorio (catálogo) cada una de las vulnerabilidades puede ir asociada con uno o varios patrones, lo que permite la automatización de varias de las acciones/ideas/conclusiones que hemos obtenido en este mini-análisis. Teniendo en cuenta que hasta ahora no se está haciendo, disponer de tecnología que lo permite supone cuanto menos un avance.

Como factores en contra, es información que puede aclarar o terminar de liar al 'inexperto', aunque, sin apelar a la demagogia, seguramente hablar de inexpertos en seguridad en el año 2009 sea un disparate :)


Otros recursos


En el año 2007 se hicieron los primeros (y curiosamente únicos) esfuerzos por dar a conocer esta inciativa: un workshop y una conferencia en la BlackHat, que podeis descargar desde aquí (Outreach and Enhancement). En este caso es un copy-paste de los utilizados en la propia web de CAPEC, que incluyo no como referencia para otras lecturas, sino para terminar de completar los orígenes de este engendro.

Además de las taxonomías utilizadas como base para este trabajo US-CERT, Rocky y AttackPattern, se ha tenido en cuenta el conocimiento “aprobado” por la comunidad en general tras el nivel de aceptación de libros como “Building Security” o “Exploiting Software: How to Break Code”, así como trabajos bastante adelantados a su época, como la iniciativa de realizar esta taxonomía por parte del Carnegie Mellon University: “Attack Modeling for Information Security and Survivability”, del 2001. Así que como conclusión, quizá se utilice en un futuro, quizá no, pero no hay duda de que al menos su contenido merece un vistazo.


Iñaki López
S21sec Labs


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login