Cómo Windows 10 Explore la vulnerabilidad crítica de DHCP detecta dos errores de seguridad más

Imagen: Unsplash

Como se describió en un artículo anterior sobre CVE-2019-0726 , a veces la búsqueda de detalles sobre una vulnerabilidad ya conocida conduce al descubrimiento de una nueva vulnerabilidad. Y en algunos casos hay más de una de esas nuevas vulnerabilidades.

En el artículo se consideraron dos funciones de la biblioteca dhcpcore.dll: el UpdateDomainSearchOption mencionado casualmente y el análisis más detallado del DecodeDomainSearchListData que llama. Como siempre sucede cuando se buscan vulnerabilidades, incluso si las conclusiones importantes al final se reducen a una o dos funciones, en el proceso de análisis debe analizar una cantidad de código mucho mayor. Y a veces el ojo se aferra a cosas insignificantes que no están relacionadas con la tarea actual, pero que pueden tener un significado independiente o ser útiles más adelante. Supongamos que en este momento no hay tiempo para prestarles atención, pero tales pequeñeces se posponen en la subcorteza y, si después de un cierto período de tiempo existe la oportunidad de volver a ellas y comprobar sus conjeturas, vuelven a aparecer en la conciencia.

Y así sucedió esta vez. Al estudiar la función DhcpExtractFullOptions, que es responsable de procesar todas las opciones especificadas en la respuesta DHCP del servidor, en particular, llamando a UpdateDomainSearchOption, dos conjuntos en la pila de 256 elementos cada uno llaman la atención de inmediato:



Al mismo tiempo, la presencia de cualquier verificación que restrinja los valores de los iteradores de estas matrices no es notable. Como en ese momento estábamos analizando otra vulnerabilidad, esta información no era relevante. Por lo tanto, solo quedaba recordar este lugar en el código para volver a él más tarde.

Análisis

Pasan un par de semanas, y nuevamente recordamos la función DhcpExtractFullOptions que había llamado la atención anteriormente. Lo buscamos en el desensamblador, peinamos las piezas de código previamente enmarcadas de manera incompleta y tratamos de entender por qué estamos usando dos matrices estáticas que nos intrigaron.

Al comienzo de la ejecución de la función, las matrices y sus iteradores se ponen a cero:



La función analiza todas las opciones del paquete recibido del servidor DHCP, recopila información de ellas y luego la procesa. Además, de acuerdo con los resultados del análisis, ella también escribe el evento correspondiente al servicio ETW (Event Tracing for Windows). Es en el registro de eventos donde participan las memorias intermedias que nos interesan. Junto con muchos otros datos, se transfieren al procedimiento EtwEventWriteTransfer. El trabajo de preparar todos los datos para el registro es bastante voluminoso y no importa mucho la vulnerabilidad que estamos considerando, por lo que podemos prescindir de las ilustraciones.

Es más importante determinar cómo se llenan estos búferes. El llenado se produce en el bucle de análisis de opciones. Primero, se llama a una función con el nombre parseado ParseDhcpv4Option para la opción actual recibida para el procesamiento, que llena los campos del objeto dhcp_pointers en función de los datos recibidos o toma nota de una opción desconocida cuando encuentra un identificador de opción con un valor para el que no hay un controlador.



Al regresar de ParseDhcpv4Option, el valor del identificador de la etiqueta de opción actual se escribe en el siguiente elemento de la matriz all_tags, la primera de las matrices que nos interesan. Si la función se encontró con una opción desconocida y, en consecuencia, no estableció el indicador is_known_option, entonces el valor del identificador también se escribe en el siguiente elemento de la segunda matriz: unknown_tags. Naturalmente, los nombres significativos de las variables en este artículo ya se obtuvieron analizando el código.

Por lo tanto, la matriz all_tags almacena etiquetas de todas las opciones del mensaje recibido, y la matriz unknown_tags almacena etiquetas solo para opciones desconocidas para el analizador. Al mismo tiempo, la comprobación de los valores de los índices de estas matrices está completamente ausente. En consecuencia, los valores de tales índices pueden exceder 256 y llevar a la escritura más allá de los límites asignados en la pila para las matrices de memoria. Para sobrellenar la primera matriz, es suficiente enviar un paquete con un número de opciones superior a 256 desde el servidor DHCP. Lo mismo es cierto para la segunda matriz, con la única diferencia de que las opciones que el cliente no puede procesar deben enviarse.

Operación

Intentemos ahora usar un ejemplo práctico para asegurarnos de que nuestras conclusiones sean correctas. Para empezar, prestamos atención al hecho de que las etiquetas de opciones ocupan un byte, mientras que los elementos de la matriz son de tipo int, es decir, son de cuatro bytes. Por lo tanto, tenemos un desbordamiento en el que controlamos cada cuarto byte, y el resto se restablece a cero cuando se sobrescribe.



Para probar nuestra suposición, la forma más fácil es sobrescribir la cookie de seguridad en la función en cuestión, lo que generará una excepción relacionada con la verificación de seguridad. Simulemos una situación en la que el servidor DHCP envía una cantidad suficiente de opciones para reescribir. Deje que sean 0x1a0 (416) opciones con identificador 0xaa y tamaño cero. Por lo tanto, cada opción ocupa dos bytes, y el tamaño total del paquete con todos los encabezados es de 1100-1200 bytes. Este valor está dentro de la MTU para Ethernet, por lo tanto, hay razones para creer que el mensaje no se fragmentará, lo que nos permitirá evitar posibles efectos adversos.

Enviamos el paquete formado de la manera descrita en respuesta a una solicitud del cliente DHCP y detectamos la excepción en el proceso svchost.exe correspondiente en la máquina cliente:



Como puede ver en el seguimiento de la pila, tanto la cookie de la pila como la dirección de retorno de la función fueron reescritas por los identificadores de las opciones de nuestro paquete.

Por supuesto, crear un exploit funcional para este error requerirá mucho esfuerzo por parte del atacante. En los sistemas modernos, el desbordamiento del búfer en la pila es una vulnerabilidad bastante compleja y laboriosa debido a todos los mecanismos de defensa existentes. Por otro lado, uno no debe olvidar que todos estos mecanismos protegen contra la reescritura de la dirección de retorno y los manejadores de excepciones, o prohíben la ejecución de código en regiones de memoria no destinadas a esto, o interfieren con la predicción de direcciones. Por ejemplo, no pueden ayudar de ninguna manera a sobrescribir los almacenados en la pila entre el búfer desbordado y la dirección de retorno de las variables locales. Y la función DhcpExtractFullOptions en cuestión contiene varias variables potencialmente peligrosas en este intervalo.

Nuevamente, escribimos a Microsoft sobre el error detectado. Después de una breve correspondencia y un análisis de la aplicación, que tardó aproximadamente una semana, obtenemos la respuesta de que se está preparando un identificador CVE para la vulnerabilidad descrita, se planea lanzar una solución en marzo y alguien informó anteriormente sobre la vulnerabilidad ya disponible en Microsoft. El hecho, en términos generales, no es sorprendente, porque el error yace literalmente en la superficie, y los buffers que no contienen verificaciones de límites de índices siempre atraen la atención primero y a menudo pueden detectarse mediante herramientas de análisis automático.

En marzo, como se anunció, se lanzó una actualización para corregir el error descrito, que recibió el identificador CVE-2019-0697 . El investigador previamente informado resultó ser Mitch Adair, el mismo empleado de Microsoft que descubrió la vulnerabilidad DHCP CVE-2019-0547 corregida en enero.

Publicado por Mikhail Tsvetkov, Especialista en Análisis de Aplicaciones de Tecnologías Positivas.