La perspectiva de Akamai sobre el Patch Tuesday de abril de 2023
No deje que nadie le engañe, el verdadero significado de PT es Patch Tuesday (martes de parches). Como hacemos cada mes, en el grupo de inteligencia sobre seguridad de Akamai, hemos querido analizar las vulnerabilidades más interesantes para las que se han aplicado parches.
Este mes se han reparado aproximadamente 100 vulnerabilidades y exposiciones comunes (CVE), 7 de ellas críticas y 2 con una puntuación del CVSS alta de 9,8. Se afirma que una de las CVE reparadas también se ha puesto en circulación, calificándola como vulnerabilidad de día cero reparada.
En este informe, evaluaremos la importancia real de las vulnerabilidades y lo comunes que son las aplicaciones y los servicios afectados y proporcionaremos una perspectiva realista sobre los errores que se han corregido. Esté atento a esta información los días posteriores a cada Patch Tuesday. También puede ver una rápida descripción general en tiempo real el día del parche en nuestra cuenta de Twitter.
Este es un informe actualizado y añadiremos más información a medida que progrese nuestra investigación. Esté atento.
En este informe, nos centramos en las áreas en las que se han aplicado parches a los errores:
Vulnerabilidades explotadas libremente
Sistema de archivos de registro común: CVE-2023-28252
Una vulnerabilidad de elevación local de privilegios en el controlador del sistema de archivos de registro común (CLFS) de Windows, según Kaspersky, se utilizó como día cero en los ataques de ransomware de Nokoyawa. También se explica la causa raíz y el efecto de la vulnerabilidad, que es una escritura prohibida que finalmente conduce a una primitiva de lectura/escritura de memoria libre del núcleo. CLFS ha estado disponible en Windows desde Windows Server 2003 R2, por lo que esta vulnerabilidad tiene un gran impacto. Le recomendamos que aplique parches a sus sistemas lo antes posible.
Microsoft Message Queuing
Había tres vulnerabilidades en el servicio Microsoft Message Queuing (MSMQ): una vulnerabilidad crítica de ejecución remota de código (RCE) 9,8 y dos vulnerabilidades de denegación de servicio. Las tres vulnerabilidades fueron encontradas por Haifei Li de Check Point Research (CPR), que publicó un buen informe sobre las vulnerabilidades.
El servicio MSMQ es una característica opcional en Windows que se utiliza para entregar mensajes entre diferentes aplicaciones. A pesar de ser opcional, muchas aplicaciones empresariales para Windows, como Microsoft Exchange Server, lo utilizan en segundo plano. En nuestras observaciones, encontramos el servicio instalado en casi el 50 % de los entornos, normalmente en más de un equipo.
Dado que la vulnerabilidad de RCE se activa fácilmente (solo requiere un único paquete según CPR), recomendamos encarecidamente aplicar parches lo antes posible. Si la aplicación de parches no es posible, debido a la continuidad operativa o por cualquier otro motivo, recomendamos restringir el acceso al servicio, como mínimo, mediante políticas de segmentación de red. Dado que el servicio MSMQ es accesible a través del puerto 1801, pero no debería haber tantos clientes con acceso a él (ya que la propia aplicación empresarial lo utiliza principalmente), recomendamos restringir el acceso arbitrario a la red a ese puerto y servicio. Intente segmentarlo mediante políticas de lista de permiso, permitiendo el acceso solo a los equipos que realmente lo necesiten.
Número de CVE |
Efecto |
Acceso requerido |
|---|---|---|
Denegación de servicio |
Red |
|
Ejecución remota de código |
Red |
Multidifusión general pragmática de Windows
La multidifusión general pragmática (PGM) es un protocolo diseñado para distribuir paquetes entre varios miembros de la red de forma fiable. En Windows, la implementación de este protocolo se denomina multidifusión fiable. Este Patch Tuesday ha corregido una vulnerabilidad crítica de RCE, CVE-2023-28250, con una puntuación CVSS de 9,8.
En nuestras observaciones, observamos que el 40 % de los entornos tenían activada la multidifusión fiable. Aunque en la mayoría de los centros de datos solo unos pocos equipos tenían esta capacidad habilitada, observamos entornos en los que varios servidores ejecutaban PGM.
Desde Windows Server 2003, PGM se basa en sockets de Windows. En el espacio de usuario, se implementa en una biblioteca denominada wshrm.dll (Windows Sockets Helper DLL para PGM, donde rm significa multidifusión remota). En el espacio del núcleo, PGM se implementa a través del controlador rmcast.sys.
El parche ha añadido la verificación de tamaño en una llamada a memset, en la función DecodeParityPackets. Antes de la corrección, un atacante remoto podía enviar un paquete especialmente diseñado para provocar un desbordamiento de enteros, lo que posteriormente llevaría a la ejecución de código. Aunque no se ha mencionado explícitamente, la vulnerabilidad puede tener una puntuación CVSS alta debido al hecho de que la ejecución de código se logra en modo de núcleo, concretamente con los privilegios más altos posibles.
Según Microsoft (en un boletín de seguridad anterior sobre una CVE diferente), "Para que un sistema sea vulnerable, Message Queuing (MSMQ) debe estar instalado y el protocolo Multidifusión general pragmática (PGM) de Windows habilitado específicamente" (Figura 1). Es decir, PGM depende de Message Queuing para su funcionamiento y, por lo tanto, las recomendaciones de la sección anterior también se aplican aquí. Esto está en consonancia con las mitigaciones y preguntas frecuentes que Microsoft ha publicado para la CVE de este mes.
Fig. 1: Activación de MSMQ y multidifusión a través del cuadro de diálogo Características de Windows
Número de CVE |
Efecto |
Acceso requerido |
|---|---|---|
Ejecución remota de código |
Red |
Servicio de servidor DHCP
El protocolo DHCP se utiliza para gestionar el tráfico y las direcciones de red (asignación de direcciones IP, configuración de puerta de enlace predeterminada y servidor DNS, etc.). Windows tiene su propia implementación de un servidor DHCP, que se puede instalar como una función adicional en instalaciones de Windows Server. En nuestras observaciones, hemos visto el servicio de servidor DHCP en aproximadamente el 40 % de los entornos.
Esta vez existe una vulnerabilidad crítica en el servidor DHCP que se puede utilizar para lograr el RCE. Dado que DHCP es crucial para el funcionamiento de toda la LAN, puede ser difícil mitigar el riesgo de la vulnerabilidad mediante segmentación (ya que, técnicamente, el servicio debe estar abierto a toda la red). Sin embargo, es posible utilizar la microsegmentación para permitir el acceso de red al servicio DHCP desde un pequeño conjunto de procesos de origen. Si dispone de supervisión de red con visibilidad de procesos de origen, es posible asignar todos los clientes DHCP únicos de la red y limitar el acceso solo a esos procesos. De lo contrario (e independientemente), debe aplicar parches a los servidores.
En nuestras observaciones, solo hemos visto que 14 procesos únicos acceden al servidor DHCP (y uno de ellos era nmap, así que técnicamente son 13).
Número de CVE |
Efecto |
Acceso requerido |
|---|---|---|
Ejecución remota de código |
Red local |
Netlogon Remote Protocol
La Netlogon Remote Protocol es el protocolo que se utiliza para la autenticación de usuarios y equipos en entornos de dominio de Windows. También se utiliza para la sincronización entre controladores de dominio. Como tal, es inevitable en las redes de dominio de Windows, por lo que CVE-2023-28268 podría afectar a la mayoría de los entornos.
Parece similar a una vulnerabilidad anterior que cubrimos en el asesoramiento de noviembre de 2022:CVE-2022-38023. Ambas vulnerabilidades giran en torno a un atacante que utiliza un ataque de máquina intermediaria (MITM) y utiliza la firma de RPC en lugar del sellado de RPC.
Para aplicar el sellado RPC, Microsoft introdujo la clave de registro RequireSeal. Según los avisos anteriores, debería ser imposible deshabilitar el registro y solo puede ser en los modos de compatibilidad o cumplimiento.
Número de CVE |
Efecto |
Acceso requerido |
|---|---|---|
Escalada de privilegios |
Red, MITM |
Llamada a procedimiento remoto de Windows
Este mes hay tres vulnerabilidades relacionadas con las llamadas a procedimientos remotos (RPC; incluimos la CVE de RPCSS). La vulnerabilidad de RCE se encuentra en el tiempo de ejecución de RPC, que proporciona la API y la implementación del protocolo RPC. Se implementa en el archivo DLL rpcrt4.dll. El Servicio de llamada a procedimiento remoto (RPCSS) en el otro extremo es un servidor RPC por sí mismo y es responsable de DCOM : es decir, de hacer que las clases y objetos COM sean accesibles a través de la red.
Dado que rpcrt4.dll y rpcss.dll son cruciales para el funcionamiento normal de Windows (por no mencionar que rpcrt4.dll se carga en todos los procesos que utilizan RPC), podría ser imposible mitigar el riesgo de una forma que no sea aplicar parches.
Número de CVE |
Efecto |
Acceso requerido |
|---|---|---|
Ejecución remota de código |
Red, autenticación obligatoria |
|
Escalada de privilegios |
||
Divulgación de información |
Servicios tratados anteriormente
Muchas CVE en el Patch Tuesday de este mes son para sistemas que ya hemos cubierto en el pasado. Si tiene interés en nuestro análisis o nuestras recomendaciones generales sobre esos servicios, le animamos a que consulte nuestras publicaciones anteriores.
Servicio |
Número de CVE |
Efecto |
Acceso requerido |
|---|---|---|---|
Ejecución remota de código |
Acceso a la red; requiere ganar una condición de carrera |
||
Ejecución remota de código |
Red |
||
Suplantación |
Usuario autenticado con permisos de creación de páginas |
||
Suplantación |
Ataque XSS; el atacante debe autenticarse |
||
Ejecución remota de código |
Autenticación obligatoria |
||
Divulgación de información |
Este resumen ofrece una descripción general de nuestros conocimientos y recomendaciones actuales, dada la información disponible. Nuestra revisión se lleva a cabo de forma continua y cualquier información aquí contenida está sujeta a cambios. También puede visitar nuestra cuenta de Twitter para obtener actualizaciones en tiempo real.
