In dit document wordt beschreven hoe Blast RADIUS-protocolspoofing kan worden beperkt.
Op 7 juli 2024 onthulden beveiligingsonderzoekers deze kwetsbaarheid in het RADIUS-protocol: CVE-2024-3596: RADIUS Protocol onder RFC 2865 is gevoelig voor vervalsingsaanvallen door een on-path-aanvaller die elke geldige reactie (Access-Accept, Access-Reject of Access-Challenge) kan wijzigen op elke andere reactie met behulp van een gekozen prefix-botsing aanval tegen MD5 Response Authenticator-handtekening. Ze hebben een paper gepubliceerd waarin hun bevindingen in dit witboek worden beschreven, waarin een succesvolle reactie wordt getoond op vervalsing van stromen die het kenmerk Message-Authenticator niet gebruiken.
Voor een bijgewerkte lijst van Cisco-producten die door deze kwetsbaarheid zijn getroffen en versies die oplossingen bevatten, gaat u naar: RADIUS Protocol Spoofing Vulnerability (Blast-RADIUS): juli 2024. Dit artikel behandelt algemene mitigatietechnieken en hoe ze van toepassing zijn op sommige, maar niet alle Cisco-producten, individuele productdocumentatie moet worden geraadpleegd voor specifieke gegevens. Als vlaggenschip van Cisco RADIUS-server wordt Cisco Identity Service Engine gedetailleerder behandeld.
Deze aanval maakt gebruik van een MD5-gekozen prefix-aanval met behulp van botsingen in MD5, waarmee een aanvaller extra gegevens aan het RADIUS-responspakket kan toevoegen terwijl bestaande kenmerken van het responspakket worden gewijzigd. Een voorbeeld hiervan is de mogelijkheid om een RADIUS Access-Reject te wijzigen in een RADIUS Access-Accept. Dit is mogelijk omdat RADIUS standaard geen hash van alle attributen in het pakket bevat. RFC 2869 voegt wel het Message-Authenticator-kenmerk toe, maar het is momenteel alleen vereist om te worden opgenomen bij het gebruik van EAP-protocollen, wat betekent dat de aanval die wordt beschreven in CVE-2024-3596 mogelijk is tegen elke niet-EAP-uitwisseling waarbij de RADIUS-client (NAD) niet het Message-Authenticator-kenmerk bevat.
1.- De RADIUS-client moet het kenmerk Message-Authenticator bevatten.
Wanneer het Network Access Device (NAD) het Message-Authenticator-kenmerk in het Access-Request bevat, bevat Cisco Identity Services Engine Message-Authenticator in het resulterende Access-Accept-, Access-Challenge- of Access-Reject-pakket in alle versies.
2.- De RADIUS-server moet de ontvangst van het Message-Authenticator-kenmerk afdwingen.
Het volstaat niet om alleen de Message-Authenticator in de Access-Request op te nemen, omdat de aanval het mogelijk maakt om de Message-Authenticator uit de Access-Request te verwijderen voordat deze naar de RADIUS-server wordt doorgestuurd. De RADIUS-server moet de NAD ook verplichten Message-Authenticator op te nemen in de Access-Request. Dit is niet standaard op Cisco Identity Services Engine, maar kan worden ingeschakeld op het toegestane protocolniveau, dat van toepassing is op het niveau van de beleidsset. De optie onder de configuratie Toegestane protocollen is Berichtenverificator vereisen voor alle RADIUS-aanvragen:
Optie Toegestane protocollen in de engine Identity Services
Verificaties die overeenkomen met een beleidsset waarbij de configuratie Toegestane protocollen Message-Authenticator vereist, maar waarbij het Access-Request niet het Message-Authenticator-kenmerk bevat, worden door ISE gedropt:

Het is belangrijk om te controleren of de NAD Message-Authenticator verzendt voordat deze door de RADIUS-server wordt vereist, aangezien dit geen onderhandeld attribuut is, is het aan de NAD om het standaard te verzenden of te worden geconfigureerd om het te verzenden. Message-Authenticator is niet een van de attributen die door ISE worden gerapporteerd, een pakketopname is de beste manier om te bepalen of een NAD / Use Case Message-Authenticator bevat. ISE heeft ingebouwde pakketopnamefunctionaliteit onder Operations > Troubleshoot > Diagnostic Tools > General Tools > TCP Dump. Houd er rekening mee dat verschillende use cases van dezelfde NAD al dan niet Message-Authenticator kunnen bevatten.
Dit is een voorbeeld van een Access-Request met het Message-Authenticator attribuut:
Message-authenticator attribuut in Radius access-request
Dit is een voorbeeld van een Access-Request die niet het Message-Authenticator attribuut bevat:

De meest effectieve langetermijnoplossing voor het beveiligen van RADIUS is het versleutelen van het verkeer tussen de RADIUS-server en de NAD. Dit voegt zowel privacy als een sterkere cryptografische integriteit toe ten opzichte van het vertrouwen op de MD5-HMAC-afgeleide Message-Authenticator. Welke, als een van deze kan worden gebruikt tussen de RADIUS-server en de NAD, is afhankelijk van beide zijden die de coderingsmethode ondersteunen.
De algemene termen die in de industrie worden gebruikt voor TLS-codering van RADIUS zijn:
Het is belangrijk om encryptie op een gecontroleerde manier uit te rollen, omdat er prestatieoverhead is voor TLS-encryptie en overwegingen voor certificaatbeheer. Certificaten moeten ook regelmatig worden vernieuwd.
Datagram Transport Layer Security (DTLS) als transportlaag voor RADIUS wordt gedefinieerd door RFC 7360 die certificaten gebruikt om de RADIUS-server wederzijds te verifiëren en de NAD versleutelt vervolgens het volledige RADIUS-pakket met behulp van een TLS-tunnel. De transportmethode blijft UDP en vereist dat certificaten worden geïmplementeerd op zowel de RADIUS-server als NAD. Houd er rekening mee dat het bij de implementatie van RADIUS via DTLS noodzakelijk is dat het verlopen en vervangen van certificaten nauwgezet wordt beheerd om te voorkomen dat verlopen certificaten de RADIUS-communicatie onderbreken. ISE ondersteunt DTLS voor ISE naar NAD communicatie, vanaf ISE 3.4 Radius over DTLS wordt niet ondersteund voor RADIUS-Proxy of RADIUS Token Servers. RADIUS over DTLS wordt ook ondersteund door veel Cisco-apparaten die fungeren als NAD's, zoals switches en draadloze controllers met Cisco IOS-XE®.
Transport Layer Security (TLS)-codering voor RADIUS wordt gedefinieerd door RFC 6614, verandert het transport naar TCP en gebruikt TLS om RADIUS-pakketten volledig te coderen. Dit wordt vaak gebruikt door de eduroam-service als voorbeeld. Vanaf ISE 3.4 wordt RADIUS over TLS niet ondersteund, maar wordt het ondersteund door veel Cisco-apparaten die fungeren als NAD's, zoals switches en draadloze controllers met Cisco IOS-XE.
Identity Services Engine heeft native ondersteuning voor IPSec-tunnels tussen ISE en NAD's die ook ondersteuning bieden voor het beëindigen van IPSec-tunnels. Dit is een goede optie waarbij RADIUS over DTLS of RADIUS over TLS niet wordt ondersteund, maar spaarzaam moet worden gebruikt, aangezien slechts 150 tunnels worden ondersteund per ISE Policy Services Node. ISE 3.3 en later geen licentie meer nodig voor IPSec, het is nu native beschikbaar.
Segmenteer RADIUS-verkeersbeheer naar VLAN's en beveiligde, gecodeerde koppelingen zoals die kunnen worden geleverd via SD-WAN of MACSec. Deze strategie brengt het risico van de aanval niet op nul, maar kan het aanvalsoppervlak van de kwetsbaarheid sterk verminderen. Dit kan een goede stop gap-maatregel zijn terwijl producten de Message-Authenticator-vereiste of DTLS / RadSec-ondersteuning uitrollen. De exploit vereist dat een aanvaller met succes Man-in-the-Middle (MITM) de RADIUS-communicatie gebruikt, dus als een aanvaller niet op een netwerksegment met dat verkeer kan komen, is de aanval niet mogelijk. De reden dat dit slechts een gedeeltelijke verzachting is, is dat een verkeerde netwerkconfiguratie of een compromis van een deel van het netwerk het RADIUS-verkeer kan blootleggen.
Als RADIUS-verkeer niet kan worden gesegmenteerd of gecodeerd, kunnen aanvullende functies worden geïmplementeerd om succesvol MITM op risicosegmenten zoals: IP Source Guard, Dynamic ARP Inspection en DHCP Snooping te voorkomen. Het is ook mogelijk om andere verificatiemethoden te gebruiken op basis van het type verificatiestroom, zoals TACACS+, SAML, LDAPS en meer.
Deze tabellen beschrijven wat beschikbaar is vanaf Cisco ISE 3.4 om verificatiestromen te beschermen tegen Blast-RADIUS.
Om samen te vatten, moeten deze volgende drie items aanwezig zijn voor een stroom die alleen Message-Authenticator gebruikt en niet DTLS/RadSec/IPSec-codering, zodat de stroom niet kwetsbaar is:
Raadpleeg Cisco bug ID CSCwk67747 die de wijzigingen bijhoudt om de kwetsbaarheden te sluiten wanneer Cisco ISE optreedt als de RADIUS-client.



Verbeteringen aan Cisco ISE als een RADIUS-client zijn opgenomen in releases: 3.1 patch 10, 3.2 patch 8, 3.3 patch 5, 3.4 patch 2, 3.5 en latere releases via Cisco bug ID CSCwk67747. Na de patch of upgrade wordt elke nieuwe bron die is gemaakt standaard toegevoegd aan de nieuwe, veiligere configuratie. Bestaande bronnen moeten worden aangepast om de veiligere configuratie na patch of upgrade te kunnen gebruiken. Er is een nieuw selectievakje toegevoegd: "Message Authenticator Required On Response", indien aangevinkt dient het een tweeledig doel: Cisco ISE stuurt altijd Message Authenticator, en het faalt de authenticatie als een antwoord wordt ontvangen zonder een Message Authenticator. Het gedrag is als volgt:
zaak |
NAD heeft Message Authenticator in aanvraag opgenomen |
NAD heeft Message Authenticator niet in aanvraag opgenomen |
| Vóór patch/upgrade |
ISE stuurt Message Authenticator naar het RADIUS-token, externe RADIUS-server of CoA |
ISE stuurt geen berichtenverificator naar het RADIUS-token, de externe RADIUS-server of de CoA |
| Het selectievakje Na patch/upgrade en Message Authenticator Required On Response is uitgeschakeld. |
ISE stuurt Message Authenticator naar het RADIUS-token, externe RADIUS-server of CoA |
ISE stuurt geen berichtenverificator naar het RADIUS-token, de externe RADIUS-server of de CoA |
| Na patch/upgrade en Message Authenticator Required On Response is het selectievakje ingeschakeld. |
ISE stuurt Message Authenticator naar het RADIUS-token, externe RADIUS-server of CoA |
ISE stuurt Message Authenticator naar het RADIUS-token, de externe RADIUS-server of de CoA |
Een nieuw selectievakje: Message Authenticator Required On Response is toegevoegd onder het tabblad Verificatie voor de RADIUS Token Server-configuratie:

Als het selectievakje is ingeschakeld en er een RADIUS-antwoord wordt ontvangen zonder berichtverificatie, wordt een foutbericht geregistreerd in het gedetailleerde verificatielog dat kan worden geopend via Live Logs of een RADIUS-verificatierapport:

Opmerking: de algehele verificatie kan nog steeds worden doorgegeven op basis van de beleidsconfiguratie, maar de verificatie kan overeenkomen met een onverwacht beleid.
Een nieuw selectievakje: Message Authenticator Required On Response is toegevoegd aan de externe RADIUS-serverconfiguratie:

Als het selectievakje is ingeschakeld en er een RADIUS-antwoord wordt ontvangen zonder berichtverificatie, wordt een foutbericht geregistreerd in het gedetailleerde verificatielog dat kan worden geopend via Live Logs of een RADIUS-verificatierapport:

Opmerking: de algehele verificatie kan nog steeds worden doorgegeven op basis van de beleidsconfiguratie, maar de verificatie kan overeenkomen met een onverwacht beleid.
De wijzigingen van het CoA zijn aangebracht in de profielen van netwerkapparaten in de lade voor autorisatiewijziging (CoA):

De optie Berichtenverificator verzenden is een eerdere functie, de nieuwe optie is Berichtenverificator vereist bij reactie. Cisco ISE verzendt het kenmerk Message Authenticator als de Message-Authenticator Required on response is ingeschakeld, ongeacht of Send Message-Authenticator is ingeschakeld of niet. Send Message-Authenticator blijft behouden voor bestaande configuraties. Als de NAD Message Authenticator niet in het CoA-antwoord bevat, wordt de volgende fout weergegeven in het gedetailleerde verificatierapport dat beschikbaar is via Live Logs:

Opmerking: de CoA kan succesvol zijn op de NAD, zelfs als een storing is geregistreerd op Cisco ISE, omdat de NAD de CoA had kunnen verwerken, maar Berichtenverificator niet in de reactie had kunnen opnemen.
De standaard profielen van Cisco-netwerkapparaten kunnen niet worden gewijzigd. Als u de nieuwe optie wilt gebruiken, kan het profiel van het netwerkapparaat worden gedupliceerd en wordt de instelling ingeschakeld op het gedupliceerde profiel. Netwerkapparaten moeten vervolgens worden toegewezen aan het nieuw gemaakte netwerkapparaatprofiel. Dit werd gedaan om het risico op een netwerkstoring na een patch of upgrade te verminderen door een incompatibiliteit tussen Cisco ISE en bestaande NAD's te introduceren. Als er een bestaand door de gebruiker gedefinieerd profiel wordt gebruikt, wordt het aanbevolen dat profiel te dupliceren en ten minste 1 van elk apparaattype op het netwerk te testen met dat profiel voordat u een wijziging aanbrengt in het bestaande profiel voor netwerkapparaten.
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
2.0 |
21-Aug-2026
|
Belangrijke opmaak, Alt-tekstwijzigingen, Inleiding, Koppelingen |
1.0 |
07-Aug-2024
|
Eerste vrijgave |