Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

El Centro de Coordinación CERT (Computer Emergency Response Team) emitió hace pocos días una alerta sobre una serie de vulnerabilidades en implementaciones de protocolos de aplicaciones que utilizan UDP como transporte. El CERT menciona que estas vulnerabilidades pueden causar denegación de servicio al generar bucles de paquetes entre hosts, agotando el ancho de banda disponible, bloqueando servicios de red y facilitando ataques DDoS. (por ejemplo, creando una carga elevada y excediendo los límites de la tasa de solicitudes).

Se menciona que las vulnerabilidades se originan en la falta de seguridad del protocolo UDP contra la suplantación de direcciones. En ausencia de protección contra este tipo de suplantación en los enrutadores de tránsito, un atacante puede especificar la dirección IP de un servidor arbitrario en un paquete UDP y enviarlo a otro servidor. Este segundo servidor devolverá una respuesta a la dirección falsa proporcionada.

Los investigadores de seguridad han identificado que ciertas implementaciones del protocolo UDP en aplicaciones pueden activarse para crear un bucle de red de paquetes aparentemente interminables…

Por ejemplo, si dos servidores de aplicaciones tienen una implementación vulnerable de dicho protocolo, un atacante puede iniciar una comunicación con el primer servidor, falsificando la dirección de red del segundo servidor (víctima). En muchos casos, el primer servidor responderá con un mensaje de error a la víctima, lo que también desencadenará un comportamiento similar de otro mensaje de error al primer servidor. Se ha demostrado que este comportamiento agota los recursos y puede hacer que los servicios dejen de responder o sean inestables.

El método de ataque se basa en crear un bucle de intercambio de paquetes entre servidores que utilizan implementaciones vulnerables de protocolos. Por ejemplo, cuando el servidor de destino responde a un paquete entrante con un código de error, el servidor cuya dirección fue suplantada por el atacante también enviará su respuesta, lo que generará una respuesta adicional del servidor original y así sucesivamente, provocando una situación de bucle o «ping-pong» sin fin entre los servidores.

Los protocolos vulnerables incluyen a las implementaciones DNS, NTP, TFTP, Echo, Chargen y QOTD, además de que se ha confirmado la presencia de la vulnerabilidad CVE-2024-2169 en productos que son Cisco, asi como también de Microsoft, Broadcom, entre otros.

Un escaneo global de direcciones de Internet reveló que hay al menos 23 mil servidores TFTP vulnerables, 63 mil servidores DNS, 89 mil servidores NTP, 56 mil servicios Echo/RFC862, 22 mil servicios Chargen/RFC864 y 21 mil servicios QOTD/RFC865. En el caso de los servidores NTP, la vulnerabilidad sin parchear se atribuye al uso de versiones muy antiguas de ntpd anteriores a 2010.

Los servicios Echo, Chargen y QOTD son intrínsecamente vulnerables debido a su arquitectura y sé menciona que la situación con los servidores TFTP y DNS requiere investigación con sus administradores. Los servidores atftpd y tftpd no se ven afectados debido a su uso de un número de puerto de red de origen aleatorio al enviar una respuesta. Se menciona que entre los servidores DNS vulnerables se encuentra dproxy-nexgen. En los productos de Microsoft, el problema afecta a WDS (Servicios de implementación de Windows), mientras que en los productos de Cisco, el problema afecta a los enrutadores de las series 2800 y 2970.

Como método para «solucionar el problema» se recomienda habilitar uRPF en el firewall, limitar el acceso a servicios UDP innecesarios y configurar la limitación de la intensidad del tráfico como soluciones alternativas para bloquear estas vulnerabilidades.

Como tal este tipo de ataques no son nuevos, ya que por mencionar un ejemplo, está la vulnerabilidad que se detectó en el servidor de sincronización horaria ntpd, una variante del ataque fue abordada en 2009 (CVE-2009-3563) en las versiones 4.2.4p8 y 4.2.5.  Este ataque implicaba enviar un paquete NTP con una dirección falsificada y el flag MODE_PRIVATE activado. Cuando el servidor objetivo procesaba este paquete, devolvía una respuesta indicando que no podía usar el modo privado, pero dejaba activado el flag MODE_PRIVATE en la respuesta.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.