Colapso en QUIC: vulnerabilidad de DoS en servidores Windows que ejecutan SMB a través de QUIC
Resumen ejecutivo
El investigador de Akamai, Ben Barnea, ha descubierto una nueva vulnerabilidad importante en Microsoft Windows Server 2022 a la que se asignó CVE-2023-24898 con una puntuación base de 7,5.
La vulnerabilidad radica en una comprobación que falta en una asignación de búfer en el controlador srvnet.sys.
Esta vulnerabilidad puede provocar ataques remotos de denegación de servicio (DoS) en equipos con Windows Server 2022. Esta vulnerabilidad puede activarla un atacante no autenticado a través de Internet.
Solo son vulnerables los servidores que utilizan SMB a través de QUIC, una función relativamente nueva. Para habilitar esta función, el servidor debe ser Windows Server 2022 Azure Edition.
Las vulnerabilidades se divulgaron de forma responsable a Microsoft y se solucionaron en el Patch Tuesday de mayo de 2023.
Proporcionamos una consulta de Insight para que los usuarios de Guardicore Segmentation de Akamai puedan detectar servidores potencialmente vulnerables en sus redes.
Introducción
QUIC Es un protocolo de capa de transporte relativamente nuevo que fue diseñado originalmente por Google, pero tiene varias implementaciones. La finalidad de QUIC es proporcionar una conexión más fiable y segura, al tiempo que se superan los problemas comunes de Internet, como la latencia y la pérdida de paquetes. Se transmite a través de UDP.
La implementación de QUIC que realiza Microsoft se denomina MsQuic. Windows también incorpora QUIC, utilizándolo como capa de transporte para el protocolo SMB (una función denominada SMB a través de QUIC) y con HTTP/3 en IIS. SMB a través de QUIC solo está disponible en Windows Server 2022 Azure Edition, mientras que HTTP/3 está disponible para todas las implementaciones de IIS que se ejecutan en Windows Server 2022.
La vulnerabilidad que se analiza en esta entrada de blog se encuentra en el controlador que implementa la capa de transporte de SMB, srvnet.sys.
La vulnerabilidad
Para mantener el estado de una conexión, QUIC utiliza un identificador de conexión, que identifica de forma única una conexión entre el cliente y el servidor. Un cliente puede crear varias conexiones simultáneas. También se multiplexa una conexión QUIC; es decir, un cliente y un servidor pueden intercambiar datos mediante varios flujos de forma simultánea a través de la misma conexión.
El código de SMB a través de QUIC se implementa en srvnet.sys. Cuando el servidor recibe nuevos datos en un flujo, se llama a la función SrvNetQuicServerReceiveEvent . La finalidad de la función es leer un mensaje SMB completo enviado por el cliente. Después de hacerlo correctamente, transfiere el mensaje a la lista de mensajes SMB para su procesamiento posterior.
Para leer un mensaje SMB, el código primero intenta leer el tamaño del mensaje SMB, representado por un entero de cuatro bytes. Si lo hace correctamente, comprueba que el tamaño no sea mayor que el tamaño máximo permitido para una asignación. Si se supera la comprobación, el código asigna un búfer con este tamaño e intenta leer los bytes restantes del paquete en el búfer recién asignado. Si termina de leer el mensaje SMB completo, indica a la capa SMB que se ha recibido un nuevo mensaje SMB.
La estructura de un mensaje SMB se ilustra en la Figura 1.
Fig. 1: Estructura de mensaje SMB en srvnet.sys
La vulnerabilidad se produce si se reciben menos de cuatro bytes de tamaño de mensaje SMB (Figura 2). En este caso, el código guardará los X bytes recibidos y también definirá PendingMessageSize en 4 menos X (donde X es el número de bytes recibidos para el tamaño del mensaje). La siguiente vez que se reciba un paquete, leerá los 4 - X bytes restantes necesarios para el tamaño del mensaje SMB.
Fig. 2: Un paquete malicioso tendría menos de cuatro bytes de tamaño de mensaje
Una vez que el código ha terminado de leer el tamaño del mensaje, asigna inmediatamente un mensaje SMB sin realizar la verificación de este tamaño en relación con el tamaño máximo permitido. De ese modo, al enviar el tamaño del mensaje SMB en dos paquetes en lugar de uno, un atacante puede omitir la verificación de tamaño máximo permitido y solicitar una asignación excepcionalmente grande.
Ataque
Para convertir este error en una vulnerabilidad de DoS, sería necesario enviar continuamente paquetes que activen el problema descrito.
Pero incluso con la capacidad de omitir el tamaño máximo permitido, existen aún dos restricciones:
1. SrvNetAllocateBuffer Tiene un límite estricto de 16 MB para asignaciones.
2. El número de conexiones simultáneas no autenticadas permitidas está limitado según la RAM disponible en el servidor. Esta restricción limita el ataque a servidores con hasta 32 GB de RAM. (En la siguiente sección, analizaremos cómo se podría omitir esta limitación).
Para aprovechar esta vulnerabilidad, primero intentamos crear varias conexiones y enviar dos paquetes cada vez para que el servidor asigne 16 MB. La realización de esta acción, de forma repetida causa el agotamiento de la memoria. Como esta vulnerabilidad se encuentra en un controlador y se ejecuta en modo kernel, el sistema completo se vuelve inestable y deja de responder.
¿Un ataque optimizado?
Este ataque requiere que se realice el envío de muchos paquetes. Creemos que mediante la explotación de las funciones de QUIC es posible reducir el número de paquetes necesarios.
Si bien QUIC permite varios flujos a través de una sola conexión, también hace posible limitar este número mediante la propiedad initial_max_streams_bidi . SMB a través de QUIC limita el número de flujos simultáneos para una conexión a uno.
Aunque no es posible mejorar el ataque mediante el uso de varios flujos simultáneos , podemos intentar aprovechar la vulnerabilidad de una forma diferente. En lugar de crear varios flujos simultáneos, se puede crear un paquete QUIC con varios marcos, de modo que la siguiente secuencia se produzca en serie y de forma repetida:
1. Crear un flujo
2. Activar la asignación de 16 MB enviando dos marcos de datos (DATA frames)
3. Cerrar el flujo
De esta forma, también es posible omitir el límite de conexiones no autenticadas. Lo dejaremos como un desafío para el lector.
Detección y mitigación
Para buscar un servidor con SMB a través de QUIC en ejecución, los usuarios de Guardicore Segmentation de Akamai pueden ejecutar la siguiente consulta sencilla de Insight:
select * from registry where
path="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableSMBQUIC" and data=1
Le recomendamos que aplique parches a su equipo Windows Server, ya que no existe ninguna otra mitigación ni solución alternativa disponible para esta vulnerabilidad, excepto desactivar la función SMB a través de QUIC.
Resumen
QUIC es un protocolo de red relativamente nuevo que garantiza un mejor rendimiento y una menor latencia. Evidentemente, ya se ha adoptado e incorporado en dos protocolos destacados: IIS (para HTTP/3) y SMB.
Creemos que QUIC es una nueva superficie de ataque interesante en Windows y en general. Además del problema que se describe, también se ha corregido otra vulnerabilidad, CVE-2023-23392en HTTP/3.
Animamos a otros investigadores a que estudien los diferentes componentes que usan MsQuic, así como el propio MsQuic.
