Table des matières

Introduction

Le 7 juillet 2024, des chercheurs en sécurité ont révélé la vulnérabilité suivante dans le protocole RADIUS : CVE-2024-3596 : Le protocole RADIUS dans le cadre de la RFC 2865 est susceptible d'être attaqué par un pirate sur le chemin qui peut modifier n'importe quelle réponse valide (Access-Accept, Access-Reject ou Access-Challenge) à n'importe quelle autre réponse en utilisant une attaque de collision de préfixe choisi contre la signature de l'authentificateur de réponse MD5. Ils ont publié un document détaillant leurs résultats à l'adresse https://www.blastradius.fail/pdf/radius.pdf qui démontre une falsification de réponse réussie contre les flux qui n'utilisent pas l'attribut Message-Authenticator.

Pour obtenir une liste à jour des produits Cisco affectés par cette vulnérabilité et des versions contenant des correctifs, consultez le site : https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-radius-spoofing-july-2024-87cCDwZ3. Cet article traite des techniques générales d'atténuation et de leur application à certains produits Cisco, mais pas à tous. Pour plus d'informations, consultez la documentation de chaque produit. En tant que serveur RADIUS phare de Cisco, Identity Service Engine sera traité plus en détail.

Fond

Cette attaque tire parti d'une attaque à préfixe choisi MD5 utilisant des collisions dans MD5, ce qui permet à un attaquant d'ajouter des données supplémentaires au paquet de réponse RADIUS tout en modifiant les attributs existants du paquet de réponse. Un exemple démontré a été la capacité de changer un RADIUS Access-Reject en un RADIUS Access-Accept. Cela est possible parce que RADIUS par défaut n'inclut pas de hachage de tous les attributs dans le paquet. Le document RFC 2869 ajoute l'attribut Message-Authenticator, mais il n'est actuellement requis que pour l'utilisation des protocoles EAP, ce qui signifie que l'attaque décrite dans CVE-2024-3596 est possible contre tout échange non-EAP où le client RADIUS (NAD) n'inclut pas l'attribut Message-Authenticator.

Atténuation

Authentificateur De Message

1) Le client RADIUS doit inclure l'attribut Message-Authenticator.

Lorsque le périphérique d'accès réseau (NAD) inclut l'attribut Message-Authenticator dans la demande d'accès, Identity Services Engine inclut Message-Authenticator dans le paquet Access-Accept, Access-Challenge ou Access-Reject résultant dans toutes les versions.

2) Le serveur RADIUS doit imposer la réception de l'attribut Message-Authenticator.

Il ne suffit pas d'inclure l'authentificateur de message dans la demande d'accès, car l'attaque permet de supprimer l'authentificateur de message de la demande d'accès avant qu'elle ne soit transférée au serveur RADIUS. Le serveur RADIUS doit également exiger que le NAD inclue Message-Authenticator dans la demande d'accès. Ce n'est pas la valeur par défaut sur Identity Services Engine, mais elle peut être activée au niveau des protocoles autorisés, qui s'applique au niveau du jeu de stratégies. L'option sous la configuration des protocoles autorisés est "Require Message-Authenticator" pour toutes les requêtes RADIUS" :

Option Protocoles autorisés dans Identity Services Engine

Les authentifications qui correspondent à un ensemble de stratégies où la configuration des protocoles autorisés nécessite Message-Authenticator, mais où la demande d'accès ne contient pas l'attribut Message-Authenticator seront abandonnées par ISE :

Il est important de vérifier si le NAD envoie Message-Authenticator avant d'être requis par le serveur RADIUS car il ne s'agit pas d'un attribut négocié, il appartient au NAD de l'envoyer par défaut ou d'être configuré pour l'envoyer. Message-Authenticator n'est pas l'un des attributs signalés par ISE, une capture de paquets est la meilleure façon de déterminer si un NAD/Cas d'utilisation inclut Message-Authenticator. ISE intègre une fonctionnalité de capture de paquets sous Opérations -> Dépannage -> Outils de diagnostic -> Outils généraux -> Dépôt TCP. Gardez à l'esprit que différents cas d'utilisation du même NAD peuvent inclure ou non Message-Authenticator.

L'exemple suivant est un exemple de capture d'une demande d'accès qui inclut l'attribut Message-Authenticator :

Attribut Message-authenticator dans la requête d'accès Radius

L'exemple suivant est un exemple de capture d'une demande d'accès qui n'inclut pas l'attribut Message-Authenticator :

Chiffrement avec TLS/IPSec

La solution à long terme la plus efficace pour sécuriser RADIUS consiste à chiffrer le trafic entre le serveur RADIUS et le NAD. Ceci ajoute à la fois la confidentialité et une intégrité cryptographique plus forte que le simple fait de se fier à l'authentificateur de message dérivé de MD5-HMAC. Si l'un de ces éléments peut être utilisé entre le serveur RADIUS et le NAD, cela dépend de la prise en charge de la méthode de cryptage par les deux parties.

Les termes généraux utilisés dans le secteur pour le chiffrement TLS de RADIUS sont les suivants :

- « RadSec » - fait référence à la norme RFC 6614

- « RadSec TLS » - fait référence à RFC 6614

- « RadSec DTLS » - fait référence à RFC 7360

Il est important de déployer le cryptage de manière contrôlée, car le cryptage TLS est surchargé en termes de performances et de gestion des certificats. Les certificats devront également être renouvelés sur une base régulière.

RADIUS sur DTLS

Le protocole DTLS (Datagram Transport Layer Security) en tant que couche de transport pour RADIUS est défini par la RFC 7360 qui utilise des certificats pour authentifier mutuellement le serveur RADIUS et le NAD chiffre ensuite le paquet RADIUS complet à l'aide d'un tunnel TLS. La méthode de transport reste UDP et nécessite le déploiement de certificats sur le serveur RADIUS et NAD. Gardez à l'esprit que lors du déploiement de RADIUS sur DTLS, il est impératif que l'expiration et le remplacement des certificats soient étroitement gérés pour empêcher les certificats expirés d'interrompre la communication RADIUS. ISE prend en charge DTLS pour les communications ISE à NAD, car à partir de la version ISE 3.4, Radius sur DTLS n'est pas pris en charge pour les serveurs proxy RADIUS ou les serveurs à jetons RADIUS. RADIUS sur DTLS est également pris en charge par de nombreux périphériques Cisco qui agissent en tant que NAD, tels que des commutateurs et des contrôleurs sans fil exécutant IOS-XE®.

RADIUS sur TLS

Le chiffrement TLS (Transport Layer Security) pour RADIUS est défini par la RFC 6614, modifie le transport en TCP et utilise TLS pour chiffrer entièrement les paquets RADIUS. C'est un exemple couramment utilisé par le service eduroam. Depuis ISE 3.4, RADIUS sur TLS n'est pas pris en charge, mais il est pris en charge par de nombreux périphériques Cisco qui agissent en tant que NAD, tels que des commutateurs et des contrôleurs sans fil exécutant IOS-XE.

IPSEC

Identity Services Engine prend en charge de manière native les tunnels IPSec entre ISE et NAD, qui prennent également en charge les tunnels IPSec de fin. Il s'agit d'une bonne option où RADIUS sur DTLS ou RADIUS sur TLS n'est pas pris en charge, mais doit être utilisé avec parcimonie, car seuls 150 tunnels sont pris en charge par noeud de services de stratégie ISE. ISE 3.3 et versions ultérieures n'exige plus de licence pour IPSec ; elle est désormais disponible en mode natif.

Atténuation partielle

Segmentation RADIUS

Segmenter le trafic RADIUS vers les VLAN de gestion et les liaisons chiffrées sécurisées, telles que celles fournies via SD-WAN ou MACSec. Cette stratégie ne réduit pas le risque d'attaque à zéro, mais peut réduire considérablement la surface d'attaque de la vulnérabilité. Il peut s'agir d'une bonne mesure d'interruption pendant que les produits déploient la configuration requise pour Message-Authenticator ou la prise en charge DTLS/RadSec. L'attaque nécessite qu'un pirate réussisse à faire fonctionner la communication RADIUS avec le mode « Man-in-the-Middle » (MITM). Ainsi, si un pirate ne parvient pas à accéder à un segment de réseau avec ce trafic, l'attaque n'est pas possible. La raison pour laquelle ce problème n'est qu'une atténuation partielle est qu'une configuration incorrecte ou une compromission d'une partie du réseau peut exposer le trafic RADIUS.

Si le trafic RADIUS ne peut pas être segmenté ou chiffré, des fonctionnalités supplémentaires peuvent être implémentées pour empêcher la réussite de la MITM sur les segments à risque tels que : Protection de la source IP, inspection ARP dynamique et surveillance DHCP. Il peut également être possible d'utiliser d'autres méthodes d'authentification basées sur le type de flux d'authentification comme TACACS+, SAML, LDAPS, etc...

État de vulnérabilité Identity Services Engine

Les tableaux ci-dessous décrivent les éléments disponibles dans ISE 3.4 pour protéger les flux d'authentification contre Blast-RADIUS. Pour récapituler, les 3 éléments suivants doivent être en place pour un flux utilisant uniquement Message-Authenticator et non le chiffrement DTLS/RadSec/IPSec, pour que le flux ne soit pas vulnérable :

1) Le périphérique d'accès réseau DOIT envoyer l'attribut Message-Authenticator dans la requête d'accès.

2) Le serveur RADIUS DOIT exiger l'attribut Message-Authenticator dans la demande d'accès.

3) Le serveur RADIUS DOIT répondre avec l'attribut Message-Authenticator dans Access-Challenge, Access-Accept et Access-Reject.

Reportez-vous au document CSCwk67747 qui suit les modifications pour fermer les vulnérabilités lorsque ISE agit en tant que client RADIUS.

ISE comme serveur RADIUS

ISE comme client RADIUS

ISE en tant que client RADIUS Mises à jour

Les améliorations apportées à ISE en tant que client RADIUS sont incluses dans les versions suivantes : 3.1 correctif 10, 3.2 correctif 8, 3.3 correctif 5, 3.4 correctif 2, 3.5 et versions ultérieures via CSCwk67747. Après l'application du correctif ou de la mise à niveau, toute nouvelle ressource créée adopte par défaut la nouvelle configuration, plus sécurisée. Les ressources existantes doivent être modifiées pour utiliser le correctif ou la mise à niveau post-configuration plus sécurisée. Une nouvelle case à cocher a été ajoutée : "Message Authenticator Required On Response", si cette case est cochée, il a un double objectif : ISE envoie toujours l'authentificateur de message et l'authentification échoue si une réponse est reçue sans authentificateur de message. Le comportement est le suivant :

Boîtier

NAD a inclus Message Authenticator dans la demande

NAD n'a pas inclus Message Authenticator dans la demande

Avant le correctif/la mise à niveau

ISE va envoyer l'authentificateur de message au jeton RADIUS, au serveur RADIUS externe ou à la CoA

ISE n'envoie pas l'authentificateur de message au jeton RADIUS, au serveur RADIUS externe ou à la CoA

Après le correctif/la mise à niveau et la case « Authentificateur de message requis en réponse » est décochée.

ISE va envoyer l'authentificateur de message au jeton RADIUS, au serveur RADIUS externe ou à la CoA

ISE n'envoie pas l'authentificateur de message au jeton RADIUS, au serveur RADIUS externe ou à la CoA

Après le correctif/la mise à niveau et la case « Authentificateur de message requis en réponse » est cochée.

ISE va envoyer l'authentificateur de message au jeton RADIUS, au serveur RADIUS externe ou à la CoA

ISE va envoyer l'authentificateur de message au jeton RADIUS, au serveur RADIUS externe ou à la CoA

Serveur de jetons RADIUS

Une nouvelle case à cocher « Message Authenticator Required On Response » a été ajoutée sous l'onglet Authentication pour la configuration du serveur de jetons RADIUS :

Lorsque cette case est cochée, si une réponse RADIUS est reçue sans l'authentificateur de message, un message d'échec est consigné dans le journal d'authentification détaillé, auquel vous pouvez accéder via les journaux en direct ou un rapport d'authentification RADIUS :

**Remarque: L'authentification globale peut toujours passer en fonction de la configuration de la stratégie, par le biais de l'authentification peut correspondre à une stratégie inattendue.

Serveur RADIUS externe

Une nouvelle case à cocher « Authentificateur de message requis en réponse » a été ajoutée à la configuration du serveur RADIUS externe :

Lorsque cette case est cochée, si une réponse RADIUS est reçue sans l'authentificateur de message, un message d'échec est consigné dans le journal d'authentification détaillé, auquel vous pouvez accéder via les journaux en direct ou un rapport d'authentification RADIUS :

**Remarque: L'authentification globale peut toujours passer en fonction de la configuration de la stratégie, par le biais de l'authentification peut correspondre à une stratégie inattendue.

Changement d'autorisation (CoA)

Les modifications CoA ont été apportées aux profils de périphériques réseau dans le tiroir Modification d'autorisation (CoA) :

L'option « Envoyer l'authentificateur de message » est une fonctionnalité précédente, la nouvelle option est « Message-Authenticator Required on response ». ISE envoie l'attribut d'authentificateur de message si la case Message-Authenticator Required on response est cochée, que la case Send Message-Authenticator soit cochée ou non. « Send Message-Authenticator » est conservé pour les configurations existantes. Si le NAD n'inclut pas l'authentificateur de message dans la réponse CoA, l'erreur suivante apparaît dans le rapport d'authentification détaillé disponible via Live Logs :

**Remarque: Le CoA peut réussir sur le NAD même si une défaillance est enregistrée sur ISE car le NAD a peut-être traité le CoA mais n'a pas inclus l'authentificateur de message dans la réponse.

Les profils de périphérique réseau « fournis par Cisco » par défaut ne peuvent pas être modifiés. Pour utiliser la nouvelle option, le profil de périphérique réseau peut être dupliqué et le paramètre activé sur le profil dupliqué. Les périphériques réseau devront alors se voir attribuer le profil de périphérique réseau nouvellement créé. Cela a été fait pour réduire le risque de provoquer une panne du réseau à la suite d'un correctif ou d'une mise à niveau en introduisant une incompatibilité entre ISE et les NAD existants. Si un profil défini par l'utilisateur existant est en cours d'utilisation, il est recommandé de dupliquer ce profil et de tester au moins 1 de chaque type de périphérique sur le réseau à l'aide de ce profil avant d'apporter une modification au profil de périphérique réseau existant.