Attack Patterns-Knowing Your Enemies in Order To Defeat Them-Paper PDF

Machine Translated by Google
Patrones de ataque como recurso de conocimiento para

Creación de software seguro
Sean Barnum Amit Sethi
Cigital, Inc. Cigital, Inc.
La creación de software con un nivel adecuado de garantía de seguridad para su misión se vuelve cada vez más desafiante a
medida que aumenta el tamaño, la complejidad y el ritmo de creación de software y el número y el nivel de habilidad de los atacantes
continúa creciendo. Cada uno de estos factores exacerba el problema de que, para crear software seguro, los desarrolladores deben
asegurarse de haber protegido todas las vulnerabilidades potenciales relevantes; sin embargo, para atacar el software, los atacantes
a menudo tienen que encontrar y explotar solo una vulnerabilidad expuesta. Para identificar y mitigar las vulnerabilidades relevantes
en el software, la comunidad de desarrollo necesita más que buenas prácticas analíticas y de ingeniería de software, una sólida
comprensión de las características de seguridad del software y un poderoso conjunto de herramientas. Todas estas cosas son
necesarias pero no suficientes. Para ser eficaz, la comunidad debe pensar fuera de la caja y tener una comprensión firme de la
perspectiva del atacante y los enfoques utilizados para explotar el software [Hoglund 04, Koizol 04].
Este artículo analiza el concepto de patrones de ataque como un mecanismo para capturar y comunicar la perspectiva del atacante.
Los patrones de ataque son descripciones de métodos comunes para explotar software. Se derivan del concepto de patrones de
diseño [Gamma 95] aplicados en un contexto destructivo en lugar de constructivo y se generan a partir de un análisis en profundidad
de ejemplos específicos de explotación del mundo real. A través del análisis de los exploits observados, se captura la siguiente
información típica para cada patrón de ataque:
• Nombre del patrón y clasificación • Habilidad o conocimiento del atacante requerido
• Prerrequisitos de ataque • Recursos necesarios
• Descripción • Soluciones y Mitigaciones
• Vulnerabilidades o debilidades relacionadas • Descripción del contexto
• Método de ataque • Referencias

• Ataque Motivación-Consecuencias
Esta información puede aportar un valor considerable para las consideraciones de seguridad del software en todas las fases del ciclo
de vida del desarrollo de software (SDLC) y otras actividades relacionadas con la seguridad, que incluyen:
• Levantamiento de requisitos • Pruebas de software y control de calidad.

• Arquitectura y Diseño • Operación de sistemas
• Implementación y codificación. • Generación de políticas y estándares
DERECHOS DE AUTOR 2007 CIGITAL, INC. 1

1.1 Introducción
Este documento presenta el concepto, la generación y el uso de patrones de ataque como una valiosa herramienta de conocimiento en el
diseño, desarrollo e implementación de software seguro.
Los patrones de diseño son una herramienta familiar utilizada por la comunidad de desarrollo de software para ayudar a resolver
problemas recurrentes encontrados durante el desarrollo de software [Gamma 95]. Estos patrones intentan abordar de frente los espinosos
problemas de la arquitectura y el diseño de software seguros, estables y efectivos. Desde la introducción de los patrones de diseño, se
han concebido muchos otros tipos de patrones relevantes para el software, incluida una construcción relativamente nueva conocida como
patrones de ataque [Hoglund 04].
Los patrones de ataque aplican el paradigma problema-solución de los patrones de diseño en un contexto destructivo más que
constructivo. Aquí, el problema común al que se dirige el patrón representa el objetivo del atacante de software, y la solución del patrón
representa métodos comunes para realizar el ataque. Las técnicas para explotar software tienden a ser pocas y bastante específicas
[Hoglund 04]. Los patrones de ataque describen las técnicas que los atacantes pueden usar para romper el software.
El incentivo detrás del uso de patrones de ataque es que los desarrolladores de software deben pensar como atacantes para anticiparse
a las amenazas y, por lo tanto, asegurar su software de manera efectiva. Debido a la ausencia de información sobre la seguridad del
software en muchos planes de estudio y el manto tradicional de secreto que rodea a los exploits, los desarrolladores de software suelen
estar mal informados en el campo de la seguridad del software y especialmente en la explotación del software. El concepto de patrones
de ataque se puede utilizar para enseñar a la comunidad de desarrollo de software cómo se explota el software en la realidad y para
implementar formas adecuadas de evitar los ataques.
A menudo, la política de seguridad también carece de una comprensión integral de los problemas relacionados con la seguridad del
software, ya que los desarrolladores tienen una propensión natural a pensar en términos de características y funciones. Las políticas
ampliamente aceptadas e implementadas que promocionan el cifrado como una panacea para los problemas de seguridad son un ejemplo.
Los representantes de la empresa suelen asegurar a los clientes que sus datos están protegidos porque la base de datos en la que se
almacenan está cifrada. Con la exageración que rodea a los cortafuegos y el cifrado, es difícil para la comunidad de desarrollo de
software aprender a crear software seguro. Este documento demostrará el uso de una herramienta clave para construir software seguro
de manera efectiva en ausencia de soluciones mágicas.
Terminología
Gran parte de la terminología utilizada en la seguridad del software no se ha estandarizado. Diferentes publicaciones usan terminología
diferente para describir los mismos conceptos y, a veces, incluso usan la misma terminología para describir conceptos diferentes. Además,
la literatura de marketing a menudo hace un mal uso de los términos relacionados con la seguridad para vender productos particulares, lo
que aumenta la confusión en torno a la seguridad del software. Esta sección intenta mitigar el problema para los propósitos de este
documento. Describirá brevemente la terminología esencial utilizada, que en su mayoría se toma prestada de Exploiting Software [Hoglund
04]. Se debe consultar el Glosario de patrones de ataque para obtener una lista más completa de la terminología utilizada en este documento.
software de destino El software de destino es el software que es el objetivo de un ataque.
host de destino Un host de destino es la computadora o plataforma que ejecuta el software de destino de un ataque.
Un host puede ser atacado a través de las interfaces proporcionadas por el software de destino o a través de

mecanismos de ataque puramente basados en la red.
explotar Un exploit es una técnica o código de software (a menudo en forma de secuencias de comandos) que aprovecha
una vulnerabilidad o debilidad de seguridad en una parte del software de destino.
ataque Un ataque es el acto de llevar a cabo un exploit.
agresor Un atacante es la persona o agente que realmente ejecuta un ataque. Los atacantes pueden variar desde
personas muy poco capacitadas que aprovechan los ataques automatizados desarrollados por otros ("script
kiddies") hasta agencias gubernamentales bien financiadas o incluso delincuentes organizados con amplia
experiencia en software.
patrón de ataque Un patrón de ataque es un marco general para llevar a cabo un tipo particular de ataque, como un método para
explotar un desbordamiento de búfer o un ataque de interposición que aprovecha ciertos tipos de debilidades
arquitectónicas. En este documento, un patrón de ataque describe el enfoque utilizado por los atacantes para
generar un exploit contra el software.
Contexto
Antes de comenzar una discusión sobre los patrones de ataque, primero debemos discutir por qué los patrones de ataque son
importantes. Los patrones de ataque proporcionan una manera para que los desarrolladores de software aprendan cómo se puede
atacar su software. Armados con el conocimiento sobre ataques posibles o probables, los desarrolladores pueden tomar medidas
para mitigar la probabilidad o el impacto de estos ataques.
Desafíos
Muchos desafíos inhiben el desarrollo de software seguro. Estos desafíos incluyen
• la dificultad real de construir software seguro,
• fuerzas del mercado que favorecen la funcionalidad y el tiempo de comercialización sobre la
seguridad, y • una importante brecha de conocimiento entre el "sombrero negro"1
La ventaja del atacante
El desafío principal en la creación de software seguro es que es mucho más fácil encontrar vulnerabilidades en el software que
hacer que el software sea seguro. Como analogía, considere la bóveda de un banco. Sus diseñadores deben asegurarse de que sea
seguro contra muchos tipos diferentes de ataques, no solo los aparentemente obvios. Por lo general, debe ser seguro contra ataques
mecánicos (p. ej., el uso de excavadoras), explosivos y grietas seguras, por nombrar algunos, y al mismo tiempo mantener la usabilidad
(es decir, permitir la entrada de personal autorizado, tener suficiente ventilación e iluminación). Esto claramente no es una tarea trivial.
Sin embargo, es posible que el atacante simplemente necesite encontrar una vulnerabilidad explotable para lograr su objetivo de
ingresar a la bóveda. El atacante puede intentar acceder a la bóveda a través de varios medios posibles, incluso a través de la entrada
principal rompiendo la combinación de seguridad, a través del techo, excavando bajo tierra, ingresando a través del sistema de
ventilación, sobornando
1
El término "sombrero negro" invoca las imágenes de las películas del viejo oeste del villano con sombrero de vaquero negro y se utiliza para describir a las personas que atacan
software maliciosamente. comunidad atacante y la comunidad de desarrollo de software defensora con una falta de conocimiento básico de los problemas y soluciones de
seguridad.

un empleado autorizado para abrir la bóveda, o creando un pequeño incendio en el banco mientras la bóveda está abierta para hacer que
todos los empleados huyan aterrorizados. Dadas estas realidades, es evidente que construir y mantener la seguridad de la bóveda de un
banco suele ser mucho más difícil que irrumpir en una.
La creación de software seguro tiene problemas similares, pero el problema se ve agravado por la virtualidad del software.
Con muchos sistemas, el atacante puede realmente poseer el software (obtener una copia local para atacar es a menudo trivial) o podría
atacarlo desde cualquier parte del mundo a través de las redes. Con la capacidad de atacar a distancia y sin acceso físico, los ataques se
vuelven mucho más fáciles. Es posible que los registros de auditoría no sean suficientes para atrapar a los atacantes después de que se
produzca un ataque, ya que los atacantes podrían aprovechar el anonimato de la red inalámbrica o las computadoras públicas de un
usuario desprevenido para lanzar ataques.
Dados los mayores riesgos que enfrenta el software en comparación con los objetos físicos, es esencial que el software se construya
teniendo en cuenta la seguridad. Para hacer esto, los desarrolladores deben tener una sólida comprensión de la perspectiva del atacante
para anticipar y frustrar los tipos de ataques esperados. Esto es especialmente cierto cuando los activos protegidos por el software son
tan valiosos como los activos físicos protegidos en las bóvedas de los bancos. Así como las bóvedas de los bancos se construyen
considerando todos los ataques conocidos de alto riesgo que pueden enfrentar, el software debe construirse considerando todos los tipos
de ataques conocidos aplicables.
Funcionalidad sobre seguridad
Otro desafío son las fuerzas del mercado que exigen que los desarrolladores de software maximicen la funcionalidad y minimicen el tiempo
de comercialización. La funcionalidad es lo que generalmente vende software, y la seguridad generalmente se trata como una idea de
último momento. Debido a que los usuarios no ven la mayoría de las capacidades de seguridad, por lo general no se consideran una
prioridad.
Los productos más exitosos tienden a ser aquellos que ofrecen la mayor funcionalidad y entran al mercado antes que los de sus competidores.
Desafortunadamente, esto es cierto para los productos de seguridad como el software de encriptación, el software antivirus, el software de
firewall, etc. Los productos que ofrecen la mejor funcionalidad a menudo se eligen sobre los que ofrecen la mejor seguridad. Debido a esto,
cada vez más sistemas están siendo explotados con importantes consecuencias de interés periodístico. A medida que pasa el tiempo, la
falta de visión de este enfoque se vuelve evidente para la industria, pero seguirá siendo un desafío durante muchos años.
La brecha del conocimiento
Un último desafío central en el área de la seguridad del software surge del hecho de que los atacantes han estado aprendiendo cómo
explotar el software durante varias décadas, pero la comunidad de desarrollo de software en general no se ha mantenido al día con el
conocimiento que han adquirido los atacantes. Esta brecha de conocimiento también es evidente en la diferencia de perspectiva entre los
atacantes con su visión deconstructiva cínica y los desarrolladores con su visión despreocupada de "no se supone que hagas eso". El
problema continúa creciendo en parte debido al temor tradicional de que enseñar cómo se explota el software podría reducir la seguridad del
software al ayudar a los atacantes existentes e incluso potencialmente crear otros nuevos. La comunidad de desarrollo de software esperaba,
en el pasado, que la oscuridad mantuviera el número de atacantes relativamente bajo. Se ha demostrado que esta suposición es pobre, y
algunos elementos de la comunidad ahora están comenzando a buscar métodos más efectivos para abordar este problema.

Por supuesto, muchos otros problemas plantean desafíos para la seguridad del software, pero los desafíos que se describen aquí
se encuentran entre los más importantes. Una comprensión básica de la perspectiva del atacante ayudará a abordar estos desafíos.
Solución
Una posible solución a estos desafíos es usar patrones de ataque para ayudar a otros a comprender la perspectiva del atacante. La
comunidad de black hat ya está bien versada en las técnicas utilizadas para atacar el software, pero la comunidad de desarrollo de
software generalmente no está educada en las formas en que se explota el software.
Los patrones de ataque brindan una forma coherente de enseñar a los diseñadores y desarrolladores cómo pueden atacar sus
sistemas y cómo pueden defenderlos de manera efectiva.
Un problema común es que los desarrolladores de software intentan endurecer pequeñas piezas de software mientras dejan huecos
en el panorama general. Por ejemplo, un desarrollador puede usar el cifrado AES de 256 bits para proteger los datos y luego
almacenar la clave en la propia aplicación. Por supuesto, un atacante elegirá la forma más fácil de romper el software. Si un atacante
necesita la clave, no intentará un ataque de fuerza bruta (no factible computacionalmente) o criptoanálisis (es poco probable que tenga
éxito). El atacante simplemente obtendrá la clave del código (muy fácil).
Asimismo, los constructores de sistemas físicos seguros, basados en siglos de experiencia, generalmente saben que los atacantes
siempre eligen la forma más fácil de lograr su objetivo. Como analogía, un ladrón que irrumpe en una casa no forzará la(s) cerradura(s)
de la puerta de entrada y tratará de adivinar el código del sistema de seguridad si, en cambio, puede cortar la línea telefónica de la
casa (deshabilitando así la seguridad). sistema) y rompa una ventana para acceder al interior. Por lo tanto, la tarea de hacer que una
casa sea más segura no debe implicar solo mejores cerraduras y códigos de desbloqueo del sistema de seguridad más largos; también
deben incluir cosas como ventanas más fuertes y copias de seguridad celulares para el sistema de seguridad (tenga en cuenta que las
señales celulares también pueden bloquearse, aunque actualmente no es tan fácil como cortar un cable), lo que puede ayudar a mitigar
posibles ataques conocidos. A menos que los desarrolladores de software comprendan problemas similares en la seguridad del
software, no pueden crear software seguro de manera efectiva.
Los patrones de ataque ayudan a categorizar los ataques de manera significativa, de modo que los problemas y las soluciones se
puedan discutir de manera efectiva. En lugar de adoptar un enfoque ad hoc para la seguridad del software, los patrones de ataque
pueden identificar los tipos de ataques conocidos a los que podría estar expuesta una aplicación para que las mitigaciones puedan
integrarse en la aplicación.
Otro beneficio de los patrones de ataque es que contienen suficientes detalles sobre cómo se llevan a cabo los ataques para permitir
que los desarrolladores ayuden a prevenirlos. Los patrones de ataque, sin embargo, normalmente no contienen detalles específicos
inapropiados sobre las vulnerabilidades reales para garantizar que no ayuden a educar a los miembros menos capacitados de la
comunidad black hat (por ejemplo, script kiddies). La información de los patrones de ataque generalmente no se puede usar
directamente para crear exploits automatizados.
Por supuesto, los patrones de ataque no son la única herramienta útil para crear software seguro. Muchas otras herramientas, como
casos de mal uso/abuso, requisitos de seguridad, modelos de amenazas, conocimiento de debilidades y vulnerabilidades comunes,
reglas de codificación y árboles de ataque, pueden ayudar. Los patrones de ataque juegan un papel único en medio de esta
arquitectura más grande de conocimientos y técnicas de seguridad de software y serán el tema central de este documento.

Antecedentes
Orígenes
El concepto de patrones de ataque se derivó de la noción de patrones de diseño introducida por Christopher Alexander
durante las décadas de 1960 y 1970 y popularizada por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides
en el libro Design Patterns: Elements of Reusable Object-Oriented Software. [Gama 95]. El libro analiza soluciones
examinadas para problemas específicos encontrados en el diseño de software orientado a objetos y cómo empaquetar
estas soluciones para un amplio aprovechamiento en forma de patrones de diseño. Un patrón de diseño captura el
contexto y los detalles de alto nivel de una solución general repetible para un problema común en el diseño de software.
No es un diseño de bajo nivel que pueda transformarse directamente en código; es una descripción de cómo resolver un
problema que puede usarse en muchas situaciones. Ejemplos de patrones de diseño incluyen el patrón singleton y el
patrón iterador. La discusión de estos y otros patrones de diseño específicos está fuera del alcance de este documento,
pero constituye una lectura recomendada para cualquiera que desee una base fundamental completa en el contexto
detrás de los patrones de ataque.
Desde la introducción de los patrones de diseño, la construcción de patrones se ha aplicado a muchas otras áreas
del desarrollo de software. Una de estas áreas es la seguridad del software y la representación de la perspectiva del
atacante en forma de patrones de ataque. El término "patrones de ataque" se acuñó en debates entre los líderes
intelectuales en seguridad del software a partir de 2001, se introdujo en el documento Modelado de ataques para la
seguridad y la supervivencia de la información [Moore 01] y se llevó a la industria en general con mayor detalle y con
un conjunto sólido. de ejemplos específicos de Greg Hoglund y Gary McGraw en 2004 en su libro Exploiting Software:
How to Break Code.
Desde la publicación de Exploiting Software, varias personas y grupos de la industria han intentado impulsar el
concepto con éxito variable. Estos esfuerzos enfrentaron desafíos como la falta de una definición y un esquema
comunes para los patrones de ataque, la falta de diversidad en las áreas específicas de análisis por parte de los
diversos grupos involucrados y la falta de un organismo independiente que actúe como recopilador y difusor de ataques
comunes. catálogos de patrones. Este documento, como parte del esfuerzo Build Security In patrocinado por EE.
Departamento de Seguridad Nacional, intenta proporcionar cierta coherencia de definición y estructura. Esfuerzos como
la iniciativa en curso de Enumeración y Clasificación de Patrones de Ataque Común (CAPEC) patrocinada por el DHS
recopilará y pondrá a disposición del público conjuntos básicos de instancias de patrones de ataque.
Concepto
Un patrón de ataque es un mecanismo de abstracción para describir cómo se ejecuta un tipo de ataque observado.
Siguiendo el paradigma del patrón, también proporciona una descripción del contexto donde es aplicable y luego, a
diferencia de los patrones típicos, brinda métodos recomendados para mitigar el ataque. En resumen, un patrón de
ataque es un modelo para un exploit. Proponemos que un patrón de ataque incluya típicamente la siguiente información:
• Nombre y clasificación del patrón: un identificador descriptivo único para el patrón.
• Prerrequisitos del ataque: ¿Qué condiciones deben existir o qué funcionalidad y qué características debe tener
el software de destino, o qué comportamiento debe exhibir, para que este ataque tenga éxito?
• Descripción: una descripción del ataque que incluye la cadena de acciones realizadas.

• Vulnerabilidades o debilidades relacionadas: ¿Qué vulnerabilidades o debilidades específicas (ver

glosario de definiciones) ¿aprovecha este ataque? Las vulnerabilidades específicas deben hacer referencia a identificadores
estándar de la industria, como el número de vulnerabilidades y exposiciones comunes ( CVE ), el número US-CERT , etc.
CWE).
• Método de ataque: ¿Cuál es el vector de ataque utilizado (p. ej., ingreso de datos malicioso,
archivo, corrupción del protocolo)?
• Motivación del ataque-Consecuencias: ¿Qué intenta lograr el atacante al usar este ataque? Este no es el objetivo comercial/
misión final del ataque dentro del contexto de destino, sino el resultado técnico específico deseado que podría aprovecharse
para lograr el objetivo comercial/misión final. Esta información es útil para alinear los patrones de ataque con los modelos de
amenazas y para determinar qué patrones de ataque del conjunto más amplio disponible son relevantes para un contexto
determinado.
• Habilidad o conocimiento requerido del atacante: ¿Qué nivel de habilidad o conocimiento específico debe tener el atacante para
ejecutar tal ataque? Esto debe comunicarse en una escala aproximada (p. ej., bajo, moderado, alto), así como en detalles
contextuales de qué tipo de habilidades o conocimientos se requieren.
• Recursos requeridos: ¿Qué recursos (por ejemplo, ciclos de CPU, direcciones IP, herramientas, tiempo) se requieren para
ejecutar el ataque?
• Soluciones y mitigaciones: ¿Qué acciones o enfoques se recomiendan para mitigar este ataque, ya sea a través de la
resistencia o la resiliencia?
• Descripción del contexto: ¿En qué contextos técnicos (p. ej., plataforma, sistema operativo, idioma, parámetros arquitectónicos)
digm) ¿es relevante este patrón? Esta información es útil para seleccionar un conjunto de patrones de ataque que sean
apropiados para un contexto determinado.
• Referencias: ¿Qué otras fuentes de información están disponibles para describir este ataque?
A continuación se proporcionan dos ejemplos de patrones de ataque [Hoglund 04]:
1. Nombre y clasificación del patrón: hacer que el cliente sea invisible
ÿ Prerrequisitos de ataque: la aplicación debe tener una arquitectura de varios niveles con una división
entre cliente y servidor.
ÿ Descripción: este patrón de ataque explota los problemas de confianza del lado del cliente que son evidentes en la
arquitectura del software. El atacante elimina al cliente del bucle de comunicación comunicándose directamente con el
servidor. Esto podría hacerse omitiendo al cliente o creando una suplantación maliciosa del cliente.
ÿ Vulnerabilidades o debilidades relacionadas: CWE-Man-in-the-Middle (MITM), CWE- Error de validación de origen, CWE-
Omisión de autenticación por falsificación, CWE- Sin autenticación para críticos
Función, CWE- Ataque de reflexión en un protocolo de autenticación
ÿ Método de Ataque: Protocolo de comunicación directa con el servidor.
ÿ Motivación del ataque-Consecuencias: Posible fuga de información, modificación de datos, ejecución de código
arbitrario, etc. Todo esto se puede lograr omitiendo la autenticación y el filtrado logrado con este patrón de ataque.

ÿ Habilidad o conocimiento del atacante requerido: encontrar y ejecutar inicialmente este ataque requiere un nivel de habilidad
moderado y conocimiento del protocolo de comunicaciones cliente-servidor. Una vez que se encuentra la vulnerabilidad, el
ataque se puede automatizar fácilmente para que lo ejecuten atacantes mucho menos hábiles.
El nivel de habilidad para aprovechar los ataques de seguimiento puede variar ampliamente según la naturaleza del ataque.
ÿ Recursos necesarios: ninguno, aunque las herramientas de análisis de protocolos y las herramientas de suplantación de clientes como
como netcat puede aumentar en gran medida la facilidad y eficacia del ataque.
ÿ Soluciones y Mitigaciones: ÿ Aumentar
la Resistencia a los Ataques: Utilice una fuerte autenticación bidireccional para todas las comunicaciones entre el cliente y el
servidor. Esta opción podría tener implicaciones significativas en el rendimiento.
ÿ Aumentar la resistencia al ataque: minimizar la cantidad de lógica y filtrado presente en el cliente; colóquelo en el servidor en su
lugar. Use listas blancas en el servidor para filtrar y validar la entrada del cliente.
ÿ Descripción del contexto: "Cualquier dato sin procesar que exista fuera del software del servidor no puede ni debe ser confiable. La
seguridad del lado del cliente es un oxímoron. En pocas palabras, todos los clientes serán pirateados. Por supuesto, el problema
real es uno de confianza del lado del cliente Aceptar cualquier cosa ciegamente del cliente y confiar en él de principio a fin es una
mala idea y, sin embargo, suele ser el caso en el diseño del lado del servidor".
[Hoglund 04].
ÿ Referencias: Explotación de software: cómo descifrar el código, p.150 [Hoglund 04].
2. Nombre y clasificación del patrón: Inyección de comandos de shell—Delimitadores de comandos
ÿ Requisitos previos del ataque: la aplicación debe pasar la entrada del usuario directamente a un comando de shell.
ÿ Descripción: Usando el punto y coma u otros caracteres no nominales, se pueden
ensartados juntos. Los programas de destino desprevenidos ejecutarán todos los comandos. Un ejemplo puede ser cuando se
autentica a un usuario usando un formulario web, donde el nombre de usuario se pasa directamente al
cáscara como en:
exec ("cat data_log_" + entrada de usuario + ".dat")

ÿ
ÿ El signo "+" denota concatenación. El desarrollador espera que el usuario solo proporcione un nombre de usuario.
Sin embargo, un usuario malintencionado podría proporcionar "nombre de usuario.dat; rm –rf / ;" como entrada
para ejecutar los comandos maliciosos en la máquina que ejecuta el software de destino. También se utilizan
técnicas similares para otros ataques como la inyección SQL. En el caso anterior, los comandos reales pasados
al shell serán:
cat data_log_username.dat; rm-rf/; .Cual
ÿ El primer comando puede o no tener éxito; el segundo comando eliminará todo en el sistema de archivos al que
tiene acceso la aplicación, y el éxito/fracaso del último comando es irrelevante
ganado.
ÿ Vulnerabilidades o debilidades relacionadas: inyección de comando CWE-OS, CVE-1999-0043, CVE 1999-0067, CVE-1999-0097,
CVE-1999-0152, CVE-1999-0210, CVE-1999-0260, 1999-0262 , CVE-1999-0279, CVE-1999-0365, etc.
ÿ Método de ataque: mediante la inyección de otros comandos de shell en otros datos que se pasan directamente
en un comando de shell.

ÿ Motivación del ataque-Consecuencias: Ejecución de código arbitrario. El atacante quiere usar el software de destino,
que tiene más privilegios que el atacante, para ejecutar algunos comandos que no tiene privilegios para ejecutar.
ÿ Habilidad o conocimiento del atacante requerido: Encontrar y explotar esta vulnerabilidad no requiere
requiere mucha habilidad. Un novato con algún conocimiento de los comandos y delimitadores de shell puede realizar
un ataque muy destructivo. Sin embargo, es posible que se requiera que un atacante habilidoso subvierta
contramedidas simples, como el filtrado de entrada rudimentario.
ÿ Recursos requeridos: No se requieren recursos especiales o extensos para este ataque.
ÿ Soluciones y mitigaciones: defina entradas válidas para todos los campos y asegúrese de que la entrada del usuario
sea siempre válida. También realice filtrado de lista blanca y/o lista negra como respaldo para filtrar delimitadores
de comando conocidos.
ÿ Descripción del Contexto: SO: UNIX.
ÿ Referencias: Software de Explotación [Hoglund 04].
Tenga en cuenta que un patrón de ataque no es demasiado genérico o teórico. El siguiente no es un patrón de ataque:
"escribir fuera de los límites de la matriz en una aplicación puede permitir que un atacante ejecute código arbitrario en la
computadora que ejecuta el software de destino". La declaración no identifica a qué tipo de funcionalidad y debilidad específica
se dirige o cómo se proporciona entrada maliciosa a la aplicación. Sin esa información, la declaración no es particularmente útil
y no puede considerarse un patrón de ataque.
Un patrón de ataque tampoco es un ataque demasiado específico que solo se aplica a una aplicación en particular. Por
ejemplo, "Cuando la variable de entorno PATH se establece en una cadena de longitud superior a 128, la aplicación foo ejecuta
el código en la ubicación de memoria a la que apuntan los caracteres 132, 133, 134 y 135 en la variable de entorno". Esta
cantidad de especificidad es peligrosa de revelar y proporciona un beneficio limitado a la comunidad de desarrollo de software.
Es peligroso porque permite que los sombreros negros ataquen más fácilmente un software en particular sin necesidad de
pensarlo mucho. Tiene un beneficio limitado para la comunidad de desarrollo de software porque no les ayuda a descubrir y
reparar vulnerabilidades en otras aplicaciones ni siquiera a reparar otras vulnerabilidades similares en la misma aplicación.
Aunque no es un requisito general o típico, puede ser valioso adornar los patrones de ataque cuando sea posible y apropiado
con otra información de referencia útil, como:
• Ejemplos-Instancias: Ejemplos explicativos o demostrativos de instancias de exploit de este tipo de ataque.

Su objetivo es ayudar al lector a comprender la naturaleza, el contexto y la variabilidad del ataque en términos más
prácticos y concretos.
• Exploits de origen: ¿ De qué exploits específicos (p. ej., malware, cracks) se derivó este patrón y cuál muestra un ejemplo?
• Patrones de ataque relacionados: ¿Qué otros patrones de ataque afectan o son afectados por este patrón?
• Patrones de diseño relevantes: ¿Qué patrones de diseño específicos se recomiendan para brindar resistencia o resiliencia
a este ataque, o qué patrones de diseño no se recomiendan ya que son particularmente susceptibles a este ataque?
• Patrones de seguridad relevantes: ¿Qué patrones de seguridad específicos se recomiendan para proporcionar resistencia?
o resiliencia a este ataque?

• Pautas o reglas relacionadas: ¿Qué pautas de seguridad existentes o reglas de codificación segura son relevantes?
para identificar o mitigar este ataque?
• Requisitos de seguridad relevantes: ¿Se han identificado requisitos de seguridad específicos relevantes para este ataque que
ofrezcan oportunidades de reutilización?
• Técnicas de sondeo: ¿Qué técnicas se utilizan normalmente para sondear y reconocer un objetivo potencial?
para determinar la vulnerabilidad y/o prepararse para un ataque?
• Indicadores-Advertencias de Ataque: Qué actividades, eventos, condiciones o comportamientos podrían servir en

indicadores de que un ataque de este tipo es inminente, está en curso o ha ocurrido?
• Técnicas de ofuscación: ¿Qué técnicas se utilizan normalmente para ocultar el hecho de que un ataque de
este tipo es inminente, está en progreso o ha ocurrido?
• Vector de inyección: ¿Cuál es el mecanismo y el formato de este ataque basado en entrada? Los vectores de inyección deben
tener en cuenta la gramática de un ataque, la sintaxis aceptada por el sistema, la posición de varios campos y los rangos
aceptables de datos [Hoglund 04].
• Carga útil: ¿Cuál es el código, la configuración u otros datos que se ejecutarán o activarán como parte de este ataque basado en
inyección?
• Zona de activación: ¿Cuál es el área dentro del software de destino que es capaz de ejecutar o activar la carga útil de este ataque
basado en inyección? La zona de activación es donde se pone en acción la intención del atacante. La zona de activación puede
ser un intérprete de comandos, algún código de máquina activo en un búfer, un navegador de cliente, una llamada a la API del
sistema, etc. [Hoglund 04].
• Impacto de la activación de la carga útil: ¿Cuál es el impacto típico de la activación de la carga útil del ataque para este ataque
basado en inyección en la confidencialidad, integridad o disponibilidad del software de destino?
Conceptos relacionados
Existen muchos otros conceptos y herramientas relacionados con los patrones de ataque, incluidos árboles de fallas, árboles de
ataque, árboles de amenazas y patrones de seguridad que están disponibles para la comunidad. Es útil examinar y describir estos
conceptos brevemente para reducir la confusión entre estos conceptos y los patrones de ataque y para que la literatura relacionada
pueda usarse como referencia al investigar o usar patrones de ataque.
Bell Labs desarrolló el concepto de árboles de fallas para la Fuerza Aérea en 1962. Posteriormente se aplicó en un contexto de software
en los trabajos de Nancy Leveson [Leveson 83] a principios de la década de 1980. Los árboles de fallas brindan una forma formal y
metódica de describir la seguridad de los sistemas, en función de varios factores que afectan la falla potencial del sistema. Los árboles
de fallas se usan comúnmente en ingeniería de seguridad; cuyo objetivo es garantizar que los sistemas críticos para la vida se comporten
según lo requerido cuando fallan partes de ellos [Vesely 81]. Los árboles de fallas tienen fallas del sistema como su nodo raíz y causas
potenciales de fallas del sistema como otros nodos en el árbol. Los "hijos" de cualquier nodo en particular representan formas en las que
el nodo puede "fallar". El concepto de árboles de fallas es especialmente útil para analizar software para el cual la disponibilidad/
capacidad de supervivencia es una preocupación de seguridad importante. Los árboles de fallas son un concepto bastante maduro, y
una gran cantidad de literatura elabora sobre el tema. Los árboles de fallas y los patrones de ataque solo tienen una relación muy tenue.
Los patrones de ataque están mucho más alineados con los árboles de ataque, un derivado de los árboles de fallas, que se describen a
continuación.
El concepto de árboles de ataque fue promulgado por primera vez por Bruce Schneier, CTO de Counterpane Internet Security. Los
árboles de ataque son similares a los árboles de fallas, excepto que los árboles de ataque se usan para analizar la seguridad del sistema.

elementos en lugar de seguridad. Los árboles de ataque proporcionan una forma formal y metódica de describir la seguridad de los
sistemas en función de diversos ataques [Schneier 99]. Microsoft usa el término "árbol de amenazas" para describir el mismo concepto
[Swiderski 04]. Un árbol de ataque tiene como raíz el objetivo del atacante, y los hijos de cada nodo padre representan condiciones de
las cuales una o más deben cumplirse para lograr el objetivo del nodo padre. De esta manera, todos los caminos a la raíz desde los nodos
hoja indican posibles ataques.
Un patrón de ataque consta de un conjunto mínimo de nodos en un árbol de ataque que logra el objetivo en el nodo raíz. En un
árbol con solo ramas "o", esto consta de todas las rutas desde un nodo hoja hasta el nodo raíz. Estos caminos también se conocen
como "caminos de ataque". En un árbol con algunas ramas "y", un patrón de ataque puede ser un subárbol del árbol de ataque que
incluye el nodo raíz y al menos un nodo hoja.
Los árboles de ataque y los patrones de ataque son conceptos complementarios que se equilibran y mejoran entre sí. Mientras que los
árboles de ataque brindan una visión holística de los ataques potenciales que enfrenta una pieza de software en particular, los patrones
de ataque brindan detalles procesables sobre tipos específicos de ataques comunes que pueden afectar clases enteras de software. Los
detalles y ejemplos de árboles de ataque se pueden encontrar en [Schneier 99].
Por último, otro concepto relacionado con los patrones de ataque son los patrones de seguridad. Los patrones de seguridad consisten
en soluciones generales a problemas de seguridad recurrentes. Un patrón de seguridad encapsula la experiencia en seguridad en forma
de soluciones examinadas para estos problemas recurrentes, presentando problemas y compensaciones en el uso del patrón [Kienzle
01]. Los ejemplos incluyen la implementación del bloqueo de cuentas para evitar ataques de fuerza bruta, el almacenamiento seguro de
datos de clientes y la autenticación de contraseñas. Debido a que los desarrolladores de software en general pueden no estar familiarizados
con las mejores prácticas de seguridad o con problemas de seguridad, los patrones de seguridad intentan proporcionar soluciones
prácticas que se pueden implementar de manera directa. Los patrones de seguridad también enumeran varias compensaciones en las
soluciones. Los patrones de seguridad pueden ser un complemento eficaz de los patrones de ataque al proporcionar soluciones viables a
patrones de ataque específicos a nivel de diseño. Como tal, debe tenerse en cuenta que los patrones de seguridad generalmente
describen tareas de implementación repetibles de nivel relativamente alto, como la autenticación de usuarios y el almacenamiento de datos.
Por lo general, no son adecuados para detalles de implementación de bajo nivel, como la terminación NULL de cadenas o incluso
problemas de diseño de muy alto nivel, como problemas de confianza del lado del cliente. Por lo tanto, son excelentes para describir
soluciones a problemas de programación con un contexto de seguridad, pero no demuestran cómo evitar las trampas más comunes en
el desarrollo de software. Un repositorio de patrones de seguridad está disponible en SecurityPatterns.org. El repositorio no pretende ser
una lista completa o más actualizada de patrones de seguridad.
1.2 Generación de patrones de ataque
La sección Introducción presentó información introductoria y contextual sobre los patrones de ataque. Esta sección
describe un proceso típico de cómo se generan realmente los patrones de ataque. El público objetivo de esta sección incluye
principalmente investigadores de seguridad y profesionales de seguridad experimentados que estén interesados en descubrir y
documentar nuevos patrones de ataque. Sin embargo, también es valioso para una audiencia más amplia, ya que brinda una comprensión
mucho más profunda de la fuente y el significado de los patrones de ataque.

Propósito
A medida que los atacantes se vuelvan más sofisticados, descubrirán nuevas formas de explotar el software. Además, el nuevo
software y los entornos de desarrollo introducirán nuevos tipos de vulnerabilidades que actualmente pueden ser desconocidas.
Para asegurarse de que la comunidad de desarrollo de software continúe implementando contramedidas efectivas contra los
últimos ataques conocidos, es importante analizar los últimos exploits para ver si representan nuevos tipos de ataques. Solo
después de caracterizar los ataques, se pueden diseñar e implementar contramedidas efectivas contra esos tipos de ataques.
Además, analizar los últimos exploits y generar nuevos patrones de ataque es un requisito previo esencial para la creación de
políticas de seguridad efectivas. Los desarrolladores de políticas deben conocer todos los ataques conocidos que un sistema
puede enfrentar antes de intentar desarrollar políticas de seguridad relevantes y completas.
Si bien los patrones de ataque representan fundamentalmente enfoques comunes para los exploits, no necesariamente tienen
que generarse solo a partir de exploits reales descubiertos en la naturaleza. En los casos en que las organizaciones realizan
investigaciones relacionadas con la seguridad, pueden descubrir una nueva forma de atacar un sistema. La organización puede
utilizar este conocimiento internamente (o proporcionarlo a los proveedores) para mitigar los problemas antes de que los atacantes
los descubran. El ejemplo presentado al final de esta sección fue realmente descubierto de esta manera.
Entradas
El proceso de generación de patrones de ataque comienza cuando se descubre un nuevo exploit que no coincide con uno de los
patrones de ataque conocidos. Las entradas al proceso incluyen los exploits reales (si están disponibles), cualquier parche de
proveedor existente para los exploits, información forense y la base de conocimiento existente de patrones de ataque. Los exploits
pueden descubrirse en la naturaleza, o pueden ser generados por investigadores de seguridad en un intento de descubrir exploits
antes que los atacantes.
Análisis
El proceso de análisis de exploits normalmente consta de los siguientes pasos:
1. Analice el exploit mediante ingeniería inversa, análisis forense y análisis de cualquier

parches de los proveedores del software de destino. Este paso no es específico para el análisis de patrones de ataque
y, por lo general, se realiza para comprender los exploits y desarrollar contramedidas, como definiciones de antivirus y
herramientas de eliminación de spyware. Una vez que se revela el funcionamiento interno del exploit, puede comenzar el
análisis del patrón de ataque real.
2. Determinar si el exploit es una instanciación de algún patrón de ataque existente. Esto a menudo no es una decisión clara e
inequívoca. Se debe realizar un análisis cuidadoso y una comparación. En la mayoría de los casos en los que el exploit
se descubre en la naturaleza, será un patrón de ataque existente y el análisis se detendrá aquí. De lo contrario, se habrá
descubierto un nuevo patrón de ataque, que debe analizarse y documentarse como se describe a continuación.
3. Determinar la funcionalidad del software que contenía la vulnerabilidad. La funcionalidad podría ser un analizador de archivos,
un convertidor de formato, un controlador de cookies o cualquier otra cosa. Determine si el exploit ataca una vulnerabilidad
o debilidad en la funcionalidad particular o si el mismo problema podría existir en el software incluso si se eliminara el
componente funcional objetivo. Si el exploit apunta a una funcionalidad específica, intente generalizar el ataque. Por ejemplo,
si un ataque apunta a un reproductor de MP3,

entonces, ¿podrían usarse también ataques similares contra reproductores WMV, visores JPEG, extractores de archivos ZIP, etc.?
La vulnerabilidad podría residir en cualquier procesador de archivos binarios, o podría existir solo en la reproducción suave de MP3 .
haría.
4. Determinar cómo se aprovechó la vulnerabilidad del software. Los ejemplos incluyen proporcionar maliciosamente
archivo creado al software, aprovechando una condición de carrera, proporcionando caracteres de separación en la entrada o omitiendo el
filtrado de entrada del lado del cliente. Este paso ayuda a identificar cómo se aprovechó la funcionalidad objetivo determinada en el paso
anterior.
5. Determine qué nivel de habilidad o conocimiento necesitaría el atacante para ejecutar dicho ataque. Tenga en cuenta que puede haber
diferentes niveles de habilidad y conocimientos necesarios para generar ciertos resultados. Por ejemplo, explotar un desbordamiento de
búfer para colapsar un sistema puede requerir muy poca habilidad, pero en realidad ejecutar código malicioso en el host de destino para
controlarlo puede requerir un atacante altamente calificado.
6. Determinar los recursos necesarios para ejecutar el ataque. ¿El ataque simplemente requiere que un atacante ingrese comandos
manualmente en una terminal, o implica comprometer miles de hosts antes de usarlos para atacar el objetivo principal? ¿La ejecución
del ataque requeriría el apoyo de una organización bien financiada? Es importante determinar los recursos necesarios para ejecutar
un ataque, ya que ayuda a determinar la probabilidad de un ataque y ayuda a priorizar las mitigaciones durante el desarrollo real del
software.
7. Determinar la motivación del atacante que genera este tipo de exploit. ¿Por qué elegiría un atacante este tipo de ataque en particular? Dada
la posibilidad de elegir entre varios medios técnicos (p. ej., ejecutar un desbordamiento de búfer) y no técnicos (p. ej., ingeniería social)
para lograr un objetivo, los atacantes tienden a seleccionar los más fáciles. Teniendo eso en cuenta, determine qué hace que el ataque
en particular sea atractivo. ¿Con qué tiene que empezar el atacante y qué quiere lograr el atacante?
Esta discusión debe ser principalmente técnica, porque las consecuencias comerciales obviamente dependerán del software en particular
y del entorno implementado. Las consecuencias pueden incluir la ejecución de código arbitrario en el host de destino, la denegación de
servicio, la obtención de acceso privilegiado al host de destino, etc.
Evaluación
Una vez que se genera un nuevo patrón de ataque, debe evaluarse para asegurarse de que modela bien las vulnerabilidades aplicables. Es
fundamental que la evaluación sea realizada por una persona diferente a la que generó el patrón de ataque. De lo contrario, el autor del
patrón de ataque podría pasar por alto los problemas debido a las suposiciones implícitas realizadas durante el análisis. El primer paso es
asegurarse de que un patrón de ataque preexistente no modele las vulnerabilidades. Si se encuentra un patrón de ataque preexistente que
modela el exploit, determine por qué se creó el nuevo patrón de ataque y si sería más beneficioso modificar el patrón de ataque existente que
crear uno nuevo.
Suponiendo que el patrón de ataque es nuevo, asegúrese de que los exploits a partir de los cuales se generó sean en realidad instancias del
patrón de ataque. Si no, determine qué modificaciones al patrón de ataque se requieren para corregir el problema. Si se hace esto, examine
también el patrón de ataque no modificado para determinar si es un patrón de ataque válido que puede aplicarse en otros escenarios.
El siguiente paso es asegurarse de que el patrón de ataque no sea demasiado genérico. Las preguntas que pueden ayudar a determinar
esto incluyen:

• ¿El patrón de ataque describe qué parte del software es atacada?
• ¿Describe el patrón de ataque cómo se proporciona la entrada maliciosa al software de destino?
• ¿El conocimiento del patrón de ataque ayudará a un diseñador o desarrollador de software a evitar el problema?
Si la respuesta a cualquiera de las preguntas anteriores es "no", es probable que el patrón de ataque sea demasiado genérico.
Por ejemplo, un patrón de ataque demasiado genérico puede indicar que "proporcionar una entrada inesperadamente grande a la
aplicación hace que se bloquee". Este "patrón de ataque" no describe qué parte del software es atacada o cómo se proporciona
información maliciosa al software de destino. Los desarrolladores no aprenden qué entrada necesitan validar (p. ej., entrada de campos
de texto en una aplicación de GUI de Windows, entrada de un formulario web, entrada de un archivo de recursos binarios). No
proporciona ninguna indicación sobre qué fuente particular de entrada no es confiable y, por lo tanto, debe validarse. Un atacante
potencial tampoco podría usar este patrón de ataque porque no le dice absolutamente nada acerca de cómo se podría proporcionar
entrada maliciosa a la aplicación. Esto puede considerarse positivo, pero el hecho es que es probable que muchos atacantes ya estén
familiarizados con el ataque, junto con instancias de explotación específicas. Al mismo tiempo, si el patrón de ataque es completamente
inútil para un atacante inexperto, es probable que no represente una captura valiosa de la perspectiva del atacante. Se pueden
proporcionar más detalles para que el patrón de ataque sea útil para los desarrolladores de software, mientras se mantienen privados
los detalles particulares del ataque.
El siguiente paso es asegurarse de que el patrón de ataque no sea demasiado específico. Las preguntas que pueden ayudar a
determinar esto incluyen:
• ¿Se puede usar el patrón de ataque para encontrar vulnerabilidades en el software no descubiertas previamente?
• ¿Pueden atacantes relativamente inexpertos utilizar el patrón de ataque para aprovechar el software?
Si la respuesta a la primera pregunta es "no", es probable que el patrón de ataque sea demasiado específico. Si la respuesta a la
segunda pregunta es "sí", entonces el ataque es extremadamente simple (como un ataque de delimitador de línea de comando) o el
patrón de ataque es demasiado específico y detallado. Si se encuentra que el patrón de ataque es demasiado específico o detallado,
este problema debe mitigarse. Es probable que un patrón de ataque demasiado específico beneficie solo a los atacantes y proporcione
poco valor continuo a los desarrolladores.
También se debe evaluar la accesibilidad del patrón de ataque; uno de los públicos objetivo son los diseñadores y desarrolladores
de software que pueden tener poca o ninguna capacitación en temas de seguridad. Sería fácil para los investigadores de seguridad
desarrollar patrones de ataque que son completamente inaccesibles para los diseñadores y desarrolladores. Es importante tener en
cuenta el objetivo de crear patrones de ataque: los patrones de ataque están diseñados para ayudar a los diseñadores y desarrolladores
de software con poca experiencia en seguridad a comprender los problemas de seguridad para que puedan desarrollar software seguro.
Salidas
La estructura esquemática típica y el contenido de un patrón de ataque que surge de este proceso se describen en la sección de
Introducción anterior. Además de la información descrita allí, el patrón de ataque debe indicar claramente los autores y revisores del
patrón de ataque. Según el entorno en el que se desarrolló el patrón de ataque, debe publicarse en un repositorio de una empresa
privada o en un repositorio de patrones de ataque público. Esto asegurará que el patrón de ataque sea fácilmente accesible y no se
pierda.

Ejemplo
Ilustraremos el proceso de generación de patrones de ataque usando un ejemplo. El ejemplo utilizado aquí fue elegido por su
sencillez de explicación y comprensión y fue, en realidad, descubierto a través de otros
medio.
Supongamos que recientemente ha habido muchos informes de archivos comprimidos con gzip que han causado la falla de la
mayoría de los detectores de virus. Además, recibir datos HTML comprimidos con gzip está provocando que los navegadores web
populares se bloqueen. A una investigadora de seguridad, Alice, se le ha encomendado la tarea de investigar los problemas y
determinar si están relacionados.
Alice ya está familiarizada con los patrones de ataque existentes que son de conocimiento público (suponga que este ataque en
particular no es de conocimiento público). Comienza por obtener algunos archivos problemáticos comprimidos con gzip. Intenta
descomprimir uno y observa que la utilidad de descompresión tarda un tiempo inusualmente largo. Obtiene una lista de archivos del
directorio en el que se está descomprimiendo el archivo y observa que el archivo que genera la utilidad de descompresión actualmente
tiene un tamaño de más de 1 gigabyte. Al darse cuenta de que esto es inusual, detiene la utilidad de descompresión y abre el archivo
parcialmente descomprimido en un editor hexadecimal. El archivo descomprimido parece contener solo la letra "A", repetida una y
otra vez. Sabiendo cómo funciona la codificación de longitud de ejecución, Alice se da cuenta de que el archivo descomprimido
simplemente debe contener el mismo byte repetido miles de millones de veces, para que la compresión sea extremadamente
eficiente. El archivo comprimido más o menos solo necesita contener la letra "A", junto con el número de veces que se repite en el
archivo original. Por lo tanto, el archivo comprimido puede ser extremadamente pequeño (de varios kilobytes a varios megabytes),
pero el archivo descomprimido puede tener un tamaño de varios cientos de gigabytes. Cuando un detector de virus intenta escanear
el contenido del archivo comprimido, primero debe descomprimirlo en la memoria. La mayoría de las computadoras no tienen varios
cientos de gigabytes de memoria y eventualmente se quedan sin memoria y fallan. Alice descubre el mismo problema en sitios web
maliciosos que envían una pequeña cantidad de datos HTML codificados con gzip a los clientes, lo que hace que los navegadores
que intentan descomprimir y mostrar los datos se bloqueen.
Ahora que Alice descubrió la causa del ataque y sabe que el patrón de ataque no existe actualmente, decide generar un patrón de
ataque que describa el ataque. Ella determina que la funcionalidad bajo ataque es la descompresión de datos codificados con gzip.
Sin embargo, también se da cuenta de que gzip no es el único tipo de codificación que puede ser susceptible a este tipo de ataques.
Otros formatos de codificación, incluidos ZIP, bzip2, PNG y GIF, también utilizan codificación de longitud de ejecución para comprimir
datos y podrían ser vulnerables a este tipo de ataques. De hecho, cualquier tipo de compresión donde la eficacia de la compresión
no esté limitada por un valor razonable puede ser vulnerable a este tipo de ataques. Por lo tanto, Alice determina que cualquier
software que realice la descompresión puede ser vulnerable a este tipo de ataques.
A continuación, Alice debe determinar cómo se explota la vulnerabilidad. Ella determina que este problema podría ocurrir cada vez
que un host de destino intente descomprimir datos maliciosos. Todo lo que debe hacer un atacante es activar el software en el
host de destino para intentar descomprimir los datos en la memoria. El software que puede hacer esto incluye escáneres de virus,
visores de imágenes y navegadores web. Por lo tanto, el atacante debe colocar de alguna manera los datos maliciosos en el host
de destino. En la mayoría de los casos, una utilidad como un escáner de virus haría el resto automáticamente. De hecho, esto se
puede utilizar para provocar un ataque de denegación de servicio a gran escala. El archivo malicioso se puede enviar por correo
electrónico a una dirección en una corporación de destino, y el escáner de virus en el servidor de correo electrónico hará que el
servidor se bloquee. Incluso si existen servidores de respaldo, también se bloquearán cuando intenten continuar donde el

otro servidor lo dejó (es decir, cuando intentan escanear el archivo malicioso). Esto provocará una denegación de servicio y detendrá
todas las comunicaciones por correo electrónico dentro de esa organización. Este problema ahora es de conocimiento público y se ha
mitigado en todos los software antivirus populares. La divulgación pública de esta información en este documento ya no representa una
amenaza significativa.
Ahora, Alice debe determinar el nivel de habilidad del atacante que puede ejecutar tal ataque. Señala que crear un archivo malicioso no
es una tarea sencilla, ya que el atacante no puede simplemente crear un archivo de varios cientos de gigabytes de tamaño y luego
comprimirlo (debido a las limitaciones de memoria de la computadora del atacante). El atacante debe conocer los detalles del formato
del archivo comprimido para poder crear un archivo comprimido válido pero malicioso sin tener que crear el archivo descomprimido
original. Sin embargo, si un atacante no calificado alguna vez obtiene un archivo tan malicioso, puede aprovecharlo fácilmente para
atacar otros sistemas.
Por lo tanto, la creación de un archivo malicioso requiere un atacante hábil, pero incluso un atacante no calificado puede usar el archivo
para ejecutar un ataque.
A continuación, Alice debe determinar los recursos necesarios para ejecutar el ataque. Este ataque en particular requiere recursos
mínimos, simplemente que el atacante pueda enviar datos al objetivo, lo que podría hacerse a través de correo electrónico, HTTP,
FTP, etc.
Ahora que Alice conoce los detalles del ataque, necesita determinar por qué un atacante ejecutaría tal ataque. Identificar la motivación
ayuda a determinar la relevancia de este patrón de ataque para situaciones futuras. Este ataque está enfocado a lograr una denegación
de servicio. Un atacante que quiera interrumpir todas las comunicaciones por correo electrónico en una organización, ya sea por una
simple travesura o para causar pérdidas, puede intentar ejecutar este ataque. El ataque es extremadamente simple y un solo correo
electrónico puede detener todas las comunicaciones por correo electrónico dentro de una organización, independientemente de la
cantidad de servidores de correo de respaldo. El atacante también puede querer negar a todos los usuarios el acceso a un tablero de
mensajes publicando una imagen maliciosa en el tablero de mensajes que hace que los navegadores de los usuarios se bloqueen cuando
intentan verla. Un atacante profesional que desee monetizar un ataque de este tipo podría incluso aprovechar este ataque en combinación
con otras acciones comerciales, como cerrar una subasta de letras del Tesoro en un momento oportuno para manipular los resultados
monetarios. Hay varios ataques de este tipo en los que un atacante puede denegar al objetivo el acceso a algún recurso durante un
período de tiempo limitado.
A continuación se describe el patrón de ataque:
1. Nombre y clasificación del patrón: Denegación de servicio - Bomba de descompresión
ÿ Prerrequisitos del ataque: la aplicación debe descomprimir los datos comprimidos. Para que el ataque sea lo más efectivo
posible, la descompresión debe ocurrir automáticamente sin la intervención del usuario.
ÿ Descripción: el atacante genera una pequeña cantidad de datos comprimidos que se descomprimirán en una cantidad
extremadamente grande de datos. Los datos comprimidos pueden tener solo unos pocos kilobytes de tamaño, mientras que
los datos descomprimidos pueden tener varios cientos de gigabytes de tamaño. El objetivo es ejecutar un software que
intenta descomprimir automáticamente los datos en la memoria para analizarlos (como con el software antivirus) o para
mostrarlos (como con los navegadores web). Cuando el software de destino intenta descomprimir los datos maliciosos en la
memoria, se queda sin memoria y hace que el software de destino y/o el host de destino se bloqueen.
ÿ Vulnerabilidades o debilidades relacionadas: CWE-Amplificación de datos, CVE-2005-1260
DERECHOS DE AUTOR 2007 CIGITAL, INC. dieciséis

ÿ Método de ataque: mediante la elaboración malintencionada de datos comprimidos y su envío al objetivo a través de cualquier
protocolo (por ejemplo, correo electrónico, HTTP, FTP).
ÿ Motivación del ataque-Consecuencias: El atacante quiere negarle al objetivo el acceso a ciertos recursos.
fuentes.
ÿ Habilidad o conocimiento del atacante requerido: crear el exploit requiere una cantidad considerable de habilidad. Sin embargo,
una vez que dicho archivo está disponible, un atacante no calificado puede encontrar software vulnerable
y atacarlo.
ÿ Recursos requeridos: No se requieren recursos especiales o extensos para este ataque.
ÿ Soluciones y Mitigaciones: Restrinja el tamaño de los archivos de salida al descomprimir a un valor razonable. Especialmente,
maneje con cuidado la descompresión de archivos con una relación de compresión alta. Los creadores de descompresores
podrían especificar un tamaño máximo para el contenido descomprimido y luego detener la descompresión y lanzar una
excepción si alguna vez se alcanza este límite.
ÿ Descripción del contexto: cualquier aplicación que realice la descompresión de datos comprimidos en cualquier
formato (p. ej., imagen, archivo, sonido, HTML comprimido con gzip)
ÿ Referencias: vulnerabilidades de la bomba de descompresión
1.3 Uso del patrón de ataque
A diferencia de muchos otros conceptos y herramientas con un área de impacto limitada, los patrones de ataque brindan un valor
potencial durante todas las fases del desarrollo de software, independientemente del SDLC elegido, incluidos los requisitos, la arquitectura,
el diseño, la codificación, las pruebas e incluso la implementación del sistema. Sin embargo, debido a que los patrones de ataque describen
cómo un atacante puede romper el software, es posible que algunos lectores no entiendan de inmediato cómo se pueden usar los patrones
de ataque para construir software seguro. Una vez que el lector comprende la importancia de comprender la perspectiva del atacante sobre
la seguridad del software, el valor de los patrones de ataque se vuelve intuitivamente claro. Sin saber cómo se puede atacar el software, es
difícil saber cómo defenderse de los ataques.
Las siguientes secciones describen cómo se pueden aprovechar los patrones de ataque durante cada etapa del SDLC. Para hacer
la información más concreta, cada sección proporciona un ejemplo. Todos los ejemplos utilizarán como base una aplicación que debe
desarrollarse. La aplicación se basará en la web y estará diseñada para que los consumidores puedan comprar libros en línea.
Recopilación de requisitos
Este documento asume que el lector está familiarizado con las actividades básicas y los resultados de los esfuerzos típicos de
definición de requisitos de software. Muchos otros recursos explican las diversas metodologías y desafíos para la recopilación de
requisitos. El sitio Build Security In ofrece una buena bibliografía comentada de ingeniería de requisitos. La discusión aquí se centrará en
el papel que juegan los patrones de ataque en la definición de requisitos más apropiados y completos con respecto a la seguridad del
software en desarrollo.
Requerimientos funcionales

La mayoría de la recopilación de requisitos comienza con requisitos funcionales de nivel relativamente alto, como "los
usuarios podrán acceder al sitio utilizando al menos las últimas versiones de Internet Explorer y Mozilla Firefox" y "los
usuarios podrán comprar libros en cualquier moneda". Estos requisitos de alto nivel generalmente conducen a requisitos
funcionales más detallados y potencialmente pueden eliminar los requisitos de seguridad. Estos requisitos de seguridad
pueden ser funcionales, visibles o no para el usuario final, o de naturaleza no funcional, pero igualmente importantes. Muy
a menudo, los requisitos funcionales y no funcionales detallados, incluidos los requisitos de seguridad, se pasan por alto
y se descuidan porque el enfoque general es la funcionalidad básica.
Obtención de requisitos de seguridad a partir de requisitos funcionales
Los dos requisitos anteriores deberían dar lugar a preguntas que podrían ayudar a identificar los requisitos de seguridad.
Si un usuario intenta ver el sitio web con cualquier cosa que no sean las últimas versiones de Internet Explorer y Mozilla
Firefox, ¿qué debería suceder? ¿Es aceptable si el navegador falla? ¿Es aceptable si no se muestra absolutamente nada?
¿Hay algo que el servidor deba hacer para diferenciar entre navegadores? ¿Qué debería suceder si los datos de
autoidentificación enviados por el cliente son falsificados (por ejemplo, si Mozilla Firefox está configurado para informarse
como Internet Explorer)? Además, si los usuarios pueden comprar libros en otras monedas, ¿deberían poder navegar por
el sitio web en otros idiomas o esquemas de codificación (por ejemplo, Unicode)? Si es así, ¿cuántos idiomas y esquemas
de codificación debe admitir el sitio web? ¿Qué debería pasar si un cliente envía caracteres desde un lenguaje o esquema
de codificación que el servidor no acepta?
Como se muestra arriba, el proceso de hacer que los requisitos funcionales sean más específicos a menudo también
es un mecanismo efectivo para identificar los requisitos de seguridad. Por ejemplo, indicar que “si un cliente envía
caracteres de un idioma que el servidor no reconoce, el servidor devolverá un código de estado HTTP 415” es un buen
requisito de seguridad. Esto informa a los desarrolladores cómo manejar el problema. De lo contrario, es posible que se
pase por alto el problema, lo que provocará problemas como que los atacantes puedan eludir los filtros de entrada.
Requisitos de seguridad positivos y negativos: el papel de los patrones de ataque
Los requisitos centrados en la seguridad suelen dividirse entre requisitos positivos, que especifican los comportamientos
funcionales que debe mostrar el software (a menudo características de seguridad) y requisitos negativos (normalmente
en forma de casos de mal uso/abuso), que describen comportamientos que el software no debe mostrar. exposición para
operar de forma segura [McGraw 06].
Los patrones de ataque pueden ser un recurso invaluable para ayudar a identificar los requisitos de seguridad tanto
positivos como negativos. Tienen un beneficio directo obvio al definir la reacción esperada del software a los ataques que
describen. Cuando se colocan en el contexto de los demás requisitos funcionales del software y al considerar las
debilidades subyacentes a las que se dirige el ataque, pueden ayudar a identificar tanto los requisitos negativos que
describen posibles comportamientos no deseados como los requisitos funcionales positivos para evitar, o al menos mitigar,
el potencial. ataque. Por ejemplo, si un cliente proporciona el requisito "la aplicación debe aceptar caracteres ASCII",
entonces se puede usar el patrón de ataque "Codificación Unicode" para hacer la pregunta "¿Qué debe hacer la aplicación
si se encuentran caracteres Unicode u otro conjunto de caracteres inaceptable?" ?” A partir de esta pregunta, los casos
de uso indebido/abuso se pueden definir como "Usuario malintencionado proporciona caracteres Unicode en el campo de
entrada de datos". Al tener una definición específica para este requisito negativo, los diseñadores, implementadores y
evaluadores tendrán una idea clara del tipo de entorno hostil con el que debe lidiar el software y construirán el software en
consecuencia. Esta información también puede ayudar a definir requisitos positivos como "El sistema filtrará todas las
entradas de caracteres Unicode". Si este tipo

de los requisitos se pasan por alto, la aplicación desarrollada puede tener instancias en las que, sin saberlo, puede
aceptar caracteres Unicode, y un atacante podría usar ese hecho para eludir los filtros de entrada para caracteres ASCII.
actores
Muchas vulnerabilidades resultan de especificaciones y requisitos vagos. Esto incluye ambigüedades fuera del alcance
inmediato de la aplicación, incluido el "comportamiento no especificado" en ciertas especificaciones (p. ej., lenguaje C y
cómo los compiladores deben lidiar con ciertas situaciones) o RFC (p. ej., fragmentación de IP y cómo los nodos finales
interpretan la especificación de diferentes maneras). ). Los requisitos deben abordar específicamente estas ambigüedades
para evitar abrir múltiples agujeros de seguridad. En general, los patrones de ataque permiten que el recopilador de
requisitos haga preguntas "qué pasaría si" para que los requisitos sean más específicos. Si un patrón de ataque indica "Un
atacante puede aprovechar la condición X para causar Y", entonces una pregunta válida puede ser "¿Qué debe hacer la
aplicación si encuentra la condición X?"
Niveles variables de detalle y especificidad del patrón de ataque
Los patrones de ataque pueden existir en diferentes niveles de detalle y especificidad; a menudo pueden comenzar
de manera más abstracta con instancias de explotación menos conocidas y luego madurar en nivel de detalle con el
tiempo a medida que se descubren más instancias de explotación. Estos diferentes niveles de detalle también pueden
influir en los requisitos que identifican en diferentes niveles. Los patrones de ataque más abstractos suelen dar lugar
a requisitos no funcionales menos específicos, mientras que los patrones de ataque más detallados suelen dar lugar a
requisitos funcionales más específicos.
Arquitectura y Diseño
Una vez que se han definido los requisitos, todo el software debe pasar por algún nivel de arquitectura y diseño.
Independientemente de la formalidad del proceso seguido, los resultados de esta actividad formarán la base del software e
impulsarán todas las actividades de desarrollo restantes. Durante la arquitectura y el diseño, se deben tomar decisiones
sobre cómo se estructurará el software, cómo se integrarán e interactuarán los diversos componentes, qué tecnologías se
aprovecharán y cómo se interpretarán los requisitos que definen cómo funcionará el software. Es necesaria una cuidadosa
consideración durante esta actividad, ya que hasta el 50 % de los defectos de software que provocan problemas de
seguridad son fallas de diseño [McGraw 06]. En el ejemplo de la Figura 1, una arquitectura potencial podría consistir en un
sistema de tres niveles con el cliente (un navegador web que aprovecha Javascript/HTML), un servidor web (que aprovecha
los servlets de JavaTM) y un servidor de base de datos (que aprovecha Oracle 10i) . Las decisiones tomadas a este nivel
pueden tener un impacto significativo en el perfil de seguridad general del software
haría.
Figura 0-1: Ejemplo de arquitectura

Los patrones de ataque pueden ser valiosos durante la arquitectura y el diseño de dos maneras. Primero, algunos patrones
de ataque describen ataques que explotan directamente fallas de arquitectura y diseño en el software. Por ejemplo, el patrón de
ataque "Hacer que el cliente sea invisible" descrito en la sección Introducción anterior explota los problemas de confianza del lado
del cliente que son evidentes en la arquitectura del software. En segundo lugar, los patrones de ataque en todos los niveles
pueden proporcionar un contexto útil para las amenazas a las que probablemente se enfrente el software y, por lo tanto, determinar
qué características arquitectónicas y de diseño se deben evitar o incorporar específicamente. El patrón de ataque Make the Client
Invisible nos dice que no se puede confiar en absolutamente nada que el cliente devuelva, independientemente de los mecanismos
de seguridad de la red (por ejemplo, SSL) que se utilicen. El cliente no es de confianza y un atacante puede devolver literalmente
cualquier información que desee. Todas las validaciones de entrada, verificaciones de autorización, etc. deben realizarse en el
lado del servidor. Además, cualquier dato enviado al cliente debe ser considerado visible por el cliente independientemente de su
presentación prevista (es decir, los datos que el cliente no debería ver nunca deben enviarse al cliente). Realizar verificaciones de
autorización en el lado del cliente para determinar qué datos mostrar son inaceptables.
El patrón de ataque Make the Client Invisible instruye a los arquitectos y diseñadores para que se aseguren de que no se lleve a
cabo absolutamente ninguna lógica empresarial en el lado del cliente. De hecho, según los requisitos del sistema y las amenazas
y riesgos que enfrenta el sistema, los arquitectos y diseñadores pueden incluso querer definir un validador de entrada a través del
cual toda la entrada al servidor debe pasar antes de enviarse a las otras clases. Tales decisiones deben tomarse en la fase de
arquitectura y diseño, y los patrones de ataque brindan alguna orientación sobre qué problemas deben considerarse.
Es esencial documentar cualquier patrón de ataque utilizado en la fase de arquitectura/diseño para que la aplicación pueda
probarse utilizando esos patrones de ataque. Las pruebas deben crearse en la fase de prueba posterior para validar que las
mitigaciones para los patrones de ataque considerados durante esta fase se implementaron correctamente.

Implementación y Codificación
Si la arquitectura y el diseño se han realizado correctamente, cada desarrollador que implemente el diseño debe escribir
componentes bien definidos con interfaces bien definidas.
Los patrones de ataque pueden ser útiles durante la implementación porque identifican las debilidades específicas a las que se
dirigen los ataques relevantes y permiten que el desarrollador se asegure de que estas debilidades no ocurran en su código.
Estas debilidades podrían tomar la forma de errores de implementación o simplemente construcciones de codificación válidas que
conllevan implicaciones de seguridad. Los errores de implementación no siempre son fáciles de evitar o de detectar y corregir. Incluso
después de aplicar técnicas de revisión básicas, aún pueden seguir siendo abundantes y pueden hacer que el software sea vulnerable
a explotaciones extremadamente peligrosas. Es importante ampliar las técnicas de revisión básicas con preocupaciones relevantes de
seguridad más enfocadas. Si no se verifica correctamente un límite de matriz, por ejemplo, un atacante puede ejecutar código arbitrario
en el host de destino. Si no se realiza una validación de entrada adecuada, un atacante puede destruir una base de datos completa.
Los problemas de seguridad subyacentes en el código válido sin errores suelen ser más difíciles de identificar. No se pueden probar
con un modelo de comportamiento funcional como se puede hacer con los errores. Requieren un conocimiento especializado de cómo
son estas debilidades. Este documento se centra en cómo se pueden usar los patrones de ataque para identificar debilidades
específicas para la orientación y la mitigación al informar al desarrollador con anticipación sobre los problemas que se deben evitar y
al proporcionar una lista de problemas (Reglas de codificación de seguridad) para buscar en revisiones de código, a menudo se realiza
con herramientas de escaneo de seguridad.
La prevención requiere que los desarrolladores entiendan los patrones de ataque aplicables y se aseguren de que su código no
permita que los patrones de ataque tengan éxito. El primer paso es determinar qué patrones de ataque se aplican a la aplicación
que se está desarrollando. Solo un subconjunto de patrones de ataque será aplicable a un software en particular, según su
arquitectura, entorno y las tecnologías utilizadas para implementarlo. Por ejemplo, las vulnerabilidades de desbordamiento de búfer
normalmente no son aplicables si toda la codificación se realiza en Java.
Las vulnerabilidades de validación de entrada pueden ser menos preocupantes si todas las entradas que no son de confianza se
pasan a través de un filtro central del lado del servidor examinado antes de que se entreguen a su código, en lugar de depender
de todos los puntos de entrada (a menudo implementados por diferentes personas) para realizar su validación propia. Es importante
determinar los patrones de ataque que serán aplicables para un proyecto en particular. En algunos casos, se pueden aplicar
diferentes patrones de ataque para diferentes componentes de un producto.
Una vez que se determinan los patrones de ataque aplicables, se pueden usar para guiar a los desarrolladores sobre lo que no
deben permitir en su código. En nuestro ejemplo, un desarrollador podría aprovechar un patrón de ataque como "inyección de script
simple" y evitar las vulnerabilidades XSS. Una forma relativamente sencilla de hacer esto es identificar todos los lugares desde los
que se envía la salida al usuario desde una fuente que no es de confianza y convertir los caracteres potencialmente peligrosos en
sus equivalentes HTML. Por ejemplo, convierta ”<” en ”<”, ”>” en ”>”, etc. Las bibliotecas de terceros para Java pueden realizar
tales conversiones automáticamente. La función escape() de JavaScript realiza una tarea similar. Esto evitará que se muestren al
usuario entradas no confiables que contengan datos potencialmente maliciosos. Los datos maliciosos podrían incluir artefactos como
etiquetas <script> insertadas por un atacante. Esta versión de conversión debe administrarse cuidadosamente para evitar posibles
problemas de desbordamiento de búfer no deseados. Por supuesto, este problema también podría manejarse de otras maneras,
como el uso de una lista blanca oa nivel de arquitectura definiendo un validador de entrada y un desinfectante de salida. El enfoque
arquitectónico sería más adecuado para proyectos grandes, mientras que tratar el problema a nivel de implementación puede ser
aceptable para proyectos más pequeños.

Una buena arquitectura/diseño, así como la conciencia del desarrollador, mejorada con patrones de ataque, pueden ayudar
potencialmente a minimizar muchas debilidades de seguridad. Sin embargo, también es esencial asegurarse de que todo el código
fuente, una vez escrito, se revise para validar la ausencia de debilidades específicas. Debido al tamaño y la monotonía de esta tarea,
normalmente se realiza mediante una herramienta de análisis automatizada (p. ej., las de Fortify, Klocwork, Coverity). Aunque las
herramientas de análisis no pueden encontrar todas las debilidades de seguridad, pueden ayudar a eliminar muchos problemas
potenciales. Usando patrones de ataque como guía, se pueden apuntar subconjuntos específicos de las reglas de búsqueda de las
herramientas y se pueden crear reglas personalizadas para que las organizaciones ayuden a encontrar debilidades de seguridad o
instancias de incumplimiento de los estándares de seguridad. Por ejemplo, revisando el posible patrón de ataque de "Inyección de script
simple", una organización puede tener un estándar de seguridad en el que todas las entradas que no sean de confianza pasen a través
de un filtro de entrada, y todas las salidas de datos obtenidos de una fuente que no sea de confianza pasen a través de un codificador.
Una organización puede desarrollar dichos filtros y codificadores, y las herramientas de análisis de código fuente estático pueden ayudar
a encontrar situaciones en el código en las que los desarrolladores pueden haber descuidado el cumplimiento de los estándares y optaron
por usar las funciones de entrada/salida de Java directamente.
Pruebas de software y control de calidad
Las pruebas y el aseguramiento de la calidad son una fase crítica en el ciclo de vida del desarrollo de software. El software debe pasar
por varios niveles y tipos de pruebas antes de que se lance a un entorno de producción. Los diferentes niveles de prueba incluyen
pruebas unitarias, pruebas de integración, pruebas de sistema, pruebas de regresión y pruebas de implementación. Los diferentes tipos
de pruebas incluyen pruebas funcionales, pruebas de seguridad (incluidas las pruebas de penetración), pruebas de rendimiento, pruebas
de integridad de datos y pruebas de estrés. Una discusión detallada sobre todos los diversos niveles y tipos de pruebas está fuera del
alcance de este documento. Sin embargo, es importante tener en cuenta que los patrones de ataque se pueden aprovechar durante
muchos niveles y tipos de pruebas diferentes para ayudar a diseñar casos de prueba.
La fase de prueba se diferencia de las anteriores en el SDLC en que su objetivo no es necesariamente constructivo; el objetivo de
las pruebas de seguridad basadas en el riesgo suele ser intentar romper el software para que los problemas descubiertos puedan
solucionarse antes de que un atacante pueda encontrarlos [Whittaker 03]. El propósito de usar patrones de ataque en esta fase es que
las personas que realizan los distintos niveles y tipos de pruebas actúen como atacantes que intentan romper el software.
Aprovechamiento de los patrones de ataque en las pruebas unitarias
Las pruebas unitarias implican probar los componentes o piezas de software de forma independiente para garantizar que cumplan con
sus especificaciones funcionales y no funcionales. Los patrones de ataque aplicables deben usarse para identificar las debilidades
específicas relevantes y generar casos de prueba para cada componente para garantizar que evitan o resisten estas debilidades. Por
ejemplo, para probar la inyección de comandos de shell utilizando delimitadores de comandos, se deben diseñar cadenas de entrada
maliciosas que contengan comandos de shell separados por delimitadores e ingresarlos a los componentes aplicables para garantizar un
comportamiento adecuado cuando se les proporcione este tipo de datos maliciosos.
Aprovechamiento de los patrones de ataque en las pruebas de integración
Las pruebas de integración implican garantizar que los componentes de software se integren e interactúen entre sí correctamente.
Esto requiere no solo garantizar que todos los componentes se compilen juntos y que sus interfaces coincidan, sino también que la
funcionalidad real de los componentes no entre en conflicto. de lo contrario. Una cuestión de seguridad principal a tener en cuenta
durante las pruebas de integración es si los componentes individuales

hacer suposiciones diferentes basadas en la seguridad de modo que el todo integrado pueda contener conflictos o ambigüedades.
Los patrones de ataque se pueden aprovechar para crear algunos casos de prueba para las pruebas de integración. Como mínimo,
los patrones de ataque documentados en la fase de arquitectura/diseño deben usarse para crear pruebas de integración.
También pueden aplicarse otros patrones de ataque. Por ejemplo, el patrón de ataque Make the Client Invisible
se puede usar para crear casos de prueba que simulan un atacante que pasa por alto al cliente y se comunica directamente con el
servidor o un atacante que modifica el cliente para enviar datos maliciosos al servidor.
Aprovechamiento de los patrones de ataque en las pruebas del sistema
Las pruebas del sistema se utilizan para probar todo el sistema para garantizar que cumpla con todos sus requisitos
funcionales y no funcionales. Con suerte, los patrones de ataque se usaron en la fase de recopilación de requisitos para generar
requisitos de seguridad. Estos requisitos de seguridad deben probarse durante las pruebas del sistema. Por ejemplo, el patrón de
ataque de codificación Unicode se puede usar para generar casos de prueba que garanticen que la aplicación se comporte
correctamente cuando se le proporcionen caracteres inesperados. Los probadores deben proporcionar caracteres que la aplicación no
debe aceptar para ver cómo se comporta. El comportamiento real de la aplicación cuando está bajo ataque debe compararse con el
comportamiento deseado definido en los requisitos de seguridad.
mentos.
Aprovechamiento de los patrones de ataque en las pruebas de regresión
La prueba de regresión es la ejecución de pruebas existentes en el software cada vez que se cambia el código para garantizar que
el cambio no solo causó el comportamiento previsto, sino también que no causó inadvertidamente cambios no deseados. Los patrones
de ataque no aportan ningún valor nuevo y único a las pruebas de regresión en sí.
Las pruebas de regresión efectivas deben incluir casos de prueba de seguridad desarrollados durante los otros niveles de prueba que
fueron guiados por el uso de patrones de ataque.
Aprovechamiento de los patrones de ataque para realizar pruebas en el entorno operativo
Incluso después de la aplicación de los niveles de prueba típicos, el software trae consigo problemas de seguridad aplicables a las
pruebas. Incluso si se consideró la seguridad en todo el SDLC al crear el software, e incluso si se realizaron pruebas exhaustivas, es
probable que aún existan vulnerabilidades en el software. Esto se debe a que ninguna pieza de software útil es 100 por ciento segura
[Viega 01]. Para que el software sea útil, debe haber formas de usarlo.
Volviendo a la analogía de la bóveda de un banco, una bóveda podría hacerse extremadamente segura si se construyera a unas pocas
millas bajo tierra, si estuviera rodeada por varios cientos de pies de concreto reforzado con acero, no tuviera puertas de acceso y
pudiera resistir ataques de bombas nucleares. Incluso podría ser 100 por ciento seguro, pero por supuesto sería completamente inútil.
Para que sea útil, debe haber una forma de acceder a él, y es probable que un atacante explote los puntos de acceso si los puntos de
acceso son las formas más fáciles de obtener acceso. Los diseñadores y constructores solo pueden asegurarse de que no permitan los
ataques de "canal lateral", de modo que la única forma en que el atacante pueda acceder a la bóveda sea a través de la puerta
integrada. Los diseñadores no pueden hacer absolutamente nada para evitar que un empleado autorizado entregue la combinación de
la bóveda a sus amigos, que deje la puerta entreabierta, etc. La bóveda en sí puede hacerse extremadamente segura, pero el entorno
operativo real puede ser completamente inseguro. El software también enfrenta problemas similares. El software se puede diseñar y
desarrollar para que sea extremadamente seguro, pero si se implementa y opera de manera insegura, se pueden presentar muchas
vulnerabilidades. Por ejemplo, una pieza de software podría proporcionar un cifrado fuerte y una autenticación adecuada antes de
permitir el acceso a los datos cifrados, pero si un atacante puede obtener credenciales de autenticación válidas, él/ella

puede subvertir la seguridad del software. Nada es 100 por ciento seguro, y el entorno debe estar protegido y monitoreado para
frustrar los ataques.
Los modelos de programación orientados a objetos más nuevos que implican principios como la inversión del control complican aún
más el problema. Por ejemplo, el marco Spring para Java permite que los componentes se "conecten" entre sí de forma declarativa,
de forma similar a los componentes que se ensamblan en un automóvil. No es necesario reconstruir todo el automóvil si un fabricante
decide usar una marca diferente de llantas; Spring Framework permite un intercambio similar de componentes de software durante la
implementación sin necesidad de reconstruir piezas grandes.
Sin embargo, el problema es que los diseñadores y desarrolladores del sistema pueden haber hecho suposiciones con respecto a
ciertos componentes que pueden no ser satisfechas por los componentes que realmente se implementan. Dichos problemas no
pueden considerarse culpa del fabricante a menos que proporcionen documentación insuficiente.
Por lo tanto, es extremadamente importante realizar pruebas de seguridad del software en su entorno operativo real. Las
vulnerabilidades presentes en el software a veces pueden enmascararse mediante protecciones ambientales, como firewalls de red
y firewalls de aplicaciones, y las condiciones ambientales a veces pueden crear nuevas vulnerabilidades. Dichos problemas a
menudo se pueden descubrir mediante una combinación de análisis de caja blanca y caja negra del entorno implementado. El
análisis de caja blanca del software implementado implica realizar un análisis de seguridad del software, incluido su entorno
implementado, con conocimiento de la arquitectura, el diseño y la implementación del software. El análisis de caja negra
(generalmente en forma de prueba de penetración) implica tratar el software implementado como una "caja negra" e intentar atacarlo
sin ningún conocimiento de su funcionamiento interno. Si bien el análisis de caja negra es relativamente económico y puede encontrar
muchos de los problemas más obvios y pequeños, no es tan efectivo para encontrar muchos de los problemas a menudo más
significativos.
Estos problemas generalmente se encuentran solo a través de un análisis de caja blanca en profundidad. La caja negra es buena
para encontrar los problemas de implementación específicos que sabe que debe buscar, mientras que la caja blanca detallada y
estructurada puede descubrir problemas inesperados de arquitectura/diseño e implementación que quizás no haya sabido buscar.
Ambos tipos de pruebas son importantes y los patrones de ataque se pueden aprovechar para ambos.
Aprovechamiento de patrones de ataque para pruebas de caja negra
Las pruebas de caja negra de aplicaciones web generalmente se realizan utilizando herramientas como probadores de seguridad
de aplicaciones como los de compañías como SPI Dynamics que ejecutan automáticamente pruebas predefinidas. Los patrones de
ataque se pueden utilizar como modelos para crear las pruebas que realizan estas herramientas, lo que les otorga una mayor
relevancia y eficacia. Sin embargo, dichas herramientas no pueden encontrar muchos tipos de fallas arquitectónicas, o incluso todos
los errores de implementación. Estas herramientas generalmente prueban una gran variedad de ataques, pero generalmente no
pueden encontrar vulnerabilidades arquitectónicas sutiles. Encuentran efectivamente problemas que los script kiddies y otros
atacantes relativamente inexpertos probablemente explotarían. Sin embargo, un atacante experto podría encontrar muchos problemas
que una herramienta de escaneo de vulnerabilidades simplemente no podría detectar. Por ejemplo, la falta de cifrado para transmitir
números de seguridad social no se detectaría utilizando una herramienta automatizada, ya que el hecho de que los números de
seguridad social no estén cifrados no es una falla puramente técnica. La herramienta de prueba de caja negra no puede determinar
qué información es un número de seguro social y no puede aplicar la lógica comercial. Los patrones de ataque que son útiles para
crear pruebas de caja negra incluyen aquellos que se pueden ejecutar de forma remota sin requerir muchos pasos. Algunos ejemplos
de vulnerabilidades que pueden detectar las pruebas de caja negra incluyen secuencias de comandos entre sitios mediante la inyección
de JavaScript en un parámetro HTTP y la inyección de SQL mediante caracteres separadores. Las herramientas automatizadas se
pueden usar para crear pruebas, como cuando se inserta un carácter separador en un campo de formulario HTML, para observar

si se produce un error de base de datos. Las pruebas de caja negra de aplicaciones no web se pueden realizar de manera similar
utilizando diferentes herramientas.
Aprovechamiento de patrones de ataque para pruebas de caja blanca
Las pruebas de caja blanca son más lentas pero más completas que las de caja negra. Implica un análisis exhaustivo realizado por expertos
en seguridad que tienen acceso a los requisitos, la arquitectura, el diseño y el código del software. El objetivo principal de las pruebas de
seguridad de caja blanca es encontrar los errores de implementación más oscuros que no se encuentran en las pruebas de caja negra, así
como las fallas de arquitectura y diseño y los problemas de seguridad relacionados. La ventaja de las pruebas de caja blanca radica en su
minuciosidad; Los expertos en seguridad pueden analizar un sistema durante varias semanas o meses mientras conocen todos sus detalles
internos. Si se mitigan las fallas que encuentran, es poco probable que un atacante con un conocimiento limitado del funcionamiento interno
de una aplicación encuentre fácilmente una habilidad vulnerable significativa. Los patrones de ataque se pueden aprovechar para determinar
las áreas de riesgo del sistema y, por lo tanto, en qué áreas del sistema debe centrarse el análisis de caja blanca. Los patrones de ataque más
efectivos para el análisis de caja blanca incluyen aquellos que apuntan a las debilidades de la arquitectura y el diseño. Los patrones de ataque
que apuntan a debilidades de implementación específicas no deben ignorarse por completo porque, en muchos casos, las debilidades de
implementación solo se pueden encontrar fácilmente mediante revisiones manuales de código (un tipo de análisis de caja blanca). Un patrón
de ataque que podría aprovecharse en las pruebas de caja blanca de un sistema implementado es rastrear datos confidenciales en un canal
inseguro. Aquellos con conocimiento de las clasificaciones de confidencialidad de los datos y una comprensión del contexto comercial en torno
a varios tipos de datos pueden determinar si alguna información que siempre debe comunicarse a través de un canal cifrado, en realidad se
envía a través de un canal no seguro. Dichos problemas suelen ser específicos de un entorno implementado; por lo tanto, se requiere un
análisis del software implementado real.
Aprovechamiento de los patrones de ataque en el espectro más amplio de las pruebas
La fase de prueba del SDLC es vital para garantizar la seguridad del software en desarrollo y, como se describe aquí, los patrones de ataque
pueden desempeñar un papel valioso y amplio en las diversas actividades de prueba. Existen otros tipos de pruebas más específicos en los
que los patrones de ataque podrían aprovecharse explícita o implícitamente para probar la seguridad del sistema, pero ese nivel de detalle
excede el alcance de este documento. Proporcionar tal detalle es una excelente oportunidad para futuras investigaciones y contribuciones.
Operación de Sistemas
La operación del sistema y los patrones de ataque están relacionados de dos maneras. Primero, los patrones de ataque pueden guiar el
diseño de configuraciones y procedimientos operativos seguros. En segundo lugar, el conocimiento operativo de los problemas de
seguridad observados en el sistema de campo se puede utilizar para retroalimentar el proceso de generación de patrones de ataque.
En muchos casos, es posible que se implemente software con vulnerabilidades conocidas porque puede ser demasiado costoso solucionar
los problemas, es posible que no haya otras alternativas disponibles o puede ser menos costoso diseñar configuraciones y procedimientos
operativos para reaccionar a los ataques en lugar de mitigar realmente el problema. problemas en el propio software. También es esencial
contar con configuraciones y procedimientos operativos adecuados, incluso si el software es muy seguro. Como se describe en la sección
anterior Aprovechamiento de patrones de ataque para pruebas en el entorno operativo , las condiciones ambientales pueden dictar si ciertas
vulnerabilidades están presentes en el software implementado, y una gran parte de las condiciones ambientales consisten en configuraciones
y procedimientos operativos. Por lo tanto, las configuraciones y los procedimientos operativos adecuados son esenciales para crear un
entorno seguro [Graff 03].

Los patrones de ataque describen cómo un atacante puede realmente explotar el software. Dado un patrón de ataque, puede haber
formas en las que ciertos procedimientos operativos o configuraciones ambientales puedan frustrar el tipo de ataque. Por ejemplo,
se podrían implementar procedimientos para hacer frente al ataque con bomba de descompresión descrito en la sección Generación
de patrones de ataque hasta que esté disponible un parche del proveedor. Dichos procedimientos pueden incluir la eliminación
manual o la puesta en cuarentena de correos electrónicos sospechosos o el bloqueo temporal de todo el acceso de correo electrónico
externo a una organización.
El personal de operaciones, con su conocimiento de los problemas de seguridad y su familiaridad con los métodos de los atacantes
en un entorno operativo, también puede ser una gran fuente para generar nuevos patrones de ataque. Cuando existen indicios de
que un sistema fue explotado con éxito, generalmente se lleva a cabo una investigación que identifica cómo se llevó a cabo el
ataque. El proceso descrito en la sección anterior Generación de patrones de ataque se puede utilizar durante la investigación para
generar potencialmente nuevos patrones de ataque. Estos nuevos patrones de ataque se pueden aprovechar para modificar el
software existente y/o las configuraciones ambientales o para crear procedimientos operativos adicionales para mayor seguridad.
Generación de políticas y estándares
Si bien, como se describe en las secciones anteriores, los diseñadores y desarrolladores pueden usar patrones de ataque
directamente, también es útil en muchas organizaciones usar patrones de ataque indirectamente durante el SDLC al usarlos para
generar políticas y estándares que a su vez se usan para desarrollar software seguro. Estas políticas y estándares pueden incluir
los generados por terceros, como los estándares de la industria de tarjetas de pago (PCI) o los generados para uso interno dentro
de una organización. El uso de patrones de ataque para generar políticas es útil principalmente para organizaciones que necesitan
dictar estándares de seguridad para otras organizaciones (p. ej., consorcios de tarjetas de crédito, agencias gubernamentales) y
para grandes organizaciones de desarrollo de software.
El uso de políticas y estándares durante el SDLC no reemplaza el conocimiento de los patrones de ataque, y las organizaciones no
deben depender únicamente de que su personal de desarrollo de software use políticas para desarrollar software seguro por varias
razones. Primero, es mucho más fácil describir de manera concisa cómo se puede abusar del software que describir cómo se debe
construir un software seguro. Las mitigaciones de los patrones de ataque también varían según la tecnología utilizada. En segundo
lugar, esperar hasta que las políticas y los estándares se actualicen utilizando la información de los últimos patrones de ataque
agrega otra capa de indirección que aumenta la cantidad de tiempo que les toma a los desarrolladores de software implementar
contramedidas contra los últimos patrones de ataque.
Si bien las políticas y los estándares apropiados no reemplazan los patrones de ataque, son extremadamente útiles para las
actividades diarias de diseño y desarrollo de software. Las políticas describen reglas de alto nivel que se aplican a todo el software
implementado en una organización. Por ejemplo, una política puede establecer que "todos los datos obtenidos de una red deben
desinfectarse antes de que sean procesados por cualquier lógica comercial". Esta política puede estar diseñada para abordar
patrones de ataque como "delimitadores de comandos" y "XSS en encabezados HTTP".
Los estándares son refinamientos, a menudo sembrados con ejemplos útiles, de políticas que se aplican a software y/o
tecnologías específicas. Por ejemplo, abordar el patrón de ataque de "XSS en encabezados HTTP" en Java Serv permite el uso
de estándares como "todos los datos obtenidos de la red que contienen caracteres deben tener los siguientes caracteres eliminados
tan pronto como sean vistos por un servidor: '<', '>', '(', ')', ';' ”. Sin embargo, es importante tener en cuenta que los estándares siempre
deben desarrollarse e implementarse de manera equilibrada e integral y no de forma aislada. Por ejemplo, el ejemplo de la oración
anterior aplicado de forma aislada

podría dejar un sistema susceptible a problemas de codificación alternativos y, por lo tanto, debe coordinarse y combinarse con
otros estándares relevantes como un paquete efectivo.
Las políticas y los estándares son útiles en las grandes organizaciones porque garantizan que las mitigaciones de los patrones de ataque
se apliquen de manera uniforme en todo el código. Al igual que los patrones de ataque, las políticas y los estándares se pueden utilizar en
todas las fases del SDLC. Las políticas y los estándares también ayudan a las organizaciones a especificar los controles de seguridad
mínimos que deben implementarse para otras organizaciones que manejan ciertos tipos de datos.
1.4 Más información sobre patrones de ataque
Los patrones de ataque son un concepto bastante nuevo y, hasta el momento, hay relativamente poco contenido disponible para leer más.
La sección de referencias a continuación enumera algunos recursos que pueden resultar valiosos. Específicamente, los siguientes recursos
son directamente relevantes y deben ser considerados:
La iniciativa Common Attack Pattern Enumeration and Classification (CAPEC) patrocinada por el Departamento de Seguridad
Nacional. El objetivo de este esfuerzo es desarrollar e implementar para el público un catálogo de referencia inicial de patrones de
ataque junto con un esquema completo y una taxonomía de clasificación. Se espera que, después de su lanzamiento (segundo trimestre
de 2007), este catálogo continúe siendo el mecanismo estándar para identificar, recopilar, refinar y compartir patrones de ataque entre la
comunidad de software.
• Explotación de software: cómo descifrar el código [Hoglund 04]
• Modelado de ataques para seguridad de la información y supervivencia [Moore 01]
• Coincidencia de patrones de ataque con vulnerabilidades de seguridad en diseños de sistemas con uso intensivo de software [Gegick
05]
1.5 Glosario
ataque Un ataque es el acto de llevar a cabo un exploit.
ruta de ataque Una ruta de ataque es una ruta en un árbol de ataque desde un nodo hoja hasta el nodo raíz. Una ruta de
ataque puede ser una representación simplista de un patrón de ataque.
patrón de ataque Un patrón de ataque es un marco general para llevar a cabo un tipo particular de ataque, como un método
particular para explotar un desbordamiento de búfer o un ataque de interposición que aprovecha las debilidades
de la arquitectura. En este documento, un patrón de ataque describe el enfoque utilizado por los atacantes para
generar un exploit contra el software.
árbol de ataque Los árboles de ataque (conocidos como "árboles de amenazas" por Microsoft) proporcionan una forma
formal y metódica de describir la seguridad de los sistemas basados en varios ataques [Schneier 99].
El nodo raíz del árbol es el objetivo del atacante (conocido como "amenaza" por Microsoft), y los "hijos" de
cada nodo describen una forma de nivel inferior de lograr el objetivo del nodo principal. De esta manera, los
nodos de hoja generalmente contienen tareas de nivel relativamente bajo, como "instalar un registrador de
teclas en la máquina de destino", y el nodo raíz contiene un objetivo como "obtener la contraseña del
administrador".

agresor Un atacante es la persona que realmente ejecuta un ataque. Los atacantes pueden variar desde personas
muy poco calificadas que aprovechan los ataques automatizados desarrollados por otros ("script kiddies")
hasta agencias gubernamentales bien financiadas o incluso grandes sindicatos del crimen organizado
internacional con expertos en software altamente calificados.
insectos Los errores son problemas de software que existen solo en el código. Un error que existe en el código puede
o no ejecutarse o explotarse. Por lo tanto, un error puede o no representar una vulnerabilidad en el software
subyacente. Los errores se utilizan para describir errores menores de implementación que suelen ser fáciles
de corregir. Tenga en cuenta que el hecho de que los errores sean errores menores de implementación no
significa que el impacto de un atacante que explote el error sea pequeño. Por ejemplo, un desbordamiento
de búfer es un tipo de error bien conocido que generalmente es fácil de corregir. Sin embargo, explotar un
desbordamiento de búfer puede dar a un atacante control total sobre un sistema.
patrón de diseño Un patrón de diseño es una solución general repetible a un problema recurrente de ingeniería de software.
explotar Un exploit es una técnica o código de software (a menudo en forma de secuencias de comandos) que
aprovecha una vulnerabilidad o debilidad de seguridad en una pieza de software de destino.
defectos Las fallas son problemas de software que existen en el diseño del software. Una falla puede o no
representar una vulnerabilidad en el software subyacente. Mitigar una falla generalmente implica un
esfuerzo significativamente mayor que simplemente modificar unas pocas líneas de código. El problema
no radica únicamente en la implementación; el diseño subyacente tiene fallas y, por lo tanto, cualquier
implementación que siga al diseño contendría la falla.
Por ejemplo, realizar una lógica de negocios sensible en una aplicación de cliente que no es de confianza
es una falla de diseño que no se puede mitigar con una medida simple, como la modificación de los límites
de la matriz.
impacto El impacto es el efecto que enfrenta la organización que utiliza software vulnerable si se explota una
capacidad vulnerable. El impacto puede variar desde valores tangibles específicos, como multas monetarias,
desde el incumplimiento de una ley o regulación hasta valores intangibles, como daños a la marca y la
reputación.
casos de mal uso/abuso Los casos de uso indebido/abuso pueden verse como requisitos de casos de uso con un atacante como
actor. Representan acciones tomadas contra el software que no se encuentran dentro de los parámetros
operativos normales definidos del sistema. Por lo general, se identifican y modelan de manera integrada con
casos de uso funcionales positivos para un sistema.
riesgo Los riesgos capturan la probabilidad de que se explote una vulnerabilidad, así como el daño potencial
(impacto) que ocurrirá si lo es. Es importante tener en cuenta que los riesgos, las amenazas y los exploits
son cosas separadas. Los riesgos pueden estar presentes en el software de destino, en el host de destino
o en el entorno operativo más amplio del software.

análisis de riesgo El análisis de riesgos implica analizar el software objetivo en busca de vulnerabilidades y caracterizar su
naturaleza e impacto potencial. Microsoft llama a esto "modelado de amenazas". El análisis de riesgos
intenta identificar, priorizar y planificar la mitigación adecuada para los riesgos que enfrenta una pieza de
software.
patrón de seguridad Un patrón de seguridad es un patrón de diseño que pretende mostrar a los desarrolladores de software
cómo diseñar e implementar soluciones a problemas de seguridad comunes. Estas soluciones suelen
representar funciones de seguridad de software. Se puede usar un patrón de seguridad para mitigar múltiples
patrones de ataque, y un patrón de ataque se puede mitigar usando múltiples patrones de seguridad.
host de destino Un host de destino es la computadora o plataforma que ejecuta el software de destino de un ataque. Un
host puede ser atacado a través de las interfaces del software de destino oa través de mecanismos de
ataque puramente basados en la red.
software de destino El software de destino es el software que es el objetivo de un ataque.
amenaza Una amenaza es un actor o un agente que es una fuente de peligro para el sistema en consideración o los
activos a los que tiene acceso. La amenaza puede ser una persona que abusa del software, un programa que
se ejecuta en un sistema comprometido o incluso un evento no sensible, como una falla de hardware. Una
amenaza explota una vulnerabilidad en el software para atacarlo.
vulnerabilidades Una vulnerabilidad es una debilidad del software que puede ser aprovechada por un atacante. Los errores y
fallas forman colectivamente la base de la mayoría de las vulnerabilidades del software.
debilidad Una debilidad es una condición subyacente o construcción existente en un sistema de software que tiene el
potencial de afectar negativamente la seguridad del sistema.
1.6 Referencias
[Alejandro 64]
Alejandro, Cristóbal. Apuntes sobre la Síntesis de la Forma. Cambridge, MA: Prensa de la Universidad de Harvard, 1964.
[Alejandro 77]
Alejandro, Cristóbal; Ishikawa, Sara; y Silverstein, Murray. Un lenguaje de patrones. Nueva York, NY: Oxford University Press, 1977.
[Alejandro 79]
Alejandro, Cristóbal. Una forma atemporal de construir. Nueva York, NY: Oxford University Press, 1979.
[Oración 88]
Departamento del Ejército. AR 380-5 Programa de Seguridad de la Información del Departamento del Ejército, Almacenamiento de
Material y Documentos Clasificados (1988).

[Ellison 06]
Ellison, Roberto. Árboles de ataque. (2006).
[Gama 95]
Gama, E.; Helm, R.; Johnson, R.; & Vlissides, J. Patrones de diseño: elementos de software orientado a objetos
reutilizables. Boston, MA: Addison-Wesley, 1995.
[Gegick 05]
Gigick, Michael y Williams, Laurie. “Coincidencia de patrones de ataque con vulnerabilidades de seguridad en diseños
de sistemas intensivos en software”. ACM SIGSOFT Software Engineering Notes, Procedimientos del taller de 2005
sobre Ingeniería de software para sistemas seguros: creación de aplicaciones confiables SESS '05, Volumen 30, Número
4. Nueva York, NY: ACM Press, 2005.
[Graff 03]:Graff, Mark & van Wyk, Kenneth. Codificación segura: principios y prácticas. Sebastopol, CA: O'Reilly and
Associates, 2003.
[Hoglund 04]
Hoglund, Greg y McGraw, Gary. Explotación de software: cómo descifrar el código. Boston, MA: Addison Wesley,
2004 (ISBN 0-2017-8695-8).
[Holardo 02]
Howard, M.; & LeBlanc, D. Escritura de código seguro. Redmond, WA: Microsoft Press, 2002.
[Kienzle 01]
Kienzle, Darrell y Elder, Matthew. Patrones de seguridad (2001).
[Koizol 04]
Koizol, Jack; Litchfield, D.; Aitel, D.; Anley, C.; Eren, S.; Mehta, N.; y Riley. H. Manual de Shellcoder: descubrimiento y
explotación de agujeros de seguridad. Indianápolis, IN: Wiley, 2004 (ISBN 0764544683).
[Levison 83]
Leveson, Nancy G. & Stolzy, Janice L. "Análisis de seguridad de los programas ADA usando árboles de fallas". IEEE
Transactions on Reliability R-32, 5 (diciembre de 1983): 479-484.
[Levison 04]
Leveson, Nancy. "Un enfoque teórico de sistemas para la seguridad en sistemas intensivos en software". IEEE
Transactions on Dependable and Secure Computing 1, 1 (enero-marzo de 2004): 66-86.
[Mc Graw 06]
McGraw, Gary. Seguridad de software: Seguridad de edificios en. Boston, MA: Addison-Wesley, 2006. http://
www.buildingsecurityin.com

[Moore 01]
Moore, AP; Ellison, RJ; & Linger, Modelado de ataques RC para seguridad y supervivencia de la información
(CMU/SEI-2001-TN-001, ADA388771). Pittsburgh, PA: Instituto de Ingeniería de Software, Universidad Carnegie Mellon, 2001.
[ReliaSoft 03]
ReliaSoft. Análisis de árbol de fallas, diagramas de bloques de confiabilidad y BlockSim FTI Edition, 2003.
[Schneier99]
Schneier, Bruce. "Árboles de ataque: modelado de amenazas de seguridad". Diario del Dr. Dobb, diciembre de 1999.
[Schumacher 06a]
Schumacher, M.; Fernández-Buglioni, E.; Hybertson, D.; Buschmann, F. & Sommerlad, P. Patrones de seguridad: integración de
seguridad e ingeniería de sistemas. Nueva York, NY: John Wiley & Sons, 2006.
[Schumacher 06b]
Schumacher, Markus. SecurityPatterns.Org. (2006).
[Swiderski 04]
Swiderski, F. & Snyder, W. Modelado de amenazas. Redmond, WA: Microsoft Press (2004).
[Vesely 81]
Vesely, NOSOTROS; Goldberg, FF; Roberts, Nueva Hampshire; & Haasl, DH Fault Tree Handbook (NUREG-0492).
Washington, DC: Investigación de Sistemas y Confiabilidad, Oficina de Investigación de Reglamentación Nuclear, Comisión de
Reglamentación Nuclear de EE. UU., 1981.
[Viega 01]
Viega, John y McGraw, Gary. Creación de software seguro: cómo evitar problemas de seguridad de la manera correcta.
Boston, MA: Addison-Wesley, 2001.
[Whitaker 03]
Whittaker, James. Cómo romper la seguridad del software: técnicas efectivas para las pruebas de seguridad. Boston, MA:
Addison-Wesley, 2003.

Attack Patterns-Knowing Your Enemies in Order To Defeat Them-Paper PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Attack Patterns-Knowing Your Enemies in Order To Defeat Them-Paper PDF

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Patrones de ataque como recurso de conocimiento para

• Nombre del patrón y clasificación • Habilidad o conocimiento del atacante requerido

• Prerrequisitos de ataque • Recursos necesarios

• Descripción • Soluciones y Mitigaciones

• Vulnerabilidades o debilidades relacionadas • Descripción del contexto

• Método de ataque • Referencias

• Levantamiento de requisitos • Pruebas de software y control de calidad.

• Implementación y codificación. • Generación de políticas y estándares

DERECHOS DE AUTOR 2007 CIGITAL, INC. 1

diseño, desarrollo e implementación de software seguro.

patrones de ataque [Hoglund 04].

implementar formas adecuadas de evitar los ataques.

de manera efectiva en ausencia de soluciones mágicas.

software de destino El software de destino es el software que es el objetivo de un ataque.

DERECHOS DE AUTOR 2007 CIGITAL, INC. 2

mecanismos de ataque puramente basados en la red.

ataque Un ataque es el acto de llevar a cabo un exploit.

Muchos desafíos inhiben el desarrollo de software seguro. Estos desafíos incluyen

• la dificultad real de construir software seguro,

• fuerzas del mercado que favorecen la funcionalidad y el tiempo de comercialización sobre la

seguridad, y • una importante brecha de conocimiento entre el "sombrero negro"1

La ventaja del atacante

DERECHOS DE AUTOR 2007 CIGITAL, INC. 3

banco suele ser mucho más difícil que irrumpir en una.

usuario desprevenido para lanzar ataques.

de ataques conocidos aplicables.

Funcionalidad sobre seguridad

La brecha del conocimiento

DERECHOS DE AUTOR 2007 CIGITAL, INC. 4

DERECHOS DE AUTOR 2007 CIGITAL, INC. 5

• Nombre y clasificación del patrón: un identificador descriptivo único para el patrón.

DERECHOS DE AUTOR 2007 CIGITAL, INC. 6

• Vulnerabilidades o debilidades relacionadas: ¿Qué vulnerabilidades o debilidades específicas (ver

A continuación se proporcionan dos ejemplos de patrones de ataque [Hoglund 04]:

1. Nombre y clasificación del patrón: hacer que el cliente sea invisible

ÿ Método de Ataque: Protocolo de comunicación directa con el servidor.

DERECHOS DE AUTOR 2007 CIGITAL, INC. 7

ÿ Soluciones y Mitigaciones: ÿ Aumentar

servidor. Esta opción podría tener implicaciones significativas en el rendimiento.

ÿ Referencias: Explotación de software: cómo descifrar el código, p.150 [Hoglund 04].

2. Nombre y clasificación del patrón: Inyección de comandos de shell—Delimitadores de comandos

ÿ Descripción: Usando el punto y coma u otros caracteres no nominales, se pueden

exec ("cat data_log_" + entrada de usuario + ".dat")

DERECHOS DE AUTOR 2007 CIGITAL, INC. 8

ÿ Recursos requeridos: No se requieren recursos especiales o extensos para este ataque.

ÿ Descripción del Contexto: SO: UNIX.

ÿ Referencias: Software de Explotación [Hoglund 04].

• Ejemplos-Instancias: Ejemplos explicativos o demostrativos de instancias de exploit de este tipo de ataque.

DERECHOS DE AUTOR 2007 CIGITAL, INC. 9

• Indicadores-Advertencias de Ataque: Qué actividades, eventos, condiciones o comportamientos podrían servir en

DERECHOS DE AUTOR 2007 CIGITAL, INC. 10

1.2 Generación de patrones de ataque

mucho más profunda de la fuente y el significado de los patrones de ataque.

DERECHOS DE AUTOR 2007 CIGITAL, INC. 11

El proceso de análisis de exploits normalmente consta de los siguientes pasos:

1. Analice el exploit mediante ingeniería inversa, análisis forense y análisis de cualquier

DERECHOS DE AUTOR 2007 CIGITAL, INC. 12

controlarlo puede requerir un atacante altamente calificado.

servicio, la obtención de acceso privilegiado al host de destino, etc.

crear uno nuevo.

DERECHOS DE AUTOR 2007 CIGITAL, INC. 13

• ¿El patrón de ataque describe qué parte del software es atacada?