image

RADIUS-protocol kwetsbaar voor nieuwe Blast-RADIUS-aanval

dinsdag 9 juli 2024, 15:01 door Redactie, 5 reacties

Het populaire RADIUS-protocol, dat veel wordt gebruikt voor toegangsbeheer tot netwerken en netwerkapparatuur, bevat een kwetsbaarheid waardoor spoofingaanvallen mogelijk zijn. Een aanvaller kan zodoende op elk apparaat inloggen dat RADIUS voor authenticatie gebruikt, of zichzelf willekeurige netwerkrechten geven. Dat stellen onderzoekers van verschillende universiteiten, Microsoft en het Nederlandse Centrum Wiskunde & Informatica (CWI), die het beveiligingslek de naam Blast-RADIUS hebben gegeven.

RADIUS (Remote Authentication Dial-In User Service) werd in 1991 ontworpen, maar wordt nog altijd als authenticatieprotocol gebruikt voor toegang tot wifi- en vpn-netwerken, en routers, switches en andere netwerkapparatuur. RADIUS-netwerkverkeer wordt doorgaans onbeveiligd getransporteerd via de zogenaamde UDP-netwerklaag, alleen beschermd door cryptografie die is gebaseerd op het verouderde MD5. Ondanks dat sinds 2004 is aangetoond dat MD5 onveilig is, is de RADIUS/UDP-standaard sinds die tijd nauwelijks veranderd.

Bij de Blast-RADIUS-aanval kan een man-in-the-middle-aanvaller tussen de RADIUS-client en -server in reactie op een mislukt authenticatie request een geldige 'accept message' vervalsen. Deze vervalsing geeft de aanvaller toegang tot netwerkapparaten, zonder dat de aanvaller wachtwoorden of andere shared secrets hoeft te raden of bruteforcen. De aanvaller komt de inloggegevens van de gebruiker ook niet te weten.

De aanval is mogelijk door een basale kwetsbaarheid in de RADIUS-protocolspecificatie die een MD5-hash gebruikt om de response te verifiëren, naast het feit dat een deel van de gehashte text voorspelbaar is, wat een chosen-prefix collision mogelijk maakt. "Onze aanval combineert een nieuwe protocolkwetsbaarheid met een MD5 chosen-prefix collision aanval en verschillende snelheidsverbeteringen", aldus de onderzoekers.

Een aanvaller kan een malafide attribuut in een request injecteren, wat voor een collision zorgt tussen de authenticatie-informatioe in de geldige server response en de vervalsing van de aanvaller. Hierdoor kan een aanvaller een 'reject' van de server in een 'accept' veranderen en willekeurige protocolattributen toevoegen. Beheerders die met RADIUS werken worden opgeroepen om te controleren of er voor hun apparatuur patches beschikbaar zijn.

"Er is een korte aanmeldtime-out van hoogstens enkele minuten, waarna de aanmeldpoging wordt afgebroken. Tot nu toe duurde het ongeveer een dag om de MD5-beveiliging te breken met zogenaamde chosen-prefix aanvallen. De onderzoekers presenteren nu een verbeterde, zeer snelle aanval op MD5 van slechts enkele minuten en laten zien hoe daarmee ongeautoriseerde toegang via RADIUS/UDP geforceerd kan worden", zo laat CWI weten.

Marc Stevens van CWI merkt op dat het gebruik van MD5 al heel lang wordt afgeraden, maar dat partijen vaak afwachten tot er een concrete aanval wordt gedemonstreerd. "De RADIUS/UDP-standaard voldoet al lang niet aan moderne cryptografische normen. We raden dan ook het gebruik van RADIUS/TLS aan, aangezien TLS sterke privacy- en securitygaranties kan geven. Leveranciers en netwerkbeheerders moeten dit aanpassen." Cloudflare en het CERT Coordination Center (CERT/CC) van de Carnegie Mellon Universiteit hebben analyses van de kwetsbaarheid gepubliceerd.

Image

Reacties (5)
09-07-2024, 15:50 door Briolet - Bijgewerkt: 09-07-2024, 15:52
Marc Stevens van CWI merkt op dat het gebruik van MD5 al heel lang wordt afgeraden

Ik gebruik al zeker 10 jaar een radiusserver van Synology. De huidige is gebaseerd op 'free radius versie 3.0.15" uit 2017. Ik kan me niet anders herinneren dat er voor elke verbinding gelogd wordt "From client xxxx via TLS tunnel". En dit is een van de meest gebruikte radius servers.

Ik zie wel dat freeradius vandaag een versie 3.0.27 uitgebracht heeft. https://www.freeradius.org/releases/
09-07-2024, 15:59 door Anoniem
Developers van nu zijn als kinderen die met vuurwerk mogen spelen. Meestal gaat het goed. Maar soms kost het een vingertje, een handje of een oogje.

Hoort erbij.
09-07-2024, 18:12 door Anoniem
Door Briolet:
Ik gebruik al zeker 10 jaar een radiusserver van Synology. De huidige is gebaseerd op 'free radius versie 3.0.15" uit 2017. Ik kan me niet anders herinneren dat er voor elke verbinding gelogd wordt "From client xxxx via TLS tunnel". En dit is een van de meest gebruikte radius servers.
Dat komt omdat je het dan hebt over bijvoorbeeld WPA2-EAP of MsChapv2 gebaseerde authenticatie, waarbij er een TLS verbinding getunneld wordt via RADIUS.
Het eigenlijke request is wel via die TLS verbinding (challenge/response of certificaat gebaseerd) maar het "outer" RADIUS protocol wat "accept" terug geeft blijft volgens mij gewoon hetzelfde.

Overigens denk ik dat het (zoals gebruikelijk) allemaal weer zwaar overdreven wordt. Het komt niet vaak voor in normaal gedesignede netwerken dat je een man-in-the-middle kunt doen tussen RADIUS client en server.
Ik weet alleen niet hoe dit geregeld is bij de bekende ***roam netwerken (govroam, eduroam, etc), maar ik kan me niet voorstellen dat daar RADIUS plain over internet verstuurd wordt, zit vast minimaal in een VPN en anders in TLS.
En dan nog, als er iemand een paar uur gaat zitten proberen in te loggen dan valt het grote aantal Access-Rejects vast wel ergens op!
10-07-2024, 09:23 door Anonym0u53
Ik ben wel benieuwd naar de ratio van UDP/TLS implementaties van RADIUS.
12-07-2024, 20:00 door Anoniem
Er is in de security wereld spraken van een soort inflatie...
Relatief kleine zaken worden door beginnende security researchers groot gebracht om op te vallen...
Als ik t schema van de aanval zie dan is de aanvaller dus al binnen....
Voor het mitm deel.... Wat is t voordeel dan om een pakket van buiten te bewerken.

Radius als beheer protocol zou niet over een publiek deel van het net mogen lopen.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.