Tiempo de ejecución de la RPC, segunda parte: el descubrimiento de una nueva vulnerabilidad
Resumen ejecutivo
El investigador de Akamai, Ben Barnea, ha descubierto una nueva vulnerabilidad importante en la biblioteca de tiempo de ejecución de la llamada a procedimiento remoto (RPC): CVE-2022-22019, con una puntuación base de 8,8.
La nueva vulnerabilidad aprovecha un desbordamiento de enteros que se había notificado previamente a Microsoft y para la que se había aplicado un parche en abril de 2022.
La nueva vulnerabilidad se ha solucionado en el “Patch Tuesday” de mayo de Microsoft.
Recomendamos que, junto con la lista de mitigaciones previa de Microsoft, se apliquen los parches de manera rápida y se aproveche la segmentación de la red para limitar la explotación de estas vulnerabilidades del movimiento lateral.
Introducción
El 12 de abril de 2022, Microsoft publicó parches para tres vulnerabilidades en la biblioteca de tiempo de ejecución de la llamada a procedimiento remoto (RPC) (rpcrt4.dll). A estas vulnerabilidades se les asignaron los siguientes CVE: CVE-2022-26809, CVE-2022-24492 y CVE-2022-24528. Los sistemas operativos a los que afecta son Windows 7, 8, 10 y 11, y Windows Servers 2008, 2012, 2019 y 2022.
Un atacante remoto no autenticado podría aprovechar estas vulnerabilidades para ejecutar código en el equipo vulnerable con los privilegios del servicio RPC. Esta capacidad se puede utilizar tanto para acceder a una red como para realizar movimientos laterales y por eso resulta tan atractiva para los atacantes y los operadores de ransomware. Microsoft, por su parte, ha definido estas vulnerabilidades como propensas a ser utilizadas. Debido a su gravedad (CVSS 9,8), decidimos analizar a fondo la biblioteca con el parche y escribir sobre nuestros hallazgos en una publicación previa del blog sobre este tema.
Descubrimos que las tres vulnerabilidades eran desbordamientos de enteros y el parche agregaba una verificación para comprobar si se había producido tal desbordamiento. Gracias a esta corrección, Microsoft pudo prevenir el aprovechamiento de estas vulnerabilidades. Sin embargo, durante nuestra investigación encontramos una vulnerabilidad adicional que utilizaba un desbordamiento de enteros de la misma variable que se había descubierto anteriormente y que no se había mitigado con la verificación que se había añadido.
Tras un proceso de divulgación con Microsoft, podemos perfilar la nueva vulnerabilidad de la RPC. Se descubrió con la publicación del “Patch Tuesday” de abril y ahora se ha solucionado en el parche de mayo. A la vulnerabilidad, que está presente tanto en el servidor como en el código de cliente, se le asignó un CVE único:
Comprender la vulnerabilidad encontrada
Para comprender la vulnerabilidad de la RPC que se acaba de descubrir, volvamos a analizar la vulnerabilidad a la que se aplicó un parche en abril. Según la conclusión a la que llegamos en nuestra anterior publicación del blog, existía un error de desbordamiento de enteros en el código de la biblioteca de tiempo de ejecución de la RPC que, cuando se forzaba, podía causar un desbordamiento del búfer del montón (una situación en la que los datos se copian en un búfer demasiado pequeño para rellenarlo). Esto, a su vez, permite que los datos se escriban fuera de los límites del búfer, en el montón. Cuando se utiliza correctamente, esto podría conllevar una ejecución remota del código.
Para corregir esta vulnerabilidad, se agregó una nueva llamada al ProcessReceivedPdu:
Esta llamada activa una función que comprueba si el parámetro de enteros se ha desbordado:
Al analizar OSF_SCALL::GetCoalescedBuffer (la función en la que se produce el desbordamiento del montón), también pudimos apreciar la verificación que se había agregado:
GetCoalescedBuffer es responsable de fusionar fragmentos de búfers que ProcessReceivedPdu ha puesto en cola. El desbordamiento de enteros original se produce cuando la longitud total de los fragmentos que se han puesto en cola se agrega a la longitud actual recibida del búfer; esta adición origina a un desbordamiento. Al invocar la función para comprobar el desbordamiento, Microsoft corrigió la vulnerabilidad original.
Sin embargo, el parche solo solucionaba parcialmente la vulnerabilidad. Durante nuestra investigación, descubrimos que justo antes de asignar la memoria para el nuevo búfer fusionado, el código agregaba otros 24 bytes al tamaño de la asignación (como ya hemos visto con la llamada a OSF_SCALL::TransGetBuffer). Estos 24 bytes son el tamaño de una estructura denominada rpcconn_request_hdr_t, que se utiliza como encabezado del búfer. Como el parche comprueba el desbordamiento de enteros antes de agregar el tamaño del encabezado, no tiene en cuenta este último, lo que puede causar el mismo desbordamiento de enteros que el parche trataba de mitigar.
La nueva vulnerabilidad (una en una función del cliente y otra en una función del servidor) ya se ha mitigado. El nuevo parche agrega otra llamada para verificar que la adición de estos 24 bytes no origina un desbordamiento.
Mitigación
Aplique las actualizaciones de seguridad de mayo que mitigan esta vulnerabilidad.
Bloquee el tráfico del puerto TCP 445 desde dispositivos situados fuera del perímetro empresarial.
Limite el movimiento lateral al habilitar el puerto TCP 445 de entrada solo en equipos en los que sea necesario (controladores de dominio, servidores de impresión, servidores de archivos, etc.).
Tiempos de divulgación
13 de abril de 2022: se envió un informe a Microsoft.
13 de abril de 2022: el estado cambió de Nuevo a En revisión/reproducción .
22 de abril de 2022: el estado cambió de En revisión/reproducción a Desarrollo.
10 de mayo de 2022: se publica el parche.
Conclusión
La aplicación de parches se considera una de las medidas de seguridad más básicas. Cuando se encuentra una vulnerabilidad, se publica un parche y se mitiga la vulnerabilidad. Aunque las vulnerabilidades de día cero reciban mucha más atención en los medios y en la comunidad en general, los profesionales sabemos que las vulnerabilidades más importantes provienen de situaciones como esta. Este es un gran ejemplo de por qué este proceso debe ser constante y repetitivo.
Nosotros, como comunidad, solemos centrarnos en el código original cuando buscamos errores, pero trabajar específicamente en actualizaciones y parches ofrece otro punto de vista que puede facilitar la colaboración a la hora de buscar soluciones y ofrecer, en general, una seguridad mejor.
Esta situación también reafirma en gran medida la importancia de los investigadores de seguridad independientes. Nos gustaría animar a otros investigadores de seguridad a seguir analizando este y otros parches en busca de vulnerabilidades.
¿Tiene alguna pregunta o desea hablar sobre lo que hemos encontrado? Diríjase a nosotros en Twitter @Akamai_Research , nos encantaría conocer su opinión al respecto.
