Blast-RADIUS-protocol (CVE-2024-3596) voor het beperken van spoofing

Inleiding

Op 7 juli 2024 onthulden beveiligingsonderzoekers de volgende kwetsbaarheid in het RADIUS-protocol: CVE-2024-3596: Het RADIUS-protocol onder RFC 2865 is vatbaar voor vervalsingsaanvallen door een on-path-aanvaller die elke geldige Response (Access-Accept, Access-Reject of Access-Challenge) kan aanpassen aan elke andere reactie met behulp van een gekozen prefix collision attack tegen MD5 Response Authenticator-handtekening. Ze hebben een paper gepubliceerd waarin hun bevindingen worden beschreven op https://www.blastradius.fail/pdf/radius.pdf, die een succesvolle reactie op vervalsing van stromen laat zien die het Message-Authenticator-attribuut niet gebruiken.

Voor een actuele lijst van Cisco-producten die getroffen zijn door dit beveiligingslek en versies die oplossingen bevatten, gaat u naar: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-radius-spoofing-july-2024-87cCDwZ3. In dit artikel wordt ingegaan op algemene mitigatietechnieken en op de manier waarop deze van toepassing zijn op sommige, maar niet alle Cisco-producten. De afzonderlijke productdocumentatie moet voor meer informatie worden geraadpleegd. Als Cisco's vlaggenschip RADIUS-server zal Identity Service Engine meer in detail worden behandeld.

Achtergrond

Deze aanval maakt gebruik van een MD5-gekozen prefix aanval met behulp van botsingen in MD5, waardoor een aanvaller om extra gegevens toe te voegen aan de RADIUS-responspakket, terwijl het wijzigen van bestaande kenmerken van de respons pakket. Een voorbeeld hiervan is de mogelijkheid om een RADIUS Access-Reject te veranderen 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 attribuut Message-Authenticator 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 attribuut Message-Authenticator bevat.

verzachting

berichtenverificator

1) RADIUS-client moet attribuut Message-Authenticator bevatten.

Wanneer het Network Access Device (NAD) het Message-Authenticator attribuut in het Access-Request (toegangsverzoek) opneemt, zal Identity Services Engine Message-Authenticator opnemen in het resulterende Access-Accept, Access-Challenge of Access-Reject pakket in alle versies.

2) De RADIUS-server moet het ontvangen van het attribuut Message-Authenticator afdwingen.

Het is niet voldoende om alleen de Message-Authenticator in het Access-Request op te nemen, omdat de aanval het mogelijk maakt om de Message-Authenticator uit het Access-Request te halen voordat deze wordt doorgestuurd naar de RADIUS-server. De RADIUS-server moet ook eisen dat de NAD Message-Authenticator in het Access-Request opneemt. Dit is niet standaard op Identity Services Engine, maar kan worden ingeschakeld op het toegestane protocolniveau, dat van toepassing is op het ingestelde beleidsniveau. De optie onder de configuratie Toegestane protocollen is "Vereist berichtverificatie" voor alle RADIUS-verzoeken:

Optie Toegestane Protocollen in Identity Services Engine

Verificaties die overeenkomen met een beleidsset waarbij de configuratie Toegestane protocollen Message-Authenticator vereist, maar waarbij het Access-Request niet het Message-Authenticator attribuut bevat, worden door ISE verwijderd:

Het is belangrijk om te controleren of de NAD Message-Authenticator verzendt voordat deze door de RADIUS-server wordt vereist, aangezien dit geen onderhandelde eigenschap is, is het aan de NAD om deze standaard te verzenden of te worden geconfigureerd om deze 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 functionaliteit voor pakketregistratie 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.

Hieronder ziet u een voorbeeld van een Access-Request dat het attribuut Message-Authenticator bevat:

Message-authenticator attribuut in Radius access-request

Hieronder ziet u een voorbeeld van een Access-Request dat niet het attribuut Message-Authenticator bevat:

Versleutelen met TLS/IPSec

De meest effectieve langetermijnoplossing om RADIUS te beveiligen, is het versleutelen van het verkeer tussen de RADIUS-server en de NAD. Dit voegt zowel privacy als een sterkere cryptografische integriteit toe dan alleen te 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:

•  RadSec verwijst naar RFC 6614
• RadSec TLS verwijst naar RFC 6614
• RadSec DTLS verwijst naar RFC 7360

Het is belangrijk om encryptie op een gecontroleerde manier uit te rollen, omdat er prestatieoverhead is voor TLS-codering en overwegingen met betrekking tot certificaatbeheer. Certificaten moeten ook regelmatig worden vernieuwd.

RADIUS boven DTLS

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 codeert 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 bij de implementatie van RADIUS via DTLS het verlopen en vervangen van certificaten strikt moet worden beheerd om te voorkomen dat verlopen certificaten de RADIUS-communicatie onderbreken. ISE ondersteunt DTLS voor ISE-naar-NAD-communicatie, omdat vanaf ISE 3.4 Radius over DTLS niet wordt ondersteund voor RADIUS-Proxy- of RADIUS-tokenservers. RADIUS over DTLS wordt ook ondersteund door veel Cisco-apparaten die fungeren als NAD's, zoals switches en draadloze controllers met IOS-XE®.

RADIUS boven TLS

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. Met ingang van ISE 3.4 wordt RADIUS over TLS niet ondersteund, maar wel door veel Cisco-apparatuur die als NAD's fungeert, zoals switches en draadloze controllers waarop IOS-XE wordt uitgevoerd.

IPSEC

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-knooppunt. ISE 3.3 en hoger vereist geen licentie meer voor IPSec, het is nu beschikbaar in eigen beheer.

gedeeltelijke mitigatie

RADIUSsegmentatie

Segmenteer RADIUS-verkeer naar beheer-VLAN's en beveiligde, gecodeerde koppelingen zoals kunnen worden geleverd via SD-WAN of MACSec. Deze strategie brengt het risico van de aanval niet tot nul, maar kan het aanvalsoppervlak van de kwetsbaarheid aanzienlijk 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 in een netwerksegment kan komen met dat verkeer, is de aanval niet mogelijk. De reden dat dit slechts een gedeeltelijke beperking is, is dat een verkeerde configuratie van het netwerk of een compromis van een deel van het netwerk het RADIUS-verkeer kan blootstellen.

Als RADIUS-verkeer niet kan worden gesegmenteerd of gecodeerd, kunnen extra functies worden geïmplementeerd om succesvolle MITM te voorkomen op risicosegmenten zoals: IP-bronbewaking, dynamische ARP-inspectie en DHCP-controle. Het kan ook mogelijk zijn om andere verificatiemethoden te gebruiken op basis van het type verificatiestroom, zoals TACACS+, SAML, LDAPS, enz...

Kwetsbaarheidsstatus van engine voor identiteitsservices

De volgende tabellen beschrijven wat beschikbaar is vanaf ISE 3.4 om authenticatiestromen te beschermen tegen Blast-RADIUS. Om samen te vatten, moeten de volgende 3 items aanwezig zijn voor een stroom met alleen Message-Authenticator en niet met DTLS/RadSec/IPSec-codering, zodat de stroom niet kwetsbaar is:
1) Het netwerktoegangsapparaat MOET het attribuut Message-Authenticator in het Access-Request verzenden.

2) De RADIUS-server MOET het attribuut Message-Authenticator in het Access-Request hebben.

3) De RADIUS-server MOET reageren met het attribuut Message-Authenticator in Access-Challenge, Access-Accept en Access-Reject.

Raadpleeg CSCwk67747 die de wijzigingen bijhoudt om de kwetsbaarheden te sluiten wanneer ISE optreedt als RADIUS-client.

ISE als RADIUS-server

ISE als RADIUS-client

ISE als RADIUS Client Updates

Verbeteringen aan ISE als 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 CSCwk67747. Na patch of upgrade zal elke nieuwe resource die wordt gemaakt standaard voldoen aan de nieuwe, veiligere configuratie. Bestaande bronnen moeten worden gewijzigd om de veiligere configuratie na patch of upgrade te gebruiken. Er is een nieuw selectievakje toegevoegd: "Message Authenticator Required On Response", indien aangevinkt dient het een tweeledig doel: ISE zal altijd Message Authenticator verzenden en ISE zal de verificatie mislukken als een antwoord wordt ontvangen zonder Message Authenticator. Het gedrag is als volgt:

RADIUS-tokenserver

Een nieuw selectievakje: "Message Authenticator Required On Response" is toegevoegd onder het tabblad Verificatie voor de RADIUS-tokenserverconfiguratie:

Als het selectievakje ingeschakeld is en een RADIUS-antwoord wordt ontvangen zonder Message Authenticator, wordt een foutbericht geregistreerd in het gedetailleerde verificatielogboek 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, waardoor de verificatie kan overeenkomen met een onverwacht beleid.

Externe RADIUS-server

Een nieuw selectievakje: "Message Authenticator Required On Response" is toegevoegd aan de Externe RADIUS-serverconfiguratie:

Als het selectievakje ingeschakeld is en een RADIUS-antwoord wordt ontvangen zonder Message Authenticator, wordt een foutbericht geregistreerd in het gedetailleerde verificatielogboek 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, waardoor de verificatie kan overeenkomen met een onverwacht beleid.

Wijziging van de vergunning (CoA)

De CoA-wijzigingen zijn aangebracht in de netwerkapparaatprofielen in de lade voor de wijziging van de autorisatie (CoA):

De optie "Send Message-Authenticator" is een eerdere functie, de nieuwe optie is "Message-Authenticator Required on response. ISE verzendt het attribuut Message Authenticator als de Message-Authenticator Required on response is aangevinkt, ongeacht of "Send Message-Authenticator" is aangevinkt of niet. "Send Message-Authenticator" blijft behouden voor bestaande configuraties. Als de NAD Message Authenticator niet in de CoA-respons opneemt, 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 fout is aangemeld op ISE, omdat de NAD de CoA mogelijk heeft verwerkt, maar de Message Authenticator niet in het antwoord heeft opgenomen.

De standaard "Cisco Provided" Network Device Profiles kunnen niet worden gewijzigd, om de nieuwe optie te gebruiken kan het Network Device Profile worden gedupliceerd en kan de instelling worden ingeschakeld op het gedupliceerde profiel. Netwerkapparaten moeten dan worden toegewezen aan het nieuwe netwerkapparaatprofiel. Dit werd gedaan om het risico op het veroorzaken van een netwerkuitval na een patch of upgrade te verminderen door een incompatibiliteit tussen ISE en bestaande NAD's te introduceren. Als een bestaand gebruikersgedefinieerd profiel wordt gebruikt, wordt 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 netwerkapparaatprofiel.