Protocolo de red RADIUS sometido a presentación debido a una falla basada en MD5 • The Register
Expertos en ciberseguridad de universidades y grandes empresas de tecnología han revelado una vulnerabilidad en un protocolo de red común cliente-servidor que permite a los espías eludir potencialmente la autenticación del usuario mediante ataques de intermediario (MITM).
Si la vulnerabilidad, calificada con 7,5 sobre 10 en la escala de gravedad CVSS y rastreada como CVE-2024-3596Si se explota (y no es tan fácil de hacer), los atacantes podrían, en teoría, acceder a dispositivos y servicios de red sin necesidad de obtener ninguna credencial. Esto requiere, a nivel práctico, MITMar el tráfico de red y realizar un rápido descifrado de hash.
Apodado Blast RADIUS por investigadores de Cloudflare, Microsoft, UC San Diego, CWI Amsterdam y BastionZero, probablemente puedas adivinar que afecta el protocolo de red RADIUS. Básicamente, la falla permite que alguien inicie sesión en un dispositivo cliente que depende de un servidor RADIUS remoto para realizar comprobaciones de autenticación, sin las credenciales correctas.
Si se pregunta cómo le afecta esto, el equipo señala que:
Sin embargo, continúan diciendo que no todo es fácil: «Dicho acceso al tráfico RADIUS puede ocurrir a través de diferentes mecanismos. Si bien se desaconseja el envío de RADIUS/UDP a través de Internet abierto, todavía ocurre en la práctica. Para el tráfico de red interna, el El atacante puede inicialmente comprometer parte de una red empresarial.
«Incluso si el tráfico RADIUS está confinado a una parte protegida de una red interna, una mala configuración o errores de enrutamiento pueden exponer involuntariamente este tráfico. Un atacante con acceso parcial a la red puede explotar DHCP u otros mecanismos para hacer que los dispositivos de las víctimas envíen tráfico desde una VPN dedicada «.
Abajo
El servicio de usuario de acceso telefónico de autenticación remota (RAYO) se creó en la década de 1990 y todavía se utiliza en las redes actuales. Se entiende que la falla Blast RADIUS afecta las implementaciones RADIUS que utilizan PAP, CHAP, MS-CHAPv2 y otros métodos de autenticación que no son EAP. IPSec, TLS, 802.1x, Eduroam y OpenRoaming se consideran seguros.
«El protocolo RADIUS es un componente fundamental de la mayoría de los sistemas de acceso a redes en todo el mundo. A partir del 9 de julio, casi todos estos sistemas ya no son seguros», afirmó Alan DeKok, director ejecutivo de InkBridge Networks.
«El descubrimiento del problema Blast RADIUS significa que los técnicos de red deben instalar actualizaciones de firmware en todos los dispositivos involucrados en la seguridad, identidad y autenticación de la red. Creemos que los proveedores de servicios de Internet, las empresas y la mayoría de los proveedores de identidad en la nube probablemente se verán afectados por esto. asunto.»
Blast RADIUS se basa en la forma en que los clientes y servidores RADIUS manejan las solicitudes de autenticación e implica realizar ataques de colisión contra la función hash MD5. Se ha demostrado que MD5 no funciona desde la década de 2000, aunque el equipo de Blast RADIUS dice que su abuso del algoritmo para explotar la vulnerabilidad del protocolo RADIUS «es más complejo que simplemente aplicar un antiguo ataque de colisión MD5». Dicen que su enfoque es mejor en términos de velocidad y escala.
Como hemos indicado, un ataque Blast RADIUS exitoso implica que alguien manipule el tráfico RADIUS cliente-servidor de una víctima para autenticarse en uno de los clientes del objetivo, como un enrutador, para causar más daño y caos, todo sin la necesidad de una contraseña. . válido. Dados los obstáculos involucrados, este tipo de ataque es muy útil para alguien que ya tiene presencia en una red y quiere profundizar más.
Cómo funciona Blast RADIUS
Esta será una explicación simplificada y, para aquellos que quieran la historia completa, una artículo técnico [PDF] está disponible en la vulnerabilidad sitio web de la marca.
El exploit Blast RADIUS comienza cuando un atacante intenta autenticarse en un cliente utilizando cualquier combinación de nombre de usuario y contraseña que desee; no importa, no tiene por qué funcionar.
Luego, el cliente se comunica con su servidor RADIUS a través de la red para realizar la autenticación real mediante un mensaje de solicitud de acceso. Si el servidor determina que las credenciales presentadas son correctas, envía de vuelta un paquete Acceso-Aceptar al cliente, indicando que se le debe permitir al usuario iniciar sesión. Por supuesto, en este caso el servidor no hará esto porque las credenciales son incorrectas; en cambio, devolverá un paquete de acceso denegado.
Para proteger de alguna manera las comunicaciones entre el cliente y el servidor contra la suplantación, tienen un secreto compartido. Cuando el cliente envía su solicitud de acceso al servidor, el cliente incluye un valor aleatorio de 16 bytes llamado Autenticador de solicitud, y cuando el servidor responde, el servidor incluye un valor de Autenticador de respuesta que se calcula utilizando el Autenticador de solicitud aleatorio del cliente, el secreto compartido y otros datos en la respuesta.
Luego, cuando el cliente recibe la respuesta del servidor, puede usar su valor de Autenticador de solicitud y el secreto y los datos compartidos en la respuesta para verificar que el servidor calculó y envió el Autenticador de respuesta correcto con su respuesta. Si alguien intenta hacerse pasar por el servidor y no conoce el secreto, no podrá enviar la respuesta correcta y el cliente podría ignorarlo. Idealmente, esto debería socavar los ataques MITM.
Volvamos al cliente que intenta autenticar a alguien que no conoce las credenciales correctas. Aquí es donde ocurre Blast RADIUS MITM.
El espía puede interceptar la solicitud de acceso del cliente y su valor aleatorio del autenticador de solicitud y manipular sus datos de modo que cuando el atacante envíe este mensaje alterado al servidor, el servidor responda con un mensaje de acceso denegado que el atacante pueda interceptar nuevamente y manipulación para convertir la respuesta del servidor en un mensaje de aceptación de acceso falsificado válido para el cliente.
Esto se hace utilizando un ataque de colisión de hash de prefijo elegido MD5 basado en Trabajo previo por Marc Stevens y otray explotar el hecho de que los datos basura cuidadosamente elaborados agregados a un atributo de configuración de proxy en el mensaje de solicitud de acceso al servidor por parte del atacante se incluyen en la respuesta de acceso denegado del servidor. Con un poco de baile criptográfico, es posible crear una respuesta de aceptación y acceso falsificada que sea válida para el valor del autenticador de solicitud del cliente, pero sin conocer el secreto compartido.
Esta doble interceptación y manipulación es necesaria porque el atacante no conoce el secreto, pero puede controlar el contenido de las cargas útiles del mensaje y así, mediante el ataque de colisión, los hashes para que lo que el atacante envía al cliente coincida con las expectativas del cliente. .
En lo que respecta al cliente, recibe una respuesta válida de Acceso-Aceptar de su servidor y concede acceso al atacante.
Según Cloudflare escribirNormalmente, el ataque debe realizarse en menos de cinco minutos para que funcione en la mayoría de los kits RADIUS en el campo, teniendo en cuenta la tolerancia de tiempo de espera predeterminada del cliente. La mayoría de los dispositivos toleran tiempos de espera de entre 30 y 60 segundos y, en teoría, los atacantes con buenos recursos podrían utilizar plataformas de computación en la nube para acelerar la explotación.
Estrategias de mitigación
El equipo detrás de la investigación nos dijo que los creadores de las pilas de autenticación RADIUS desarrollaron actualizaciones para evitar la explotación de esta debilidad a nivel de protocolo, que aparentemente se descubrió en febrero, a pesar de que la gente conoce los problemas de seguridad de los intercambios desde hace algún tiempo. pedido.
A juzgar por la siguiente nota del experto, debería buscar e instalar actualizaciones para sus implementaciones:
Nos dijeron que la mejor mitigación para las implementaciones RADIUS cliente-servidor es implementar RADIUS sobre TLS (RadSec) para proteger de los delincuentes los paquetes RADIUS en un flujo fuertemente cifrado. Consulte el sitio web de vulnerabilidad para obtener más detalles y mitigaciones. ®