Saltar al contenido principal

Robustecimiento de RADIUS contra ataques de colisión MD5 (BlastRADIUS)

Mitigue los ataques BlastRADIUS de CVE-2024-3596. Imponga RADIUS Message-Authenticator, parchee FreeRADIUS y Cisco ISE, y migre a 802.1X EAP-TLS.

Por Iain JewittPublicado Actualizado
📖 8 min de lectura1,510 palabras2 ejemplos prácticos2 preguntas de práctica5 definiciones clave

Video overview

Escuchar esta guía

Ver transcripción del podcast
Bienvenido al boletín técnico de Purple. Soy su anfitrión, estratega sénior de contenido técnico en Purple. Hoy abordamos un problema crítico y urgente para cualquier organización que cuente con WiFi de nivel empresarial: una nueva vulnerabilidad práctica en un protocolo de hace 30 años que podría permitir a los atacantes franquear directamente su puerta de acceso digital. Estamos hablando del protocolo RADIUS y del ataque de colisión MD5 conocido como Blast-RADIUS. Para nuestra audiencia de responsables de TI, arquitectos de red y directores de tecnología (CTO) en los sectores de hostelería, comercio minorista y grandes recintos públicos, este no es un problema meramente teórico. Es una amenaza directa para la integridad de su red, la seguridad de sus datos y su estado de cumplimiento. En los próximos diez minutos explicaremos en qué consiste la vulnerabilidad, cómo funciona y, lo que es más importante, ofreceremos una hoja de ruta clara y práctica para mitigarla. Tanto si es responsable de un hotel de 200 habitaciones como de una cadena minorista nacional o de un estadio con capacidad para 60 000 espectadores, este boletín es directamente relevante para las decisiones que debe tomar este trimestre. Comencemos con un poco de contexto. RADIUS (Remote Authentication Dial-In User Service) se diseñó en 1991, en la época de la conexión a internet por marcación telefónica. Es un protocolo cliente - servidor que gestiona la autenticación, la autorización y la contabilidad para el acceso a la red. Cuando un miembro del personal o un dispositivo se conecta a su WiFi empresarial, el punto de acceso actúa como cliente RADIUS y envía una solicitud de autenticación a un servidor RADIUS central. El servidor comprueba las credenciales y responde con un Access-Accept o un Access-Reject. Este intercambio ha sido la columna vertebral de la seguridad de las redes empresariales durante más de tres décadas. El problema es que RADIUS se diseñó antes de que existieran los estándares criptográficos modernos. El protocolo utiliza el algoritmo de hash MD5 para proporcionar una comprobación de integridad básica en las respuestas del servidor - un campo llamado Response Authenticator. Se demostró por primera vez que MD5 estaba criptográficamente roto en 2004. Sin embargo, estamos en 2024 y RADIUS sigue dependiendo de él. El sector sabía que MD5 era débil. El protocolo, sencillamente, nunca se actualizó. Entremos ahora en el análisis técnico detallado. El ataque Blast-RADIUS, clasificado formalmente como CVE-2024-3596, fue revelado en julio de 2024 por un equipo de investigadores de la Universidad de Boston, la UC San Diego, el CWI Amsterdam y Microsoft Research. Combina una vulnerabilidad a nivel de protocolo con un ataque de colisión de prefijo elegido por MD5 y, lo que es fundamental, con mejoras de velocidad significativas que hacen que el ataque sea viable en tiempo real. Así es como funciona. Un atacante de tipo man-in-the-middle se sitúa en la ruta de red entre el cliente RADIUS (su punto de acceso) y el servidor RADIUS. Cuando un usuario intenta autenticarse, el atacante intercepta el paquete Access-Request. Inyecta un atributo malicioso especialmente diseñado en esta solicitud. Este atributo está diseñado para provocar una colisión matemática: una situación en la que dos entradas diferentes producen el mismo hash MD5. El atacante calcula previamente esta colisión para que el hash MD5 de la respuesta legítima Access-Reject del servidor coincida con el hash MD5 de una respuesta Access-Accept falsificada que el atacante ha construido. Cuando el servidor devuelve su Access-Reject, el atacante la sustituye por su Access-Accept falsificada. El cliente RADIUS comprueba el Response Authenticator, determina que es válido (porque los hashes MD5 coinciden) y concede acceso a la red. El atacante nunca ha necesitado saber la contraseña del usuario. Tampoco ha necesitado conocer el secreto compartido entre el cliente y el servidor RADIUS. Simplemente ha explotado la debilidad matemática de MD5 para hacer que una respuesta falsificada parezca legítima. Y con el hardware moderno, la colisión de MD5 requerida se puede calcular en menos de cinco minutos. No se trata de un ataque teórico. Es operativamente viable hoy en día. Esta vulnerabilidad afecta a todos los despliegues de RADIUS que utilizan los modos de autenticación PAP (Password Authentication Protocol), CHAP y MS-CHAP sobre UDP. Estos son extremadamente comunes en entornos empresariales, especialmente en despliegues heredados. Los únicos modos de autenticación que son inmunes son aquellos que utilizan EAP (Extensible Authentication Protocol), porque EAP establece su propio túnel criptográfico que es independiente del Response Authenticator de MD5. Permítame exponer el riesgo empresarial en términos concretos. Piense en una cadena hotelera. Un atacante que obtenga acceso no autorizado a la red corporativa puede moverse lateralmente para llegar al sistema de gestión inmobiliaria, acceder a los registros de los huéspedes, llegar a los terminales de punto de venta y, potencialmente, exfiltrar datos de tarjetas de pago. El coste medio de una filtración de datos en el sector de la hostelería supera los tres millones de libras. Bajo la GDPR, una filtración que afecte a los datos personales de los huéspedes puede acarrear multas de hasta el cuatro por ciento de la facturación anual global. Bajo PCI-DSS, una filtración que afecte a los datos de los titulares de tarjetas puede dar lugar a investigaciones forenses obligatorias, multas de las marcas de tarjetas y la posible pérdida de los privilegios de procesamiento de pagos. Las consecuencias financieras y de reputación son sustanciales. Pasemos ahora a las recomendaciones de implementación. ¿Cómo defenderse de esto? La respuesta tiene dos niveles: el endurecimiento inmediato y la modernización a largo plazo. La acción inmediata es aplicar los parches del fabricante para CVE-2024-3596. Todos los principales fabricantes de RADIUS - Cisco ISE, Microsoft NPS, FreeRADIUS, Juniper, Aruba, Ruckus - han lanzado actualizaciones. Junto con el parche, el cambio de configuración crítico es imponer el atributo Message-Authenticator en todos los clientes y servidores RADIUS. Este atributo, definido en RFC 2869, proporciona una comprobación de integridad basada en HMAC sobre todo el paquete RADIUS. A diferencia del Response Authenticator, la construcción HMAC no es vulnerable al ataque de colisión de prefijo elegido. Configurar su infraestructura para requerir este atributo - y rechazar cualquier mensaje que llegue sin él - cierra el vector de ataque inmediato. Para FreeRADIUS, esto significa establecer require_message_authenticator igual a yes en su archivo de configuración de clientes. Para Microsoft NPS, es una configuración de directiva en su configuración de Network Policy. Este es un cambio de baja interrupción que normalmente se puede implementar dentro de una ventana de mantenimiento. Sin embargo, la imposición de Message-Authenticator es un parche temporal, no una solución. La respuesta estratégica a largo plazo es migrar a la autenticación basada en EAP. El estándar de oro es WPA3-Enterprise con EAP-TLS. EAP-TLS utiliza autenticación mutua basada en certificados - tanto el dispositivo cliente como el servidor RADIUS deben presentar certificados digitales válidos de una Entidad de Certificación de confianza. Esto elimina el secreto compartido por completo, elimina la dependencia de MD5 y proporciona un nivel de seguridad que es inmune a toda la clase de ataques que representa Blast-RADIUS. Para entornos donde implementar una infraestructura PKI completa es complejo - particularmente espacios con una alta rotación de dispositivos o políticas de trae tu propio dispositivo - PEAP con MSCHAPv2 es un paso intermedio aceptable, siempre que los clientes estén configurados para validar el certificado del servidor RADIUS. Sin la validación del certificado del servidor, PEAP es vulnerable a ataques de puntos de acceso no autorizados, lo cual es un riesgo diferente pero igualmente grave. La fase final de la hoja de ruta de modernización es implementar RADIUS sobre TLS, conocido como RADSEC. RADSEC encapsula todo el tráfico RADIUS dentro de una sesión TLS mutuamente autenticada, proporcionando total confidencialidad e integridad para todo el intercambio de autenticación. Esto hace que los ataques a nivel de transporte como Blast-RADIUS sean imposibles, porque no hay tráfico RADIUS sin cifrar para interceptar. RADSEC es particularmente valioso en entornos distribuidos - cadenas hoteleras, redes minoristas, complejos de estadios - donde el tráfico RADIUS puede atravesar múltiples segmentos de red entre el punto de acceso y el servidor de autenticación central. Pasemos a una sesión de preguntas y respuestas rápidas. Pregunta uno: Usamos EAP. ¿Estamos seguros? Si está utilizando EAP-TLS, PEAP o EAP-TTLS, no es vulnerable al ataque de colisión MD5 específico de Blast-RADIUS. Sin embargo, debería aplicar los parches del fabricante como medida de defensa en profundidad, y debería auditar su configuración para asegurarse de que la validación del certificado del servidor se imponga en todos los clientes. Segunda pregunta: Nuestro tráfico RADIUS se encuentra en una VLAN de gestión dedicada. ¿Nos protege eso? Reduce la superficie de ataque, pero no elimina la vulnerabilidad. Un atacante que ya haya comprometido cualquier dispositivo en la red de gestión todavía puede ejecutar un ataque man-in-the-middle. La segmentación es una capa de defensa valiosa, pero debe combinarse con la aplicación de Message-Authenticator y la migración a EAP. Tercera pregunta: ¿Qué tan difícil es la mitigación inmediata? Para la mayoría de los entornos, aplicar Message-Authenticator es un cambio de configuración sencillo. El principal desafío es garantizar que todos los dispositivos de red - puntos de acceso, switches, controladores - admitan el atributo y lo tengan habilitado. Una auditoría de dispositivos antes de aplicar el requisito en el lado del servidor es esencial para evitar fallos de autenticación en el hardware heredado. Cuarta pregunta: ¿Puedo detectar si he sido atacado? Esto es muy difícil. El paquete Access-Accept falsificado parece válido para el cliente RADIUS porque la comprobación del hash MD5 es correcta. Su mejor enfoque de detección es supervisar los registros de contabilidad de RADIUS en busca de autenticaciones correctas anómalas - tipos de dispositivos inesperados, direcciones MAC que no coinciden con su inventario o inicios de sesión correctos a horas inusuales. Integre sus datos de contabilidad de RADIUS con su SIEM para obtener alertas automatizadas. Para resumir y esbozar sus próximos pasos. La vulnerabilidad Blast-RADIUS es una amenaza grave y prácticamente explotable para cualquier organización que ejecute la autenticación RADIUS heredada sobre UDP. El ataque no requiere conocimiento de credenciales y se puede ejecutar en cuestión de minutos. Su prioridad inmediata es auditar su infraestructura, aplicar los parches del proveedor y exigir el atributo Message-Authenticator en todos los clientes y servidores RADIUS. Su objetivo a medio plazo es migrar a EAP-TLS y WPA3-Enterprise. Su objetivo de arquitectura a largo plazo es RADSEC. En Purple, proporcionamos la capa de inteligencia que le ayuda a comprender y proteger la red WiFi de su establecimiento. Nuestra plataforma le ofrece la visibilidad para identificar tipos de dispositivos, supervisar patrones de autenticación y garantizar que sus políticas de seguridad se apliquen de manera efectiva en cada punto de acceso de su propiedad. Su plan de acción se resume en tres palabras: Auditar, Parchear y Modernizar. No permita que un protocolo de hace 30 años sea el eslabón débil en su postura de seguridad. Gracias por unirse a este Purple Technical Briefing. Manténgase seguro.

Parte de nuestra serie principal: Guía de seguridad WiFi corporativa

Hardening RADIUS against MD5 collision attacks

Resumen ejecutivo

El protocolo Remote Authentication Dial-In User Service (RADIUS), definido en la norma IETF RFC 2865, ha servido como marco de autenticación central para redes empresariales durante más de tres décadas. Sin embargo, la divulgación de CVE-2024-3596 (conocido como BlastRADIUS) expuso una vulnerabilidad crítica del protocolo en la forma en que RADIUS procesa los campos de autenticación de respuesta (Response Authenticator) basados en MD5.

Al explotar las técnicas de colisión de prefijo elegido de MD5, un atacante intermedio (MitM) situado en la ruta de red entre un cliente RADIUS (como un punto de acceso inalámbrico o un conmutador) y un servidor RADIUS puede falsificar aprobaciones de autenticación. Un atacante puede convertir en tiempo real un paquete Access-Reject legítimo en un paquete Access-Accept sin poseer credenciales de usuario ni conocer el secreto compartido de RADIUS.

Esta guía técnica describe la mecánica criptográfica del ataque BlastRADIUS, detalla las estrategias inmediatas de mitigación de los proveedores mediante la aplicación de Message-Authenticator y proporciona una hoja de ruta empresarial para migrar la infraestructura WiFi a EAP-TLS de confianza cero y Purple Cloud RADIUS.


Mecánica técnica de los ataques de colisión MD5 (CVE-2024-3596)

Para comprender BlastRADIUS es necesario examinar la estructura de la cabecera del paquete RADIUS establecida bajo la norma RFC 2865:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     Request Authenticator                     |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

El fallo criptográfico en RFC 2865

Cuando un servidor RADIUS responde a un Access-Request, calcula un hash MD5 sobre el código de respuesta, el identificador, la longitud, el autenticador de solicitud, los atributos y el secreto compartido:

Response Authenticator = MD5(Code + ID + Length + Request Authenticator + Attributes + Shared Secret)

Dado que MD5 es susceptible a colisiones de prefijo elegido, un atacante ejecuta la siguiente secuencia:

  1. Interceptar Access-Request: Intercepta un Access-Request legítimo enviado por un punto de acceso.
  2. Inyectar prefijos de colisión: Inserta atributos Proxy-State manipulados en el paquete de solicitud antes de reenviarlo al servidor RADIUS.
  3. Interceptación de Access-Reject: cuando el servidor RADIUS rechaza el intento de autenticación y devuelve un Access-Reject, el atacante intercepta el paquete.
  4. Falsificación de Access-Accept: el atacante modifica el código de respuesta a Access-Accept y altera las cargas útiles de los atributos. Dado que el prefijo de colisión calculado previamente produce un resumen de salida MD5 idéntico, el punto de acceso valida el Access-Accept falsificado como auténtico.

-

Hoja de ruta de mitigación paso a paso

Paso 1: Forzar Message-Authenticator (RFC 2869)

El atributo Message-Authenticator (Atributo 80) utiliza HMAC-MD5 para calcular una firma digital sobre todo el paquete RADIUS, incluidos los campos de cabecera y los atributos de carga útil:

Message-Authenticator = HMAC-MD5(Paquete RADIUS, Secreto compartido)

Dado que HMAC-MD5 es resistente a los ataques de colisión de prefijo elegido, forzar el Atributo 80 en todas las solicitudes de clientes y respuestas de servidores hace imposible la explotación de BlastRADIUS.

Comandos de implementación de proveedores

Proveedor de RADIUS Comando / Acción de configuración Versión mínima admitida
FreeRADIUS Establecer require_message_authenticator en yes en clients.conf v3.0.27 / v3.2.5
Cisco ISE Habilitar Require Message-Authenticator for all RADIUS Requests v3.1 Parche 8 / v3.2 Parche 4
Aruba ClearPass Activar Enforce Message-Authenticator en el Servicio RADIUS v6.11.7 / v6.12.2
Microsoft NPS Aplicar el valor DWORD de registro RequireMessageAuthenticator en 1 Windows Server 2019/2022 KB5040442
Ruckus SmartZone Habilitar Message-Authenticator Enforcement bajo el Servidor AAA v6.1.2 Parche 1
# Fragmento de securización de FreeRADIUS clients.conf
# Asegurar que require_message_authenticator esté establecido en yes para los bloques de clientes
client branch_ap_cluster {
    ipaddr_range: 192.168.10.0/24
    secret_key: EnterpriseSecret2026!
    require_message_authenticator_option: yes
    limit_connections: 16
    idle_timeout_sec: 30
}
# Securización del registro de Microsoft NPS a través de PowerShell
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy" `
    -Name "RequireMessageAuthenticator" -Value 1 -PropertyType DWORD -Force
Restart-Service IAS

-

Matriz de seguridad comparativa: opciones de securización de RADIUS

Medida de securización Protección contra vulnerabilidades Esfuerzo de implementación Compatibilidad con clientes Impacto operativo
Message-Authenticator (RFC 2869) Bloquea CVE-2024-3596 Bajo (Cambio de configuración) Compatible con APs modernos Tiempo de inactividad mínimo
RADSEC (RFC 6614) Cifrado completo TLS 1.3 WAN Medio (Despliegue de proxy) Requiere compatibilidad con TCP 2083 Elimina riesgos MitM
Migración a 802.1X EAP-TLS Autenticación mutua de certificados zero-trust Medio a alto (PKI / SCEP) Todos los sistemas operativos corporativos compatibles Elimina las contraseñas
Purple Cloud RADIUS Servidor RADIUS en la nube de extremo a extremo + RADSEC Bajo (Integración en la nube lista para usar) Compatibilidad universal con 802.1X Ciclo de vida de certificados automatizado

-

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.

Transición a RADSEC (RFC 6614) y EAP-TLS

El RADIUS tradicional funciona a través de los puertos UDP no cifrados 1812 y 1813. El transporte de tráfico de autenticación a través de enlaces WAN no confiables expone las cabeceras de los paquetes a la interceptación activa.

La implementación de RADSEC (RADIUS sobre TLS) envuelve los paquetes RADIUS dentro de un túnel TCP TLS 1.3 cifrado:

  • Puerto: TCP 2083
  • Cifrado: TLS 1.3 con suites de cifrado AES-256-GCM
  • Autenticación: Verificación mutua de certificados X.509 entre los proxies de los clientes y los endpoints del servidor
flowchart LR
    A["Wireless Endpoints (Laptops/IoT)"] -->|WPA3-Enterprise 802.1X| B["Access Points / Switches"]
    B -->|RADSEC TLS 1.3 Port 2083| C["Purple Cloud RADIUS"]
    C -->|REST / SCIM API| D["Cloud IdP (Entra ID / Okta / Google)"]

Beneficios arquitectónicos clave de Purple Cloud RADIUS

  1. Incorporación de certificados 802.1X sin intervención (Zero-touch): Automatiza la emisión de certificados SCEP y EST para dispositivos gestionados, eliminando la configuración manual de contraseñas.
  2. Arquitectura proxy RADSEC integrada: Protege el tráfico de las sucursales remotas a través de conexiones TCP cifradas sin necesidad de complejos túneles IPsec de sitio a sitio.
  3. Seguridad integral para invitados y corporativa: Combina la autenticación enterprise 802.1X con la incorporación de invitados a través de un Captive Portal que cumple con el GDPR.

Cumplimiento normativo empresarial e impacto de auditoría

Requisitos de PCI-DSS v4.0

Bajo PCI-DSS v4.0, una infraestructura RADIUS no corregida expone los entornos de tarjetas de pago a un grave incumplimiento de auditoría:

  • Requisito 8.3: Exige autenticación multifactor y una gestión sólida de credenciales para todo el acceso administrativo.
  • Requisito 8.6: Prohíbe la dependencia de algoritmos criptográficos débiles (como los resúmenes MD5 sin clave).
  • Requisito 1.3: Requiere una segmentación de red estricta entre los entornos de invitados, IoT y el entorno de datos de titulares de tarjetas (CDE).

Alineación con ISO 27001 y GDPR

Mantener una autenticación RADIUS no cifrada o vulnerable infringe el Control A.8.20 de ISO 27001:2022 (Seguridad de redes) y el Artículo 32 de GDPR (Seguridad del tratamiento). La actualización a EAP-TLS y RADSEC establece un cumplimiento criptográfico documentado.

Evalúe el estado de seguridad de su RADIUS con Purple

¿Es la infraestructura de WiFi corporativa de su empresa vulnerable a BlastRADIUS (CVE-2024-3596)? Purple ofrece soluciones de cloud RADIUS de confianza cero con cifrado RADSEC integrado, aprovisionamiento automatizado de certificados SCEP e integración perfecta con proveedores de identidad.

  • Incorporación automatizada de 802.1X EAP-TLS: Elimine las contraseñas heredadas en todos los endpoints corporativos.
  • Proxies en la nube RADSEC listos para usar: Cifre el tráfico de autenticación de las sucursales a través de TLS 1.3 sin la sobrecarga de una VPN.
  • Seguridad y analítica unificadas: Gestione la seguridad corporativa 802.1X junto con un WiFi para invitados que cumple con el GDPR.

Hable con un especialista en seguridad RADIUS

Preguntas frecuentes

¿Es EAP-TLS vulnerable a BlastRADIUS?

No. EAP-TLS, PEAP y EAP-TTLS establecen un túnel TLS independiente entre el dispositivo cliente y el servidor RADIUS. Este túnel criptográfico funciona de forma independiente del resumen MD5 del Response Authenticator de RADIUS heredado, lo que hace que la autenticación EAP sea inmune a CVE-2024-3596.

¿Cómo evita Message-Authenticator (RFC 2869) el CVE-2024-3596?

Message-Authenticator (Atributo 80) utiliza HMAC-MD5 para firmar todo el paquete RADIUS utilizando el secreto compartido. A diferencia de los Response Authenticators MD5 estándar, HMAC-MD5 es resistente desde el punto de vista criptográfico a los ataques de colisión de prefijo elegido, lo que imposibilita la falsificación de paquetes.

¿Cuál es la diferencia entre UDP RADIUS y RADSEC (RFC 6614)?

RADIUS estándar transporta paquetes de autenticación en texto plano a través de puertos UDP no cifrados 1812 y 1813. RADSEC encapsula los paquetes RADIUS dentro de un flujo TCP TLS 1.3 cifrado en el puerto 2083, lo que proporciona autenticación mutua de certificados X.509 y una confidencialidad total a través de redes no seguras.

¿Cómo auditan los equipos de red los puntos de acceso heredados para verificar la compatibilidad con Message-Authenticator?

Los equipos de red deben capturar el tráfico RADIUS entrante utilizando tcpdump -i eth0 -n port 1812 y filtrar por radius.Message_Authenticator. Confirmar la presencia del Atributo 80 en todos los modelos de puntos de acceso garantiza que la aplicación en el lado del servidor no interrumpirá las conexiones de los clientes.


Próximos pasos y recursos relacionados

Para explorar arquitecturas de seguridad de WiFi para empresas y guías de diagnóstico relacionadas, revise los siguientes recursos:

Definiciones clave

BlastRADIUS (CVE-2024-3596)

Una vulnerabilidad crítica a nivel de protocolo en RADIUS (RFC 2865) que permite a un atacante falsificar respuestas de autenticación utilizando técnicas de colisión de prefijo elegido MD5.

Revelado en julio de 2024, afecta a la infraestructura de red corporativa que ejecuta autenticación RADIUS no cifrada sobre UDP.

Message-Authenticator (Atributo 80)

Un atributo de cabecera RADIUS definido en RFC 2869 que utiliza HMAC-MD5 para calcular una firma digital sobre todo el paquete RADIUS.

La imposición del Atributo 80 bloquea los ataques BlastRADIUS porque HMAC-MD5 es criptográficamente inmune a la manipulación por colisión de prefijo elegido.

Response Authenticator

Un campo de 16 bytes en las cabeceras de los paquetes RADIUS RFC 2865 calculado mediante un resumen MD5 sobre el autenticador de solicitud, los atributos y el secreto compartido.

El punto de acceso receptor depende de este resumen para verificar la autenticidad del paquete, algo que explota BlastRADIUS.

RADSEC (RADIUS sobre TLS)

Un estándar RFC 6614 que encapsula los paquetes de autenticación RADIUS dentro de un flujo TCP TLS 1.3 cifrado en el puerto 2083.

Evita la interceptación de paquetes de tipo intermediario (man-in-the-middle) a través de enlaces WAN no confiables entre los puntos de acceso y los servidores RADIUS.

EAP-TLS

Protocolo de Autenticación Extensible - Seguridad de la Capa de Transporte. Un estándar de autenticación mutua IEEE 802.1X que utiliza certificados digitales X.509.

Recomendado por los marcos normativos NIST e ISO 27001 como el reemplazo principal para la autenticación RADIUS heredada PAP/CHAP.

Ejemplos prácticos

¿Cómo verifican los administradores de red si los puntos de acceso inalámbricos y conmutadores existentes imponen Message-Authenticator antes de habilitar la aplicación obligatoria en los servidores RADIUS?

Para auditar la conformidad de Message-Authenticator sin interrumpir el acceso WiFi de producción:

  1. Auditoría de captura de paquetes: Ejecute Wireshark o tcpdump en la interfaz del servidor RADIUS (puerto UDP 1812) para capturar los paquetes Access-Request entrantes: tcpdump -i eth0 -n port 1812 -w radius_audit.pcap.
  2. Inspección de filtros de atributos: Filtre los paquetes capturados por radius.Message_Authenticator. Confirme que todos los tipos de hardware cliente (puntos de acceso, conmutadores, controladores inalámbricos) incluyen el Atributo 80 en las solicitudes iniciales.
  3. Prueba de políticas de proveedor: Habilite el requisito de Message-Authenticator en un único perfil de cliente RADIUS de prueba antes de aplicar la imposición global en los servidores de producción FreeRADIUS, Cisco ISE o Microsoft NPS.
Comentario del examinador: Auditar las capacidades de los clientes antes de la imposición en el servidor evita que los conmutadores de red heredados o los AP heredados queden excluidos durante las ventanas de mantenimiento.

¿Cómo actualiza un operador de recintos multisitio las instalaciones heredadas de FreeRADIUS para bloquear BlastRADIUS mientras planifica una migración de confianza cero a EAP-TLS?

Un plan de mitigación en dos fases mantiene la continuidad operativa de la red:

  1. Fase 1 (Robustecimiento inmediato): Actualice FreeRADIUS a la versión 3.0.27 o 3.2.5. Edite clients.conf para establecer require_message_authenticator = yes y actualice radiusd.conf para rechazar paquetes no autenticados.
  2. Fase 2 (Actualización de arquitectura): Despliegue proxies RADSEC en los puntos de acceso de las sucursales para envolver el tráfico RADIUS en túneles TLS 1.3 (puerto TCP 2083) e integre Purple Cloud RADIUS con la inscripción automatizada SCEP para dispositivos corporativos.
Comentario del examinador: La Fase 1 cierra el vector de explotación CVE-2024-3596 de inmediato con cero costes de hardware, mientras que la Fase 2 establece un aislamiento criptográfico a largo plazo contra la interceptación de paquetes WAN.

Preguntas de práctica

Q1. ¿Por qué la colisión de prefijo elegido MD5 permite a un atacante eludir la autenticación RADIUS sin conocer el secreto compartido?

Sugerencia: Concéntrese en cómo el punto de acceso inalámbrico verifica el resumen del MD5 Response Authenticator.

Ver respuesta modelo

En RADIUS RFC 2865, los resúmenes de los paquetes Access-Reject y Access-Accept dependen de un hash MD5 del contenido del paquete combinado con el secreto compartido. Un atacante con acceso man-in-the-middle inserta prefijos de colisión en los atributos de estado del proxy antes de reenviar el Access-Request. Cuando el servidor devuelve un Access-Reject, el atacante altera el código del paquete a Access-Accept. Dado que las colisiones de prefijo elegido de MD5 producen resúmenes de salida hash idénticos para entradas diferentes, el punto de acceso valida el Access-Accept falsificado como auténtico sin llegar a conocer el secreto compartido.

Q2. ¿Qué métodos de autenticación RADIUS son vulnerables a BlastRADIUS y qué métodos son criptográficamente inmunes?

Sugerencia: Distinga entre los protocolos heredados PAP/CHAP sobre UDP frente a los protocolos EAP envueltos en TLS.

Ver respuesta modelo

Los modos de autenticación RADIUS que dependen de PAP, CHAP y MS-CHAP sobre UDP son vulnerables porque dependen directamente de la validación del autenticador de respuesta MD5. EAP-TLS, PEAP y EAP-TTLS son inmunes a BlastRADIUS porque EAP establece una sesión TLS criptográfica independiente entre el suplicante y el servidor, evitando la dependencia del resumen del autenticador de respuesta RADIUS heredado para la verificación de la identidad.

Continúe leyendo esta serie

Configuring RADIUS Authentication for Guest and Staff WiFi Networks

Esta guía de referencia técnica describe la arquitectura, configuración y despliegue de la autenticación RADIUS para redes WiFi empresariales de invitados y de personal. Proporciona a los arquitectos de redes y responsables de TI los protocolos exactos, los estándares de seguridad y las metodologías de resolución de problemas necesarios para crear sistemas de control de acceso inalámbrico seguros y escalables.

Leer la guía →

Passpoint y OpenRoaming: Guía completa

Esta guía de referencia técnica proporciona un análisis exhaustivo de los frameworks Passpoint (Hotspot 2.0) y WBA OpenRoaming dentro de las redes WiFi empresariales. Detalla los protocolos de autenticación subyacentes, los componentes arquitectónicos y las estrategias de despliegue necesarias para establecer una conectividad de invitados segura y sin fricciones. Los arquitectos de redes y los líderes de TI aprenderán a diseñar, implementar y solucionar problemas de estos estándares para eliminar las barreras de inicio de sesión manual mientras mantienen una seguridad de nivel empresarial.

Leer la guía →

Server RADIUS: una guía completa para empresas

Esta guía proporciona a directores de TI, arquitectos de redes y directores de tecnología (CTO) una referencia técnica definitiva sobre la autenticación mediante server RADIUS para WiFi empresarial. Cubre el marco AAA, la arquitectura 802.1X, la selección del método EAP, las ventajas y desventajas del despliegue en la nube frente a local y la asignación dinámica de VLAN. Los operadores de recintos del sector de la hostelería, retail, eventos y el sector público encontrarán pautas de implementación prácticas, casos de estudio reales y los marcos de decisión necesarios para migrar de claves precompartidas no seguras a una arquitectura de control de acceso a la red segura y basada en la identidad.

Leer la guía →

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.