Eindämmung des Blast-RADIUS-Protokoll-Spoofing (CVE-2024-3596)

Einleitung

In diesem Dokument wird beschrieben, wie Sie Blast RADIUS-Protokoll-Spoofing eindämmen können.

Überblick

Am 7. Juli 2024 enthüllten Sicherheitsforscher diese Schwachstelle im RADIUS-Protokoll: CVE-2024-3596: Das RADIUS-Protokoll unter RFC 2865 ist anfällig für Fälschungsangriffe durch einen On-Path-Angreifer, der jede gültige Antwort (Access-Accept, Access-Reject oder Access-Challenge) auf eine beliebige andere Antwort ändern kann, indem ein ausgewählter Präfix-Kollisionsangriff auf die MD5 Response Authenticator-Signatur verwendet wird. Sie haben einen Bericht veröffentlicht, in dem sie ihre Ergebnisse in diesem Whitepaper ausführlich darstellen. Darin wird eine erfolgreiche Fälschung von Reaktionen auf Datenflüsse veranschaulicht, die das Message-Authenticator-Attribut nicht verwenden.

Eine aktuelle Liste der von dieser Sicherheitslücke betroffenen Cisco Produkte und der Versionen, die Korrekturen enthalten, finden Sie unter: Spoofing-Schwachstelle im RADIUS-Protokoll (Blast-RADIUS): Juli 2024. In diesem Artikel werden allgemeine Eindämmungstechniken beschrieben und erläutert, wie diese auf einige, jedoch nicht auf alle Cisco Produkte angewendet werden. Nähere Informationen finden Sie in der jeweiligen Produktdokumentation. Als RADIUS-Server, das Flaggschiff von Cisco, wird die Cisco Identity Service Engine ausführlicher behandelt.

Hintergrund

Dieser Angriff nutzt einen MD5-Selected-Prefix-Angriff, bei dem Kollisionen in MD5 verwendet werden, wodurch ein Angreifer dem RADIUS-Antwortpaket zusätzliche Daten hinzufügen und gleichzeitig vorhandene Attribute des Antwortpakets ändern kann. Ein Beispiel hierfür war die Möglichkeit, eine RADIUS Access-Reject in eine RADIUS Access-Accept zu ändern. Dies ist möglich, da RADIUS standardmäßig keinen Hash aller Attribute im Paket enthält. RFC 2869 fügt das Message-Authenticator-Attribut hinzu, es muss jedoch derzeit nur bei Verwendung von EAP-Protokollen eingeschlossen werden. Dies bedeutet, dass der in CVE-2024-3596 beschriebene Angriff gegen jeden Nicht-EAP-Austausch möglich ist, bei dem der RADIUS-Client (NAD) das Message-Authenticator-Attribut nicht enthält.

Eindämmung

Message-Authenticator

1.- Der RADIUS-Client muss ein Message-Authenticator-Attribut enthalten.

Wenn das Netzwerkzugriffsgerät (Network Access Device, NAD) das Message-Authenticator-Attribut in die Access-Request-Nachricht einbindet, enthält die Cisco Identity Services Engine Message-Authenticator in allen Versionen des resultierenden Access-Accept-, Access-Challenge- oder Access-Reject-Pakets.

2.- Der RADIUS-Server muss den Empfang des Message-Authenticator-Attributs erzwingen.

Es reicht nicht aus, nur den Message-Authenticator in die Access-Request einzubeziehen, da der Angriff es ermöglicht, den Message-Authenticator aus der Access-Request zu entfernen, bevor er an den RADIUS-Server weitergeleitet wird. Außerdem muss der RADIUS-Server vom NAD verlangen, dass Message-Authenticator in die Access-Request aufgenommen wird. Dies ist nicht die Standardeinstellung für die Cisco Identity Services Engine, kann jedoch auf der Ebene der zulässigen Protokolle aktiviert werden, die auf der Ebene des Richtliniensatzes angewendet wird. Die Option unter der Konfiguration für zulässige Protokolle lautet Message-Authenticator für alle RADIUS-Anforderungen anfordern:

Option für zulässige Protokolle in Identity Services Engine

Authentifizierungen, die einem Richtliniensatz entsprechen, bei dem die Konfiguration für zulässige Protokolle Message-Authenticator erfordert, die Access-Request jedoch nicht das Message-Authenticator-Attribut enthält, werden von ISE verworfen:

Es ist wichtig, zu überprüfen, ob der NAD Message Authenticator sendet, bevor er vom RADIUS-Server benötigt wird, da es sich nicht um ein ausgehandeltes Attribut handelt. Es ist Sache des NAD, dieses entweder standardmäßig zu senden oder so konfiguriert zu sein, dass es gesendet wird. Message-Authenticator ist keines der Attribute, die von der ISE gemeldet werden. Eine Paketerfassung ist die beste Methode, um zu bestimmen, ob ein NAD/Anwendungsfall Message-Authenticator enthält. Die ISE verfügt über eine integrierte Paketerfassungsfunktion unter Vorgänge > Fehlerbehebung > Diagnosetools > Allgemeine Tools > TCP-Dump. Beachten Sie, dass unterschiedliche Anwendungsfälle von derselben NAD entweder Message-Authenticator enthalten oder nicht enthalten können.

Dies ist eine Beispielerfassung einer Access-Request, die das Message-Authenticator-Attribut enthält:

Message-Authenticator-Attribut in Radius-Zugriffsanforderung

Dies ist eine Beispielerfassung einer Access-Request, die das Message-Authenticator-Attribut nicht enthält:

Verschlüsseln mit TLS/IPSec

Die effektivste langfristige Lösung zur Sicherung von RADIUS besteht in der Verschlüsselung des Datenverkehrs zwischen dem RADIUS-Server und dem NAD. Dadurch wird sowohl Datenschutz als auch kryptografische Integrität gewährleistet, da Sie sich nicht nur auf den MD5-HMAC Message-Authenticator verlassen müssen. Welche dieser Optionen zwischen dem RADIUS-Server und der NAD verwendet werden können, hängt davon ab, dass beide Seiten die Verschlüsselungsmethode unterstützen.

Branchenweit werden für die TLS-Verschlüsselung von RADIUS folgende Begriffe verwendet:

• RadSec - bezieht sich auf RFC 6614
• RadSec TLS - bezieht sich auf RFC 6614
• RadSec DTLS - bezieht sich auf RFC 7360

Es ist wichtig, die Verschlüsselung kontrolliert einzuführen, da die TLS-Verschlüsselung einen Performance-Overhead verursacht und das Zertifikatsmanagement berücksichtigt wird. Auch die Zertifikate müssen regelmäßig erneuert werden.

RADIUS über DTLS

Datagram Transport Layer Security (DTLS) als Transport Layer für RADIUS wird durch RFC 7360 definiert, das Zertifikate für die gegenseitige Authentifizierung des RADIUS-Servers verwendet, und der NAD verschlüsselt dann das vollständige RADIUS-Paket mithilfe eines TLS-Tunnels. Die Transportmethode bleibt UDP und erfordert die Bereitstellung von Zertifikaten sowohl auf dem RADIUS-Server als auch auf NAD. Beachten Sie, dass bei der Bereitstellung von RADIUS über DTLS das Ablaufdatum und der Austausch von Zertifikaten eng verwaltet werden müssen, damit abgelaufene Zertifikate die RADIUS-Kommunikation nicht unterbrechen. Die ISE unterstützt DTLS für die Kommunikation zwischen ISE und NAD, da der Radius über DTLS für ISE 3.4 für RADIUS-Proxy- oder RADIUS-Token-Server nicht unterstützt wird. RADIUS über DTLS wird auch von vielen Cisco Geräten unterstützt, die als NADs fungieren, z. B. Switches und Wireless-Controller, auf denen Cisco IOS-XE® ausgeführt wird.

RADIUS über TLS

Transport Layer Security (TLS) Encryption for RADIUS wird von RFC 6614 definiert, ändert den Transport zu TCP und verwendet TLS zur vollständigen Verschlüsselung von RADIUS-Paketen. Dies wird vom eduroam-Dienst häufig als Beispiel verwendet. Ab ISE 3.4 wird RADIUS over TLS nicht mehr unterstützt, jedoch von vielen Cisco Geräten, die als NADs fungieren, wie Switches und Wireless-Controller, auf denen Cisco IOS-XE ausgeführt wird.

IPsec

Identity Services Engine bietet native Unterstützung für IPSec-Tunnel zwischen ISE und NADs, die auch terminierende IPSec-Tunnel unterstützen. Dies ist eine gute Option, wenn RADIUS über DTLS oder RADIUS über TLS nicht unterstützt wird, aber sparsam verwendet werden muss, da pro ISE Policy Services Node nur 150 Tunnel unterstützt werden. ISE 3.3 und höher erfordern keine Lizenz für IPSec mehr. Sie ist jetzt nativ verfügbar.

Teilweise Eindämmung

RADIUS-Segmentierung

Segmentierung des RADIUS-Datenverkehrs in Management-VLANs und sichere, verschlüsselte Verbindungen, wie sie über SD-WAN oder MACSec bereitgestellt werden können Diese Strategie bringt das Risiko des Angriffs nicht auf Null, kann jedoch die Angriffsfläche der Schwachstelle erheblich verringern. Dies kann eine gute Stopp-Gap-Messgröße sein, wenn Produkte die Message-Authenticator-Anforderung erfüllen oder DTLS/RadSec unterstützen. Der Exploit erfordert, dass ein Angreifer die RADIUS-Kommunikation (Man-in-the-Middle, MITM) erfolgreich durchführt. Wenn ein Angreifer mit diesem Datenverkehr nicht in ein Netzwerksegment gelangen kann, ist der Angriff nicht möglich. Dies ist nur eine teilweise Reduzierung, da der RADIUS-Datenverkehr durch eine falsche Netzwerkkonfiguration oder eine Kompromittierung eines Teils des Netzwerks verfügbar gemacht werden kann.

Wenn der RADIUS-Datenverkehr nicht segmentiert oder nicht verschlüsselt werden kann, können zusätzliche Funktionen implementiert werden, um erfolgreiches MITM in risikobehafteten Segmenten zu verhindern, z. B.: IP Source Guard, Dynamic ARP Inspection und DHCP Snooping. Es ist auch möglich, andere Authentifizierungsmethoden auf Basis des Authentifizierungsflusstyps wie TACACS+, SAML, LDAPS usw. zu verwenden.

Schwachstellenstatus der Identity Services Engine

In diesen Tabellen wird beschrieben, welche Funktionen von Cisco ISE 3.4 zum Schutz von Authentifizierungsflüssen vor Blast-RADIUS verfügbar sind.

Um es noch einmal zusammenzufassen: Die folgenden drei Elemente müssen für einen Datenfluss vorhanden sein, der nur Message-Authenticator und keine DTLS/RadSec/IPSec-Verschlüsselung verwendet, damit der Datenfluss nicht anfällig ist:

• Das Netzwerkzugriffsgerät MUSS das Message-Authenticator-Attribut in der Access-Request senden.
• Der RADIUS-Server MUSS das Message-Authenticator-Attribut in der Access-Request benötigen.
• Der RADIUS-Server MUSS mit dem Message-Authenticator-Attribut in den Feldern "Access-Challenge", "Access-Accept" und "Access-Reject" reagieren.

Die Bug-ID CSCwk67747 verfolgt die Änderungen und schließt die Schwachstellen, wenn die Cisco ISE als RADIUS-Client agiert.

ISE als RADIUS-Server

ISE als RADIUS-Client

ISE als RADIUS-Client-Update

Neuerungen an der Cisco ISE, die als RADIUS-Client fungiert, sind in den folgenden Versionen enthalten: 3.1 Patch 10, 3.2 Patch 8, 3.3 Patch 5, 3.4 Patch 2, 3.5 und neuere Versionen über die Cisco Bug-ID CSCwk67747. Nach dem Patch oder Upgrade wird jede neue Ressource standardmäßig auf die neue, sicherere Konfiguration zurückgesetzt. Vorhandene Ressourcen müssen geändert werden, um die sicherere Konfiguration nach Patches oder Upgrades verwenden zu können. Ein neues Kontrollkästchen wurde hinzugefügt: "Message Authenticator Required On Response" (Nachrichtenauthentifizierer bei Antwort erforderlich): Wenn diese Option aktiviert ist, erfüllt sie einen doppelten Zweck: Die Cisco ISE sendet immer Message Authenticator und schlägt bei der Authentifizierung fehl, wenn eine Antwort ohne Message Authenticator empfangen wird. Das Verhalten ist wie folgt:

Gehäuse	NAD beinhaltete Message Authenticator in Anfrage	NAD hat den Nachrichtenauthentifizierer nicht in die Anforderung aufgenommen.
Vor Patch/Upgrade	ISE sendet Message Authenticator an das RADIUS-Token, den externen RADIUS-Server oder CoA	ISE sendet keinen Message Authenticator an das RADIUS-Token, den externen RADIUS-Server oder CoA
Nach Patch/Upgrade und Message Authenticator bei Antwort erforderlich ist deaktiviert.	ISE sendet Message Authenticator an das RADIUS-Token, den externen RADIUS-Server oder CoA	Die ISE sendet keinen Message Authenticator an das RADIUS-Token, den externen RADIUS-Server oder den CoA.
Nach Patch/Upgrade und Message Authenticator bei Antwort erforderlich ist aktiviert.	ISE sendet Message Authenticator an das RADIUS-Token, den externen RADIUS-Server oder CoA	ISE sendet Message Authenticator an das RADIUS-Token, den externen RADIUS-Server oder CoA

RADIUS-Token-Server

Ein neues Kontrollkästchen: Message Authenticator Required On Response (Nachrichtenauthentifizierung bei Antwort erforderlich) wurde auf der Registerkarte Authentication (Authentifizierung) für die RADIUS Token Server-Konfiguration hinzugefügt:

Wenn das Kontrollkästchen aktiviert ist und eine RADIUS-Antwort ohne Message Authenticator empfangen wird, wird eine Fehlermeldung im detaillierten Authentifizierungsprotokoll protokolliert, auf das über Live-Protokolle oder einen RADIUS-Authentifizierungsbericht zugegriffen werden kann:

Externer RADIUS-Server

Ein neues Kontrollkästchen: Der bei Antwort erforderliche Nachrichtenauthentifizierer wurde der Konfiguration des externen RADIUS-Servers hinzugefügt:

Wenn das Kontrollkästchen aktiviert ist und eine RADIUS-Antwort ohne Message Authenticator empfangen wird, wird eine Fehlermeldung im detaillierten Authentifizierungsprotokoll protokolliert, auf das über Live-Protokolle oder einen RADIUS-Authentifizierungsbericht zugegriffen werden kann:

Autorisierungsänderung (CoA)

Die CoA-Änderungen wurden an den Netzwerkgeräteprofilen unter der Mappe "Autorisierungsänderung (CoA)" vorgenommen:

Die Option Send Message-Authenticator (Nachrichtenauthentifizierer senden) ist eine vorherige Funktion, die neue Option ist Message-Authenticator Required (Nachrichtenauthentifizierer bei Antwort erforderlich). Die Cisco ISE sendet das Message Authenticator-Attribut, wenn Message-Authenticator Required bei Antwort geprüft wird, unabhängig davon, ob Send Message-Authenticator aktiviert ist oder nicht. Message-Authenticator senden wird für vorhandene Konfigurationen beibehalten. Wenn Message Authenticator (NAD) nicht in der CoA-Antwort enthalten ist, wird der folgende Fehler im detaillierten Authentifizierungsbericht angezeigt, der über Live-Protokolle verfügbar ist:

Die von Cisco bereitgestellten Standardprofile für Netzwerkgeräte können nicht geändert werden. Um die neue Option zu verwenden, kann das Netzwerkgeräteprofil dupliziert werden, und die Einstellung kann für das duplizierte Profil aktiviert werden. Netzwerkgeräten muss dann das neu erstellte Netzwerkgeräteprofil zugewiesen werden. Auf diese Weise wurde das Risiko eines Netzwerkausfalls nach einem Patch oder Upgrade durch die Einführung einer Inkompatibilität zwischen der Cisco ISE und vorhandenen NADs verringert. Wenn ein vorhandenes benutzerdefiniertes Profil verwendet wird, wird empfohlen, dieses Profil zu duplizieren und mindestens einen Gerätetyp im Netzwerk mit diesem Profil zu testen, bevor eine Änderung am vorhandenen Netzwerkgeräteprofil vorgenommen wird.

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
2.0	21-Aug-2026	Wichtige Formatierungen, Änderungen bei Alternativtext, Einführungsabschnitt, Links
1.0	07-Aug-2024	Erstveröffentlichung