advanced-threat-research/cve-2020-16898CVE-2020-16898 (Bad Neighbor) Lógica de detección y regla de vulnerabilidad TCP/IP de Microsoft Windows
El 13 de octubre, Microsoft anunció una vulnerabilidad excepcionalmente crítica en la pila IPv6 de Windows, que permite a un atacante enviar paquetes maliciosamente manipulados para potencialmente ejecutar código arbitrario en un sistema remoto. La prueba de concepto compartida con los miembros de MAPP es extremadamente simple y perfectamente confiable. Produce un BSOD (Pantalla Azul de la Muerte) inmediato, pero además indica la probabilidad de explotación para aquellos que puedan eludir las mitigaciones de Windows 10 y Windows Server 2019. Los efectos de un exploit que permita la ejecución remota de código serían generalizados y de gran impacto, ya que este es el tipo de error que podría volverse gusano. Para facilitar la referencia, nombramos la vulnerabilidad "Bad Neighbor" porque se encuentra dentro de un "Protocolo" de Descubrimiento de Vecinos ICMPv6, usando el tipo de Anuncio de Enrutador.
Este documento ha sido preparado por McAfee Advanced Threat Research. Su objetivo es proporcionar información valiosa para administradores de redes y personal de seguridad que busquen comprender mejor esta vulnerabilidad y defenderse contra la explotación. La firma aquí producida debe ser considerada y probada exhaustivamente en entornos de prueba antes de ser utilizada en producción y puede beneficiarse de un ajuste específico para el despliegue objetivo.
La firma de Suricata para esta vulnerabilidad se encuentra en cve-2020-16898.rules y contiene la siguiente lógica:
alert icmp any any -> any any (msg:"Posible Explotación de CVE-2020-16898"; lua:cve-2020-16898.lua; sid:202016898; rev:1;)
El script Lua correspondiente se puede encontrar en cve-2020-16898.lua. Contiene la lógica necesaria para analizar correctamente la capa ICMPv6 e identificar una posible explotación de Bad Neighbor, de la siguiente manera:
Una vez que localizamos el inicio de la capa ICMPv6, probamos el primer byte de la capa para asegurarnos de que sea un paquete ICMPv6 de Anuncio de Enrutador (Tipo = 134); si no lo es, salimos.
Dado que las primitivas de Suricata no se han actualizado para analizar las opciones ICMPv6, simplemente saltamos al byte 17 de la capa ICMPv6, ya que ahí es donde deberían comenzar las Opciones, si están presentes (los primeros 16 bytes son campos de longitud fija, según RFC 4443). A partir de ahí, recorremos cada Opción hasta que se acaben los bytes del paquete. Para cada Opción, solo nos interesan los dos primeros bytes: los campos Tipo y Longitud de la Opción, respectivamente. Si bien ignoramos todas las Opciones que no sean RDNSS, para el Tipo de Opción = 25 (RDNSS), verificamos si la Longitud (segundo byte de la Opción) es un número par. Si lo es, lo marcamos. Si no, continuamos. Dado que la Longitud se cuenta en incrementos de 8 bytes, multiplicamos la Longitud por 8 y saltamos esa cantidad de bytes para llegar al inicio de la siguiente Opción (restando 1 para tener en cuenta el byte de longitud que ya hemos consumido).
Con esta regla, también verificamos que la Longitud sea al menos 3, ya que RFC 8106 lo requiere, pero en última instancia esta verificación puede ser superflua, ya que solo nos interesa si la Longitud es par o no.
