Vulnerabilidades críticas de Ripple20: lógica de detección y firmas


Este documento ha sido preparado por McAfee Advanced Threat Research en colaboración con JSOF, quien descubrió y responsablemente reveló las vulnerabilidades. Su objetivo es servir como un esfuerzo de investigación conjunto para producir información valiosa para los administradores de red y el personal de seguridad, que buscan comprender mejor estas vulnerabilidades para defenderse de la explotación. Las firmas producidas aquí deben considerarse y examinarse minuciosamente en entornos de ensayo antes de usarse en producción y pueden beneficiarse de un ajuste específico para la implementación de destino. Existen limitaciones técnicas en este trabajo, incluido el hecho de que podrían ser necesarios métodos de detección más complejos para detectar estas vulnerabilidades. Por ejemplo, múltiples capas de encapsulación pueden confundir la explotación de los defectos y aumentar la dificultad de detección.

También proporcionamos capturas de paquetes tomadas de la prueba de conceptos de vulnerabilidad como artefactos para probar e implementar las firmas a continuación o firmas personalizadas basadas en la lógica de detección. Las firmas y los scripts de Lua se encuentran en ATR Github página, así como en línea y en el apéndice de este documento respectivamente.

A partir de esta mañana (5 de agostoth), JSOF ha presentado detalles técnicos adicionales y análisis de explotación en BlackHat 2020, sobre las dos vulnerabilidades más críticas en DNS.

La información proporcionada en este documento está sujeta a cambios sin previo aviso y se proporciona "TAL CUAL", con todos los defectos, sin garantía ni garantía en cuanto a la exactitud o aplicabilidad de la información a cualquier situación o circunstancia específica y para su uso bajo su propio riesgo. Además, no podemos garantizar ningún punto de referencia de rendimiento o eficacia para ninguna de las firmas.

Desbordamiento de enteros en tfDnsExpLabelLength Conduciendo a Heap Overflow y RCE

CVE: CVE-2020-11901 (variante 1)
CVSS: 9
Protocolo (s): DNS sobre UDP (y probablemente DNS sobre TCP)
Puerto (s): 53

Descripción de la vulnerabilidad:
En la pila Treck, los nombres DNS se calculan mediante la función tfDnsExpLabelLength. Existe un error en esta función donde el cálculo se realiza usando un short sin firmar, lo que hace posible desbordar el valor calculado con un paquete de respuesta DNS especialmente construido. Ya que tfDnsExpLabelLength calcula la longitud completa de un nombre DNS después de descomprimirlo, es posible inducir un desbordamiento utilizando un paquete DNS mucho más pequeño que 2dieciséis bytes. En algunas rutas de código, tfGetRawBuffer se llama poco después tfDnsExpLabelLength, asignando un búfer en el montón donde se almacenará el nombre DNS utilizando el tamaño calculado por tfDnsExpLabelLength, lo que conduce a un desbordamiento del montón y un potencial RCE.
Si bien las versiones más recientes de la pila Treck dejarán de copiar el nombre DNS en el búfer tan pronto como se alcance un carácter que no sea alfanumérico o un guión, las versiones anteriores no tienen esta restricción y usan ID de transacciones predecibles para consultas de DNS, lo que hace esta vulnerabilidad es más fácil de explotar.

Limitaciones o consideraciones especiales para la detección:

Idealmente, la lógica de detección de esta vulnerabilidad implicaría calcular de forma independiente la longitud sin comprimir de todos los nombres DNS contenidos en las respuestas DNS entrantes. Desafortunadamente, esto puede ser computacionalmente costoso para que un dispositivo funcione con cada respuesta DNS entrante, especialmente porque cada una puede contener muchos nombres DNS. En cambio, debemos confiar en una combinación de heurísticas.

Además, actualmente no está claro si es posible ejercer esta vulnerabilidad cuando se utiliza EDNS (0) o DNS sobre TCP. Recomendamos asumir que es posible a los efectos de implementar la lógica de detección. Durante nuestras pruebas, se descubrió una inconsistencia en la forma en que Suricata manejaba el DNS sobre TCP; en algunos casos, se identificó correctamente como tráfico de DNS y, en otros casos, no. En consecuencia, se han creado dos reglas para determinar el tamaño del tráfico de DNS sobre TCP. La segunda regla usa la primitiva TCP en lugar de la primitiva DNS; sin embargo, la segunda regla solo se evaluará si no está marcada por la primera regla.

Debido a que la regla Suricata en dns_invalid_size.rules usa la longitud EDNS UDP de las respuestas DNS, que puede ser controlada por el atacante, se aplica un segundo límite superior de 4096 bytes.

Criterios de detección recomendados:

  • El dispositivo debe ser capaz de procesar el tráfico DNS y hacer coincidir las respuestas con sus solicitudes correspondientes.
  • El dispositivo debe ser capaz de identificar nombres DNS individuales dentro de paquetes DNS individuales.
  • El dispositivo debe marcar cualquier respuesta DNS cuyo tamaño supere lo "esperado". El tamaño esperado depende del tipo de paquete DNS enviado:
    • Para DNS sobre TCP, el tamaño no debe exceder el valor especificado en los dos primeros bytes de la carga útil de TCP.
    • Para DNS sobre UDP con EDNS (0), el tamaño no debe exceder el valor negociado en la solicitud, que se especifica en el campo CLASS del OPT RR, si está presente.
    • Para DNS sobre UDP sin EDNS (0), el tamaño no debe exceder los 512 bytes.
    • Todos estos se comprueban en dns_invalid_size.rules, que invoca dns_size.lua o dns_tcp_size.lua para la lógica.
  • El dispositivo debe marcar las respuestas DNS que contengan nombres DNS que superen los 255 bytes (antes de la descompresión).
    • Esto se comprueba en dns_invalid_name.rules, que invoca dns_invalid_name.lua para la lógica.
  • El dispositivo debe marcar las respuestas DNS que contengan nombres DNS compuestos por caracteres además de a-z, A-Z, 0-9, “-”, “_” y “*”.
    • Esto también se comprueba en dns_invalid_name.rules, que invoca dns_invalid_name.lua para la lógica.
  • El dispositivo debe marcar las respuestas de DNS que contienen una gran cantidad de punteros de compresión de DNS, particularmente punteros uno tras otro. La tolerancia específica dependerá de la red.
    • El dispositivo debe contar todas las etiquetas que comienzan con los bits 0b10, 0b01 o 0b11 contra este puntero total, ya que las versiones vulnerables de la pila Treck clasifican (incorrectamente) todas las etiquetas donde los dos primeros bits no son 0b00 como punteros de compresión. En el script Lua, tratamos cualquier valor por encima de 63 (0x3F) como un puntero por esta razón, ya que cualquier valor en ese rango tendrá al menos uno de estos bits establecido.
    • Los umbrales específicos se establecieron en 40 punteros en total en un solo paquete DNS o 4 punteros consecutivos para nuestra implementación de esta regla. Estos valores se eligieron ya que no parecían desencadenar ningún falso positivo en un PCAP de prueba muy grande, pero deben modificarse según sea necesario para adaptarse al tráfico típico de la red en la que se implementará la regla. La prueba de punteros consecutivos es especialmente útil ya que cada nombre de dominio solo debe tener un puntero (al final), lo que significa que nunca deberíamos ver muchos punteros seguidos en el tráfico normal.
    • Esto se implementa en dns_heap_overflow_variant_1.lua, que es invocado por dns_heap_overflow.rules.
  • La implementación de la lógica de detección anterior se ha dividido entre varios archivos de reglas de Suricata, ya que solo la lógica de recuento de punteros es específica de esta vulnerabilidad. La detección de vulnerabilidades que aprovechan esta vulnerabilidad se mejora con la adición de la verificación del tamaño de la capa DNS, la verificación de la longitud comprimida del nombre de dominio y la verificación de los caracteres del nombre de dominio implementadas en las otras reglas, pero se consideran firmas "auxiliares" y se marcan una de estas. no indica necesariamente un intento de explotación de esta vulnerabilidad específica.

Condiciones falsas positivas (firmas que detectan tráfico no malicioso):

Las redes que esperan tráfico no malintencionado que contenga nombres DNS con caracteres no alfanuméricos o una cantidad anormalmente grande de punteros de compresión DNS pueden generar falsos positivos. Desafortunadamente, la verificación de punteros solo en los campos del nombre de dominio es insuficiente, ya que un paquete malicioso podría usar un puntero de compresión que apunta a un desplazamiento arbitrario dentro de dicho paquete, por lo que nuestra regla verifica cada byte de la capa DNS. En consecuencia, la clasificación excesivamente liberal de Treck de los punteros de compresión de DNS significa que nuestra regla a menudo clasificará erróneamente los bytes no relacionados en la carga útil de DNS como punteros.

En nuestras pruebas, encontramos falsos positivos con nombres de dominio que contienen espacios o cosas como "https: //". Según las RFC, los caracteres como ":" y "/" no deben estar presentes en los nombres de dominio, pero pueden aparecer de vez en cuando en el tráfico real no malicioso. La lista de caracteres aceptables debe ampliarse según sea necesario para la red de destino para evitar un exceso de falsos positivos. Dicho esto, mantener la lista de caracteres aceptables lo más pequeña posible hará que sea más difícil colarse en shellcode para aprovechar una de las vulnerabilidades de DNS de Ripple20.

Pueden producirse falsos positivos en las reglas de tamaño de DNS cuando se utiliza DNS sobre TCP si Suricata no clasifica correctamente el paquete como un paquete de DNS, algo que ha ocurrido varias veces durante nuestras pruebas. Esto provocaría que se produzca la segunda comprobación de tamaño, que supone que todo el tráfico sobre el puerto 53 es tráfico DNS y procesa la carga útil en consecuencia. Como resultado, cualquier tráfico que no sea DNS en el puerto TCP 53 puede causar falsos positivos en este caso específico. Se recomienda que el número de puerto en la regla se ajuste para cualquier red donde se espera un protocolo diferente sobre el puerto 53.

La fragmentación del tráfico de DNS a través de TCP también puede generar falsos positivos. Si los flujos no se reconstruyen correctamente en el momento en que se ejecutan las reglas en la carga útil de DNS, las compensaciones de bytes utilizadas en los scripts de Lua adjuntos podrían analizar datos incorrectos. La fragmentación en los paquetes de respuesta de DNS no es común en una red estándar a menos que los valores de MTU se hayan establecido particularmente bajos. Cada regla debe evaluarse de forma independiente antes de su uso en producción según los requisitos y condiciones específicos de la red.

Condiciones falsas negativas (firmas que no detectan vulnerabilidad / explotación):

Es más probable que haya falsos negativos ya que esta lógica de detección se basa en heurísticas debido a que el cálculo de la longitud del nombre DNS sin comprimir es demasiado costoso computacionalmente. Los paquetes maliciosos construidos con cuidado pueden eludir las limitaciones de puntero sugeridas y aún así desencadenar la vulnerabilidad.

Firma (s):

dns_invalid_size.rules:

alert dns any any ‑> any any (msg:"DNS packet too large"; flow:to_client; flowbits:set,flagged; lua:dns_size.lua; sid:2020119014; rev:1;)

Lua script (dns_size.lua) se puede encontrar en Apéndice A

alert tcp any 53 -> any any (msg:"DNS over TCP packet too large"; flow:to_client,no_frag; flowbits:isnotset,flagged; lua:dns_tcp_size.lua; sid:2020119015; rev:1;)

Lua script (dns_tcp_size.lua) se puede encontrar en Apéndice A

dns_invalid_name.rules:

alert dns any any -> any any (flow:to_client; msg:"DNS response contains invalid domain name"; lua:dns_invalid_name.lua; sid:2020119013; rev:1;)

Lua script (dns_invalid_name.lua) se puede encontrar en Apéndice A

dns_heap_overflow.rules:

# Variant 1

alert dns any any -> any any (flow:to_client; msg:"Potential DNS heap overflow exploit (CVE-2020-11901)"; lua:dns_heap_overflow_variant_1.lua; sid:2020119011; rev:1;)

Lua script (dns_heap_overflow_variant_1.lua) se puede encontrar en Apéndice A

La falta de coincidencia de longitud de RDATA en los registros CNAME de DNS provoca un desbordamiento del montón

CVE: CVE-2020-11901 (variante 2)
CVSS: 9
Protocolo (s): DNS / UDP (y probablemente DNS / TCP)
Puerto (s): 53

Descripción de la vulnerabilidad:

En algunas versiones de la pila Treck, existe una vulnerabilidad en la forma en que la pila procesa las respuestas DNS que contienen registros CNAME. En tales registros, la longitud del búfer asignado para almacenar el nombre DNS se toma del campo RDLENGTH, mientras que los datos escritos son el nombre de dominio completo y descomprimido, que termina solo en un byte nulo. Como resultado, si el tamaño del nombre de dominio descomprimido especificado en RDATA excede el RDLENGTH proporcionado en un registro CNAME, el exceso se escribe más allá del final del búfer asignado, lo que resulta en un desbordamiento del montón y un potencial RCE.

Limitaciones o consideraciones especiales para la detección:

Aunque se ha confirmado la explotación de esta vulnerabilidad utilizando DNS maliciosos sobre paquetes UDP, no se ha probado utilizando DNS sobre TCP y no está claro si dichos paquetes utilizarían la misma ruta de código vulnerable. Hasta que esto se pueda confirmar, la lógica de detección debe asumir que ambos vectores son vulnerables.

Criterios de detección recomendados:

  • El dispositivo debe poder procesar las respuestas DNS entrantes.
  • El dispositivo debe ser capaz de identificar registros CNAME dentro de las respuestas DNS.
  • El dispositivo debe marcar todas las respuestas de DNS donde el tamaño real del campo RDATA para un registro CNAME exceda el valor especificado en el campo RDLENGTH del mismo registro.
    • En este caso, el "tamaño real" corresponde a cómo las versiones vulnerables de la pila Treck calculan la longitud de RDATA, lo que implica sumar el tamaño de cada etiqueta hasta que se encuentre un byte nulo, un puntero de compresión DNS o el final de la carga útil. . La pila Treck seguirá y descomprimirá el puntero que termina el nombre de dominio, si está presente, pero el script no lo hace, ya que este cálculo es simplemente demasiado caro, como se mencionó anteriormente.

Condiciones falsas positivas (firmas que detectan tráfico no malicioso):

Los falsos positivos deberían ser poco probables, pero posibles en escenarios donde los dispositivos de red envían tráfico no malicioso donde RDLENGTH no es igual al tamaño de RDATA, rompiendo así RFC 1035.

Condiciones falsas negativas (firmas que no detectan vulnerabilidad / explotación):

Dado que la lógica de detección no realiza la descompresión al calcular el "tamaño real" de RDATA, no detectará paquetes maliciosos que contengan nombres de dominio cuya longitud solo exceda RDLENGTH después de la descompresión. Desafortunadamente, la cobertura para este caso no es trivial, ya que estos paquetes son en realidad compatibles con RFC. Según RFC 1035, sección 4.1.4:

Si un nombre de dominio está contenido en una parte del mensaje sujeto a un campo de longitud (como la sección RDATA de un RR) y se usa la compresión, la longitud del nombre comprimido se usa en el cálculo de la longitud, en lugar de la longitud del nombre expandido.

Además de la sobrecarga computacional, la aplicación de dicha verificación probablemente resultaría en tasas muy altas de falsos positivos.

Firma (s):

dns_heap_overflow.rules:

# Variant 2

alert dns any any -> any any (flow:to_client; msg:"Potential DNS heap overflow exploit (CVE-2020-11901)"; lua:dns_heap_overflow_variant_2.lua; sid:2020119012; rev:1;)
El script Lua (dns_heap_overflow_variant_2.lua) se puede encontrar en Apéndice A

Escribir fuera de límites mediante el tipo de encabezado de enrutamiento 0

CVE: CVE-2020-11897
CVSS: 10
Protocolo (s): IPv6
Puerto (s): N / A

Descripción de la vulnerabilidad:

Cuando se procesan paquetes entrantes IPv6, se puede activar una inconsistencia al analizar el encabezado de enrutamiento IPv6 donde la longitud del encabezado se compara con el paquete total y no con la longitud del fragmento. Esto significa que si enviamos paquetes fragmentados con un tamaño total mayor o igual a la longitud del encabezado de enrutamiento especificado, procesamos el encabezado de enrutamiento bajo el supuesto de que tenemos suficientes bytes en nuestro fragmento actual (donde tenemos suficientes bytes en el total paquete reensamblado solamente). Por lo tanto, utilizando el tipo de encabezado de enrutamiento 0 (RH0) podemos forzar la lectura y escritura en una ubicación de memoria fuera de los límites.

También hay un efecto secundario secundario en el que podemos obtener una fuga de información en una dirección IPv6 de origen en un parámetro ICMP devuelto por el dispositivo.

Limitaciones o consideraciones especiales para la detección:

La RFC para RH0 define el campo de longitud como "dos veces el número de direcciones en el encabezado". Por ejemplo, si la longitud del encabezado de enrutamiento es seis, se esperan tres direcciones IPv6 en el encabezado. Tras la reconstrucción de los paquetes fragmentados, el número de direcciones informado se completa con los datos de los fragmentos que siguen. Esto crea direcciones IPv6 "no válidas" en el encabezado y potencialmente deforma la siguiente capa del paquete. Durante la explotación, también es probable que la siguiente capa del paquete tenga un formato incorrecto. Aunque ICMP se puede utilizar para realizar una fuga de información, es posible que la siguiente capa sea de cualquier tipo y, por lo tanto, varíe en longitud. Por tanto, la verificación de la longitud de esta capa podría resultar muy cara y no determinista.

Criterios de detección recomendados:

  • El dispositivo debe ser capaz de procesar tráfico IPv6 fragmentado
  • El dispositivo debe inspeccionar los paquetes fragmentados que contienen encabezado de enrutamiento tipo 0 (RH0). Si un paquete RH0 IPv6 está fragmentado, es probable que se esté aprovechando la vulnerabilidad.
  • Si la longitud de la capa IPv6 de un fragmento de paquete que contiene el encabezado RH0 es menor que la longitud informada en el encabezado de enrutamiento, es probable que se esté aprovechando la vulnerabilidad.
  • Tras la reconstrucción de los paquetes fragmentados, si el encabezado de la capa que sigue a IPv6 está mal formado, es posible que se esté aprovechando la vulnerabilidad.

Notas:

El tipo de encabezado de enrutamiento 0 fue obsoleto en el tráfico IPv6 en RFC 5095 en diciembre de 2007. Como resultado, puede ser factible simplemente detectar paquetes usando este criterio. Es posible que se produzcan falsos positivos en este escenario para dispositivos o plataformas heredados. Suricata ya proporciona una regla predeterminada para este escenario que se ha agregado a continuación. Según el RFC, no se supone que los enrutadores fragmenten los paquetes IPv6 y deben admitir una MTU de 1280, que siempre contendría todo el encabezado RH0, a menos que se utilice una cantidad inusual de extensiones de encabezado o un encabezado inusualmente grande. Si se sigue esto, un paquete que utilice el encabezado RH0 nunca debe fragmentarse a través de los límites del encabezado de la extensión RH0 y cualquier paquete RH0 fragmentado de esta manera debe tratarse como potencialmente malicioso. Tratar cualquier paquete RH0 fragmentado como potencialmente malicioso puede ser suficiente. Además, tratar cualquier paquete RH0 fragmentado con un tamaño de fragmentos por debajo de un umbral, así como paquetes IPv6 con múltiples encabezados de extensión o un encabezado inusualmente grande por encima de un umbral, puede proporcionar una detección de alta precisión.

Condiciones falsas positivas (firmas que detectan tráfico no malicioso):

Si se utilizan todos los criterios de detección descritos anteriormente, los falsos positivos deben ser mínimos, ya que la longitud informada de un paquete debe coincidir con su longitud real y el siguiente encabezado nunca debe contener datos con formato incorrecto. Si solo se marca el tipo de encabezado de enrutamiento 0, es más probable que se produzcan falsos positivos. En la regla adicional proporcionada, los falsos positivos deben ser mínimos, ya que RH0 está en desuso y el encabezado ICMP nunca debe tener sumas de comprobación no válidas o códigos desconocidos.

Condiciones falsas negativas (firmas que no detectan vulnerabilidad / explotación):

Pueden producirse falsos negativos si la firma se desarrolla demasiado específica para la capa que sigue a IPv6, por ejemplo, ICMP. Un atacante podría potencialmente aprovechar otra capa y aún aprovechar la vulnerabilidad sin la fuga de información; sin embargo, esto aún activaría la regla RH0 predeterminada. En la segunda regla a continuación, es probable que ocurran falsos negativos si:

  • Un atacante usa una capa que no es ICMP siguiendo la capa IPv6
  • Se utiliza un código ICMP válido
  • La suma de comprobación es válida y la carga útil es menor o igual a 5 bytes (este valor se puede ajustar en la firma)

Firma (s):

Ipv6_rh0.rules:

alert ipv6 any any -> any any (msg:"SURICATA RH Type 0"; decode-event:ipv6.rh_type_0; classtype:protocol-command-decode; sid:2200093; rev:2;)

alert ipv6 any any -> any any (msg:"IPv6 RH0 Treck CVE-2020-11897"; decode-event:ipv6.rh_type_0; decode-event:icmpv6.unknown_code; icmpv6-csum:invalid; dsize:>5; sid:2020118971; rev:1;)

Ejecución remota de código de túnel IPv4 / UDP

CVE: CVE-2020-11896

CVSS: 10.0
Protocolo (s): IPv4 / UDP
Puerto (s): Alguna

Descripción de la vulnerabilidad:

La pila Treck TCP / IP no maneja adecuadamente los paquetes IPv4-in-IPv4 entrantes con datos de carga útil fragmentados. Esto podría conducir a la ejecución remota de código al enviar múltiples paquetes UDP tunelizados especialmente diseñados a un host vulnerable.

La vulnerabilidad es el resultado de una operación de recorte incorrecta cuando la longitud total de IP anunciada (en el encabezado del paquete) es estrictamente menor que los datos disponibles. Al enviar paquetes IPv4 tunelizados utilizando varios fragmentos con un valor de longitud IP total pequeño, la pila TCP / IP ejecutaría la operación de recorte. Esto conduce a una situación de desbordamiento del montón cuando el paquete se copia en un paquete de destino asignado según la longitud más pequeña. Cuando los paquetes IPv4 tunelizados son paquetes UDP enviados a un puerto de escucha, existe la posibilidad de activar este exploit si la cola de recepción UDP no está vacía. Esto puede resultar en una situación de desbordamiento de pila explotable, lo que lleva a la ejecución remota de código en el contexto en el que se ejecuta la pila Treck TCP / IP.

Criterios de detección recomendados:

Para detectar un ataque en curso, se deben cumplir las siguientes condiciones si la encapsulación se puede desembalar:

  • La cola de recepción de UDP no debe estar vacía
  • Los paquetes UDP entrantes deben estar fragmentados
    • Marcar MF = 1 con cualquier desplazamiento, o
    • Bandera MF = 0 con desplazamiento distinto de cero
  • Los paquetes fragmentados deben tener un paquete IPv4 encapsulado (al ensamblar)
    protocolo = 0x4 (IPIP)
  • El paquete IPv4 encapsulado debe dividirse en 2 fragmentos de paquete.
  • El paquete IPv4 reensamblado (más interno) tiene una longitud de datos incorrecta almacenada en el encabezado IP.

La cuarta condición anterior es necesaria para activar la ruta del código que es vulnerable, ya que distribuye los datos que se copiarán en varios búferes en memoria. El paso de detección final es la fuente del desbordamiento de la memoria intermedia, por lo que puede ser suficiente activarlo.

Dependiendo de las limitaciones del dispositivo de inspección de red en cuestión, se podría usar una condición más flexible, aunque puede ser más propensa a falsos positivos.

Para detectar un ataque en curso si la encapsulación no se puede desempacar:

  • La cola de recepción de UDP no debe estar vacía
  • Los paquetes UDP entrantes deben estar fragmentados
    • Marcar MF = 1 con cualquier valor en el campo de compensación, o
    • Marcar MF = 0 con cualquier valor distinto de cero en el campo de compensación
  • El fragmento final tiene una longitud total del fragmento mayor que el campo de desplazamiento.

La condición final que se muestra arriba no es algo que deba verse en una red normal.

La fragmentación, cuando ocurre, es el resultado de que los datos desborden la MTU de un tipo de paquete determinado. Esto indica que el fragmento final no debería ser más grande que cualquier otro fragmento, y en la práctica probablemente sería más pequeño. La inversa, donde el fragmento final es de alguna manera más grande que los fragmentos anteriores, indica que la fragmentación no es el resultado del desbordamiento de MTU, sino algo más. En este caso, intención maliciosa.

Dado que es probable que los monitores de red de uso común tengan la capacidad de descomprimir la encapsulación, solo se proporciona ese conjunto de reglas.

Limitaciones o consideraciones especiales para la detección:

La pila Treck admite (al menos) dos niveles de túneles. Cada nivel de túnel puede ser IPv4-en-IPv4, IPv6-en-IPv4 o IPv4-en-IPv6. La lógica anterior es específica para IPv4-in-IPv4, caso de un solo nivel de tunelización. En casos de anidamiento más profundo, será necesario realizar una verificación recursiva o un desenvolvimiento completo de todas las capas de túnel.

Condiciones falsas positivas (firmas que detectan tráfico no malicioso):

Los falsos positivos deben ser mínimos si se utilizan todos los criterios de detección descritos anteriormente en el caso de que se pueda desembalar el túnel. En el caso de que no se pueda desempaquetar la tunelización, es poco probable que esto genere muchos falsos positivos en presencia de aplicaciones que cumplen con los estándares. La fragmentación como se ve aquí simplemente no es común.

Condiciones falsas negativas (firmas que no detectan vulnerabilidad / explotación):

Pueden producirse falsos negativos con niveles más profundos de anidamiento o anidamiento de IPv6.

Firma (s):

ipv4_tunneling.rules:

alert ip any any -> any any (msg:"IPv4 TUNNELING EXPLOIT (CVE‑2020‑11896)"; ip_proto:4; lua:tunnel_length_check.lua; sid:2020118961; rev:1;)

Lua script (tunnel_length_check.Lua) se puede encontrar en Apéndice A

El Apéndice A contiene los scripts de Lua necesarios para su uso con las firmas correspondientes de Suricata. Estos scripts también se encuentran en McAfee ATR GitHub.

dns_tcp_size.lua:

dns_size.lua:

dns_invalid_name.lua:

dns_heap_overflow_variant_1.lua:

dns_heap_overflow_variant_2.lua:

tunnel_length_check.lua:





Enlace a la noticia original