Sin pasar por firmas de IDS / IPS

original fecha: 09/27/2012
* Actualización de contenidos en formato de presentación, en el fondo *

Intro

Yo trabajo con muchas firmas para proporcionar protección a los clientes. A menudo recibo firmas que necesitan ser cambiado debido a una variedad de problemas de detección (como no detectar un ataque real en absoluto). En este post vamos a ver los problemas que se encuentran regularmente con las firmas de Snort. Primero, los grupos que hacen las firmas se clasificarán, a continuación, se analizarán los problemas entre estos escritores, y, finalmente, se discutirán más interesantes técnicas de firma de bypass. Todos los ejemplos serán de firmas reales todavía en uso. El objetivo final es conseguir que la gente a pensar de manera diferente acerca de cómo se escriben las firmas y / o la forma de verificar personalmente detección inapropiada.
* Tenga en cuenta que las múltiples derivaciones serán vistos por firma, pero cubriré sólo uno.
** También note que Snort está cubierto extensivamente. Estos temas van a través de diferentes sistemas IDS. Me gustaría destacar, en concreto, que Suricata no los mismos problemas con el reensamblaje protocolo que vamos a entrar en más adelante

El Ataque

El análisis inicial se hará uso de firmas para una negación popular de ataque del servicio de Apache que se ocupa de la superposición niveles de bytes (CVE-2011-3192) [1]. Cuando Apache vio la petición o solicitud estándar cabeceras HTTP cada rango se tratará como una nueva solicitud. Memoria se thusly asigna para cada solicitud y respondió con la gama del archivo solicitado. Si se han enviado cientos de paquetes que contiene miles de rangos entonces el uso de memoria disparó por las nubes a una tasa promedio de consumo de 1gb/10 segundos. Ataque Ejemplo:

GET / HTTP/1.1 stun.png
Host: victim.com
Range: bytes = 0 – ,2-10 ,2-11 ,2-12 ,2-13 ,2-14 ,2-15, … (0 – significa 0 a EOF)

Amateur Firmas

El grupo de aficionados firma está compuesta por las personas que pueden escribir firmas como una pequeña parte de su trabajo o son nuevos en las firmas en general. Esto cubre la concurrida SOC / NOC (operaciones de operaciones de seguridad de red / proveedor) que necesitan para dar cobertura a una vulnerabilidad / explotar lo más rápido posible para apaciguar a los clientes. Se oye hablar mucho acerca de los problemas del SOC de empresas y eso es porque no hay tanto trabajo diferente que hacer que es difícil centrarse en una cosa. Debido a esto la vulnerabilidad generalmente no se entiende lo suficiente o en absoluto, y nos encontramos con la mayoría de estas firmas construidos en torno al público hazaña más de la vulnerabilidad. El ejemplo de las firmas fueron sacados de una lista de correo de seguridad pública.

Amateur Firma # 1

Firma: Contenido: «Rango: bytes = 0 -«; umbral: tipo de umbral, el seguimiento by_src, cuenta 5, segundo 20,
Explicación: A los 20 segundos, si 5 paquetes son visto que contiene «Rango: Bytes = 0 -.» en la carga útil, entonces el fuego
Hay un par de problemas con esta firma. Incluso nuestro ataque inicial ejemplo omitirá esta firma, sin embargo, vamos a centrarnos en los bytes = 0 -. Todos los exploits públicos comenzado con este valor, pero eso no tiene por qué ser el caso. En su lugar, podría comenzar con 1 – y seguir adelante. Esta firma no tiene en cuenta ningún tipo de explotación de la variación y fue construido únicamente en torno a las hazañas públicas. Ataque Bypass:

GET / HTTP/1.1 stun.png
Host: victim.com
Range: bytes = 1 – , 0 – ,2-10 ,2-11 ,2-12 ,2-13 ,2-14 …

Firma Amateur # 2

Firma: el contenido : «Rango»; nocase; HTTP_HEADER; pcre: «/ ( d ,) {6} / xH»;
Explicación: Si «Rango» es visto en cualquier parte de una cabecera http, a continuación, comprobar si un dígito seguido de una coma se repite seis veces o más en forma secuencial.
Si conoce el ataque y PCRE entonces éste debe ser fácil de detectar. La cuestión radica en una comprobación de vulnerabilidad no válido. Esta expresión regular nunca se disparará en realidad en el ataque real por culpa no comprueba para una serie como 2-15, sólo coma separó números como 2,3,4. Este problema existe en una buena cantidad de firmas públicas y comerciales. Algunas de estas firmas en uso ni siquiera puede detectar el ataque. Uno puede comprender varias listas de tales firmas problemáticas mediante la búsqueda de ejemplos de PoC comunes como «| 41 41 41 41 |» y «| 61 61 61 61 |». Para una más interesante cadena de búsqueda para encontrar estos temas, por favor consulte la sección de conclusiones defensor.

Amateur Firma # 3

Firma: pcre: «/ ^ Rango: ? bytes s + d + – d d + – d +, d + – d +, d + – d +, d + – d +, d + – d +, / xH «;
: Si el comienzo de la cabecera HTTP normalizado (H) comienza con y contiene Range: bytes seguido por uno o más espacios en blanco caracteres, uno o más dígitos (+), un guión, cero o más dígitos (?) y una coma seis veces sequentually entonces fuego. Esta regla también ignora los espacios en blanco adicionales (x).
Se trata de un bien pensado firma, por desgracia, se perdió una pieza muy importante del rompecabezas. En primer lugar, vamos a describir normalize para despejar cualquier confusión:

«Match petición HTTP normalizado o cabecera de la respuesta HTTP (Similar a la cabecera http). Este modificador no se permite con la solicitud HTTP no normalizada o modificador de cabecera de respuesta HTTP (D) para el mismo contenido. Para el mensaje SIP, SIP cabecera partido de petición o respuesta (Similar a sorbo cabecera) «. [2]

La cuestión es sutil pero mortal. Mientras que esta firma es grande, se olvida de mayúsculas y minúsculas. Normalizar Actualmente no normaliza a una cadena de mayúsculas y minúsculas y no / yo estaba dentro de la expresión regular para ello. Para saltarse este todo lo que se necesita es mezclar un poco el forro de una manera válida. Nuevo ataque:

GET / HTTP/1.1 stun.png
Host: victim.com />
* Humor: «Recuerden niños, capititalization es la diferencia entre ayudar a su gato tío de un caballo y su tío Jack de un caballo.»

Profesional Firmas públicos:

Esta categoría hace de grupos que lanzan las firmas de forma gratuita. El problema es el mismo que el último grupo, pero diferente. Todo se reduce a no tener tiempo para analizar una vulnerabilidad en profundidad, ya que es una carrera de armas de cantidad. ¿Cuántas vulnerabilidades / exploits son liberados al día que la cobertura de la necesidad? No hay una ventana de tiempo lo suficientemente grande como para adentrarse en el análisis o la comprensión de ciertas vulnerabilidades en un nivel fundamental. De nuevo, estos fueron sacados de las firmas utilizadas actualmente liberados por un grupo popular de dicha firma libre.

Profesional Firma Pública # 1

Firma: contenido: «Range | 3a | bytes = 0 – ,5-0 ,5-1 ,5-2 ,5-3 ,5-4 ,5-5 ,5-6 ,5-7 ,5-8 ,5-9 ,5-10, 5-11,5-12,5-13,5-14 «; HTTP_HEADER;
Explicación: Si el contenido especificado. (| 3a | es hexagonal de colon) se ve en el interior de un HTTP_HEADER, entonces el fuego
traigo esto a su atención ya que es un ejemplo perfecto de que la experiencia de la firma o nombre profesional no hace que automáticamente el normas mejores que las firmas de aficionados. La cuestión aquí es una comprobación más específica explotar que las firmas de aficionados. Una vez más, simplemente modificando el byte oscila de usar, por ejemplo, 2 – en lugar de 5 -. Pasará por alto esta firma

Profesional Firma pública # 2

Firma: contenido: «Range | 3a |»; nocase; HTTP_HEADER; contenido: «bytes =»; HTTP_HEADER; nocase; distancia: 0; isdataat: 10, relativo; contenido: «»; HTTP_HEADER; dentro de: 11; isdataat: 10, relativa; contenido: «»; HTTP_HEADER; dentro de: 11; isdataat: 10, relativo; contenido: «»; HTTP_HEADER; dentro de: 11; isdataat: 70, relativo; contenido: «| 0a 0d |»; dentro de: 12; pcre: «/ Cocina x3a s bytes = [-0-9, x20] {100,} / iH»;
Explicación: Sin duda un bocado de una firma, pero voy a tratar de hacerlo lo más simple posible para seguir. Si Alcance: se ve en una cabecera http, bytes = en algún lugar después del último partido, una coma dentro de 11 bytes del último partido por tres veces consecutivas, y CRLF (final del encabezado HTTP) no se ve dentro de 12 bytes de último partido, a continuación, comprobar si hay 100 de los caracteres dados (guión, 0-9, coma o un espacio) con modificadores de caso insensibles y HTTP normalizador.
Ahora que estamos empezando a ver algunas optimizaciones de reglas profesionales. Esto paralizará otras firmas profesionales lo suficientemente pronto. Sin embargo, el problema aquí es que la PCRE no es completa tranquilidad. Es interesante que esta muestra un problema inverso, como se ve en el aficionado firma # 3. Lo que el PCRE no hace es ignorar espacios en blanco (x). Debido a esto existe un error en la comprobación de espacio en blanco PCRE (Rango x3a s? Bytes =). Sabemos que? significa 0 o 1 partidos, pero que no coincide con los espacios en blanco continuas. Así que es posible insertar una gran cantidad de espacios en blanco adicionales válidamente entre Rango: y bytes para eludir la firma. Tan cerca, pero tan lejos! Nuevo ataque:

GET / HTTP/1.1 stun.png
Host: victim.com
Range: bytes = 0 – ,2-10 ,2-11 ,2-12 ,2-13 ,2-14 ,2-15 …

Profesional Comercial Firmas

Estos son creados por las empresas que venden las reglas como una mercancía. Ellos tienen un mayor enfoque en las tácticas de optimización y, como de costumbre, no tienen tiempo para analizar vulnerabilidades en profundidad. Hay cuestiones interesantes en el juego intrínsecamente con las reglas comerciales. Cuantas más reglas que se agregan, más un sensor tiene que trabajar en el análisis de un solo paquete. Cuantas más reglas se activa, cuanto más se tiene que analizar y el mayor riesgo que tiene para la caída de paquetes en el análisis. Debido a esto, muchas de las medidas de optimización, como desplazamientos de bytes, se utilizan por lo que el cheque puede fallar tan rápido como sea posible y continuar con otros controles. Firmas comerciales tratan de utilizar este modo las empresas pueden ejecutar tantas reglas como sea posible y no tener que faltan comprobaciones de paquetes debido a la caída tasas. Nuestro ejemplo empresa creó tres reglas diferentes para la detección de este ataque. Uno de ellos que hemos demostrado una técnica anterior que se puede utilizar para omitir la comprobación (voy a ofrecer como un reto / ejercicio para el lector si están interesados). Los otros dos son prácticamente la misma firma que un método http diferente y menos de un cheque de contenido. Uno de estos dos se analizará a continuación.

Profesional Comercial Firma # 1

Firma: contenido: «HEAD»; nocase; http_method; contenido: «Range | 3A | bytes | 3D | 0 – | 2C | «; nocase; HTTP_HEADER;
Explicación: Si el HTTP método utilizado es la cabeza y el contenido en un encabezado HTTP contiene Range: bytes = 0 -, entonces el fuego
Aquí es donde empezamos cheques en su defecto desde el principio en el paquete.. Esta firma busca el método HEAD. Mientras que varios exploits públicos utilizan cabeza para no conseguir una gran cantidad de datos devueltos de nuevo a ellos, otros métodos se pueden utilizar y acaba de caer con las reglas del cortafuegos. Hicieron incluir otra firma que detectó por POST, pero no una que comprueba la GET. Vamos a conseguir más en forma en la detección de GET a menudo trabaja a nuestro favor en el futuro. Para omitir esta nada necesita ser cambiada de nuestro ejemplo el ataque inicial.

genéricos Bypass

Como se mencionó anteriormente, las normas tienen que ser lo más optimizado posible cuando más introducirse en el conjunto de reglas y / o el medio ambiente. De esta manera la posibilidad de tener la tasa de abandono se reduce mientras que ser capaz de detectar todos los ataques que queremos. Tenemos modificadores de contenidos como de profundidad, dentro, offset, distancia, http_method y etc que validan si el contenido se encuentra en ciertos bytes de la carga útil. Por desgracia para la defensa de este resulta ser un problema debido a la falta de entendimiento con el protocolo en lugar de la propia vulnerabilidad. Vamos a empezar a usar ejemplos al azar que se encuentran en los actuales firmas profesionales públicos y comerciales en uso hoy en día en lugar del Apache DoS.

La profundidad

» La palabra clave de profundidad permite al escritor regla para especificar hasta qué punto en un paquete Snort debería buscar el patrón especificado. profundidad modifica la palabra clave anterior «contenido» en la regla. Una profundidad de 5 diría Snort para que busque sólo para el patrón especificado dentro de los primeros 5 bytes de la carga útil «. [2] />
Firma: contenido: «GET AAAAAAAAAAAAAAAAAAAAA»; profundidad: 25;
Explicación: Si AAAAAAAAAAAAAAAAAAAAA GET es visto dentro de los primeros 25 bytes de la carga útil http entonces fuego.
Aparte de lo obvio PoC control específico para este ataque, hay algo mucho más interesante que podemos utilizar para evitar esta firma. Se trata de una comprensión del protocolo HTTP. Como esto sólo comprueba 25 Bytes, si ponemos el contenido más allá de este rango, el registro de entrada se pasa por alto. Bien podríamos insertar un número arbitrario de espacios entre la GET y Atléticos. Ejemplo:

GET de un HTTP/1.1

O incluso más divertido que podemos insertar una cantidad arbitraria de caracteres CRLF antes de la solicitud GET real. Ejemplo:

r n r n r n r n r n r n r n r n r n r n r n r n r n r n r n r n r n GET de un
HTTP/1.1
Dentro

«La palabra clave dentro es un modificador de contenido que se asegura de que en la mayoría de N bytes son entre el patrón coincide con la palabra clave de contenido (véase la sección 3.5.1). . Está diseñado para ser utilizado en combinación con la distancia (Sección 3.5.6) opción de autonomía «[2]

Firma: contenido: « «; dentro de: 100;
Explicación: En muestra el mismo problema como lo hace la profundidad. Si el «/ ur.php> » se ve dentro de los 100 bytes del partido original, entonces el fuego.
Esta es una simple derivación. Si nos vamos a insertar más de 100 caracteres entre el nombre de dominio y / ur.php, estamos fuera de peligro. Ejemplo:

http://blah.domainfree.com/ myuncleoncedroveahorsetoagalaxyfarfarawaysohecouldbeamongsthisownalienkindlivinginthestarsbeyondthemilkyway/ur.php

http_method

«La palabra clave es una http_method . modificador de contenido que restringe la búsqueda a Método extraído de una solicitud de un cliente HTTP «[2]

Firma: contenido: «GET»; http_method; contenido: «php.?»; http_uri; contenido: «x =»; http_uri; contenido: «& u =»; ​​http_uri; contenido: «& s =» ; http_uri; contenido: «& t =»; http_uri; contenido: «& java»; http_uri; contenido: «& pdf =»; http_uri; contenido: «y flash =»; contenido: «& qt = «; http_uri;
Explicación: Si el método HTTP GET se ve y el resto del contenido se vea en el URI HTTP, entonces el fuego.
Este es uno de mis tipos favoritos de bypass porque muchas normas son susceptibles. De acuerdo con el RFC HTTP, una solicitud HEAD realiza la acción de la solicitud GET, pero sólo las respuestas de cabecera se informó. O, según RFC:

«El método es idéntico al CABEZA GET excepto que el servidor NO DEBE devolver un cuerpo de mensaje en la respuesta.»

Así que si cambiamos nuestra petición a HEAD, todavía informe en el servidor web con la información (cheques ejemplo de reglas para el registro de Troya), recibimos ningún dato en el cuerpo como respuesta, y efectivamente eludir el firma. Ejemplo:

CABEZA /checkin.php?x=yes&u=Mozilla&s=Windows&t=12072012&java=1&pdf=0&flash=1&qt=1
valores URI hechas y no representa con exactitud el contenido de la memoria variable de

Conclusiones

Conclusión ofensivo

No es necesario conocer la firma para saber cómo muta el código de exploit para una vulnerabilidad. Estos ejemplos muestran que es necesario modificar el código de explotación lejos de cualquier código público tanto como sea posible. La parte más importante es entender el protocolo de la hazaña va a ser entregado en. Usted puede comenzar a posibles lugares de relleno para almacenar bytes adicionales para ver lo que está disponible byte o bytes se puede utilizar sin perturbar la explotación de sí mismo. Esto es lo que hice antes del libro de Zalewski «The Tangled Web» [4] salió que creó una de trucos para el relleno HTTP aceptable en diferentes servidores web

Conclusión Defensivo

similar a la conclusión de la ofensiva, un escritor firma necesita entender los protocolos tanto como vulnerabilidades. Sin ese conocimiento, un atacante real puede utilizar mutaciones simples de exploits para volar bajo el radar de IDS / IPS. El escritor también tiene que ser cautelosos acerca de la detección de desplazamiento de bytes a menos que sepan para datos seguros, no se puede insertar entre la coincidencia de contenido, por ejemplo, una estructura de formato de archivo conocido y de desviación. Si usted apenas está auditando sus propias reglas, por favor busque hasta prueba de concepto firmas como sea posible para ver si realmente tiene la detección de ciertas vulnerabilidades. grep-iE «(61 61 61 61) | (41 41 41 41) | (AAAA) | poc»-r / lugar / a / rules / le dará una lista de un tamaño decente para empezar a encontrar problemas con. No todos ellos serán falses, sin embargo, una mejor consulta puede ser hecha por el conocimiento de sus conjuntos de reglas y lo que puede ser genéricamente detección precisa (malware-cnc)

Otros Bypasses

Si quieres echa un vistazo a una lista de trucos genéricos actuales de derivación a nivel de red, por favor, eche un mirar el proyecto de AET en http://aet.stonesoft.com. [3]

Referencias

[ 1] http://seclists.org/…re/2011/Aug/175 – Original Apache Superposición Attack Range Pública Original Exploit Código
[2] http://manual.snort.org/ – Snort Online
Manual [3] http://aet.stonesoft.com – a nivel de la red lista de omisión
[4] http://lcamtuf.coredump.cx/tangled/ – Michal Zalewski – The Tangled Web

*** ACTUALIZACIÓN />