Mitigación de la suplantación del protocolo Blast-RADIUS (CVE-2024-3596)

Introducción

Este documento describe cómo mitigar la suplantación del protocolo Blast RADIUS.

Overview

El 7 de julio de 2024, los investigadores de seguridad revelaron esta vulnerabilidad en el protocolo RADIUS: CVE-2024-3596: El protocolo RADIUS en RFC 2865 es susceptible a ataques de falsificación por parte de un atacante en trayectoria que puede modificar cualquier respuesta válida (Access-Accept, Access-Reject o Access-Challenge) a cualquier otra respuesta mediante un ataque de colisión de prefijo seleccionado contra la firma MD5 Response Authenticator. Han publicado un documento en el que detallan sus conclusiones en este informe técnico que demuestra una falsificación de respuesta satisfactoria frente a flujos que no utilizan el atributo Message-Authenticator.

Para obtener una lista actualizada de los productos de Cisco afectados por esta vulnerabilidad y de las versiones que contienen correcciones, visite: Vulnerabilidad de suplantación de protocolo RADIUS (Blast-RADIUS): Julio de 2024. En este artículo se tratan las técnicas generales de mitigación, así como la forma en que se aplican a algunos productos de Cisco, pero no a todos ellos. Se debe consultar la documentación de cada producto para obtener información específica. Como servidor RADIUS emblemático de Cisco, Cisco Identity Service Engine se trata con más detalle.

Background

Este ataque aprovecha un ataque de prefijo seleccionado MD5 que utiliza colisiones en MD5, lo que permite que un atacante agregue datos adicionales al paquete de respuesta RADIUS mientras modifica los atributos existentes del paquete de respuesta. Un ejemplo que se demostró fue la capacidad de cambiar un rechazo de acceso RADIUS a un aceptación de acceso RADIUS. Esto es posible porque RADIUS de forma predeterminada no incluye un hash de todos los atributos en el paquete. RFC 2869 agrega el atributo Message-Authenticator, pero actualmente solo es necesario incluirlo cuando se utilizan protocolos EAP, lo que significa que el ataque descrito en CVE-2024-3596 es posible contra cualquier intercambio no EAP en el que el cliente RADIUS (NAD) no incluya el atributo Message-Authenticator.

Mitigación

Autenticador de mensaje

1.- El cliente RADIUS debe incluir el atributo Message-Authenticator.

Cuando el dispositivo de acceso a la red (NAD) incluye el atributo Message-Authenticator en la solicitud de acceso, Cisco Identity Services Engine incluye Message-Authenticator en el paquete Access-Accept, Access-Challenge o Access-Reject resultante en todas las versiones.

2.- El servidor RADIUS debe forzar la recepción del atributo Message-Authenticator.

No basta con incluir el autenticador de mensaje en la solicitud de acceso, ya que el ataque permite eliminar el autenticador de mensaje de la solicitud de acceso antes de reenviarlo al servidor RADIUS. El servidor RADIUS también debe requerir que NAD incluya el autenticador de mensaje en la solicitud de acceso. Esto no es lo predeterminado en Cisco Identity Services Engine, pero se puede habilitar en el nivel de protocolos permitidos, que se aplica en el nivel de conjunto de políticas. La opción bajo la configuración Allowed Protocols es Require Message-Authenticator para todas las solicitudes RADIUS:

Opción de protocolos permitidos en Identity Services Engine

Autenticaciones que coinciden con un conjunto de directivas en el que la configuración de Protocolos permitidos requiere Message-Authenticator, pero en el que Access-Request no contiene el atributo Message-Authenticator es eliminado por ISE:

Es importante verificar si el NAD está enviando Message-Authenticator antes de ser requerido por el servidor RADIUS ya que este no es un atributo negociado, depende del NAD enviarlo de forma predeterminada o configurarlo para enviarlo. Message-Authenticator no es uno de los atributos notificados por ISE; una captura de paquetes es la mejor manera de determinar si un NAD/caso de uso incluye Message-Authenticator. ISE ha incorporado la funcionalidad de captura de paquetes en Operaciones > Solución de problemas > Herramientas de diagnóstico > Herramientas generales > Volcado de TCP. Tenga en cuenta que diferentes casos de uso del mismo NAD pueden incluir o no Message-Authenticator.

Esta es una captura de ejemplo de una solicitud de acceso que incluye el atributo Message-Authenticator:

Atributo de autenticador de mensaje en la solicitud de acceso a Radius

Esta es una captura de ejemplo de una solicitud de acceso que no incluye el atributo Message-Authenticator:

Cifrar con TLS/IPSec

La solución más eficaz a largo plazo para proteger RADIUS es cifrar el tráfico entre el servidor RADIUS y el NAD. Esto añade privacidad y una mayor integridad criptográfica a la mera confianza en el autenticador de mensaje derivado de MD5-HMAC. El cual, si cualquiera de estos puede ser utilizado entre el servidor RADIUS y el NAD, depende de ambos lados que soportan el método de encripción.

Los términos generales utilizados en el sector para el cifrado TLS de RADIUS son:

• RadSec: hace referencia a RFC 6614
• RadSec TLS: hace referencia a RFC 6614
• RadSec DTLS - hace referencia a RFC 7360

Es importante implementar el cifrado de forma controlada, ya que el cifrado TLS presenta una sobrecarga de rendimiento, así como consideraciones de administración de certificados. Los certificados también deben renovarse periódicamente.

RADIUS sobre DTLS

La seguridad de la capa de transporte del datagrama (DTLS) como una capa de transporte para RADIUS está definida por RFC 7360, que utiliza certificados para autenticar mutuamente el servidor RADIUS y el NAD luego cifra el paquete RADIUS completo mediante un túnel TLS. El método de transporte sigue siendo UDP y requiere que los certificados se implementen tanto en el servidor RADIUS como en NAD. Tenga en cuenta que al implementar RADIUS sobre DTLS, es imperativo que el vencimiento y la sustitución de certificados se administre de cerca para evitar que los certificados caducados interrumpan la comunicación RADIUS. ISE admite DTLS para la comunicación entre ISE y NAD, ya que no se admite RADIUS 3.4 Radius sobre DTLS para servidores proxy RADIUS o servidores de token RADIUS. RADIUS sobre DTLS también es compatible con muchos dispositivos de Cisco que actúan como NAD, como switches y controladores inalámbricos que ejecutan Cisco IOS-XE®.

RADIUS sobre TLS

El cifrado de seguridad de la capa de transporte (TLS) para RADIUS se define en RFC 6614, cambia el transporte a TCP y utiliza TLS para cifrar completamente los paquetes RADIUS. Esto es comúnmente utilizado por el servicio eduroam como ejemplo. A partir de ISE 3.4, RADIUS sobre TLS no es compatible, pero lo son muchos dispositivos de Cisco que actúan como NAD, como switches y controladores inalámbricos que ejecutan Cisco IOS-XE.

IPSec

Identity Services Engine admite de forma nativa túneles IPSec entre ISE y NAD que también admiten túneles IPSec de terminación. Se trata de una buena opción en la que no se admite RADIUS sobre DTLS o RADIUS sobre TLS, pero se debe utilizar con moderación, ya que solo se admiten 150 túneles por nodo de servicios de políticas de ISE. ISE 3.3 y las versiones posteriores ya no necesitan una licencia para IPSec; ahora está disponible de forma nativa.

Mitigación parcial

Segmentación RADIUS

Segmente el tráfico RADIUS en las VLAN de gestión y los enlaces seguros y cifrados, como los que se pueden proporcionar a través de SD-WAN o MACSec. Esta estrategia no reduce el riesgo de ataque a cero, pero puede reducir considerablemente la superficie de ataque de la vulnerabilidad. Esto puede ser una buena medida de interrupción de parada mientras los productos despliegan el requisito de autenticador de mensaje o soporte DTLS/RadSec. La vulnerabilidad requiere que un atacante realice correctamente la comunicación RADIUS Man-in-the-Middle (MITM), de modo que si un atacante no puede entrar en un segmento de red con ese tráfico, el ataque no es posible. La razón por la que esto es sólo una mitigación parcial es que una configuración incorrecta de la red o una vulnerabilidad de una parte de la red puede exponer el tráfico RADIUS.

Si el tráfico RADIUS no se puede segmentar o cifrar, se pueden implementar funciones adicionales para evitar MITM exitoso en segmentos en riesgo como: Protección de origen de IP, inspección dinámica de ARP y detección de DHCP. También es posible utilizar otros métodos de autenticación basados en el tipo de flujo de autenticación, como TACACS+, SAML, LDAPS y más.

Estado de vulnerabilidad de Identity Services Engine

Estas tablas describen lo que está disponible a partir de Cisco ISE 3.4 para proteger los flujos de autenticación frente a Blast-RADIUS.

Para recapitular, estos tres elementos siguientes deben estar en su lugar para un flujo que utilice sólo el autenticador de mensaje y no el cifrado DTLS/RadSec/IPSec, para que el flujo no sea vulnerable:

• El dispositivo de acceso a la red DEBE enviar el atributo Message-Authenticator en la solicitud de acceso.
• El servidor RADIUS DEBE requerir el atributo Message-Authenticator en Access-Request.
• El servidor RADIUS DEBE responder con el atributo Message-Authenticator en Access-Challenge, Access-Accept y Access-Reject.

Consulte el ID de bug de Cisco CSCwk67747, que realiza un seguimiento de los cambios para cerrar las vulnerabilidades cuando Cisco ISE actúa como cliente RADIUS.

ISE como servidor RADIUS

ISE como cliente RADIUS

Actualizaciones de ISE como cliente RADIUS

Las mejoras de Cisco ISE que actúa como cliente RADIUS se incluyen en las versiones: 3.1 parche 10, 3.2 parche 8, 3.3 parche 5, 3.4 parche 2, 3.5 y versiones posteriores a través del ID de bug de Cisco CSCwk67747. Después de un parche o actualización, cualquier recurso nuevo que se cree tomará por defecto la nueva configuración más segura. Los recursos existentes deben modificarse para utilizar la actualización o revisión posterior de la configuración más segura. Se ha agregado una nueva casilla de verificación: "Se requiere autenticador de mensaje al responder"; si está activado, tiene un doble objetivo: Cisco ISE envía siempre el autenticador de mensaje y no supera la autenticación si se recibe una respuesta sin un autenticador de mensaje. El comportamiento es el siguiente:

Caso	NAD incluyó autenticador de mensaje en la solicitud	NAD no incluyó el autenticador de mensaje en la solicitud
Antes del parche/actualización	ISE envía el autenticador de mensaje al token RADIUS, al servidor RADIUS externo o a la CoA	ISE no envía el autenticador de mensaje al token RADIUS, servidor RADIUS externo o CoA
Después de aplicar el parche o actualizar y de que la casilla de verificación Message Authenticator Required On Response esté desactivada.	ISE envía el autenticador de mensaje al token RADIUS, al servidor RADIUS externo o a la CoA	ISE no envía el autenticador de mensaje al token RADIUS, al servidor RADIUS externo o a la CoA
Después de revisar/actualizar y marcar la casilla de verificación Se requiere autenticador de mensaje al responder.	ISE envía el autenticador de mensaje al token RADIUS, al servidor RADIUS externo o a la CoA	ISE envía el autenticador de mensaje al token RADIUS, al servidor RADIUS externo o a CoA

Servidor Token RADIUS

Una nueva casilla de verificación: Message Authenticator Required On Response fue agregada bajo la ficha Authentication para la configuración del Servidor Token RADIUS:

Con la casilla activada, si se recibe una respuesta RADIUS sin autenticador de mensaje, se registra un mensaje de error en el registro de autenticación detallado al que se puede acceder a través de registros en directo o un informe de autenticación RADIUS:

Servidor RADIUS externo

Una nueva casilla: Se agregó Message Authenticator Required On Response a la configuración del servidor RADIUS externo:

Con la casilla activada, si se recibe una respuesta RADIUS sin autenticador de mensaje, se registra un mensaje de error en el registro de autenticación detallado al que se puede acceder a través de registros en directo o un informe de autenticación RADIUS:

Cambio de autorización (CoA)

Los cambios de CoA se realizaron en los perfiles de dispositivos de red en la sección Cambio de autorización (CoA):

La opción Send Message-Authenticator es una función anterior, la nueva opción es Message-Authenticator Required on response. Cisco ISE envía el atributo de autenticador de mensaje si se marca la casilla de verificación Message-Authenticator Required on response, independientemente de si Send Message-Authenticator está marcada o no. Send Message-Authenticator se conserva para las configuraciones existentes. Si el NAD no incluye el autenticador de mensaje en la respuesta de CoA, se observa el siguiente error en el informe de autenticación detallado disponible a través de Live Logs:

No se pueden modificar los perfiles de dispositivo de red proporcionados por Cisco predeterminados. Para utilizar la nueva opción, se puede duplicar el perfil de dispositivo de red y activar la configuración en el perfil duplicado. Los dispositivos de red deben tener asignado el perfil de dispositivo de red recién creado. Esto se hizo para reducir el riesgo de provocar una interrupción de la red tras un parche o una actualización mediante la introducción de una incompatibilidad entre Cisco ISE y los NAD existentes. Si se está utilizando un perfil definido por el usuario existente, se recomienda duplicarlo y probar al menos 1 de cada tipo de dispositivo en la red que utilice ese perfil antes de realizar un cambio en el perfil de dispositivo de red existente.

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
2.0	21-Aug-2026	Formato principal, cambios de texto alternativo, sección Introducción, Vínculos
1.0	07-Aug-2024	Versión inicial