Onderzoekers vinden MD5-collisionbug in populair Radius-authenticatieprotocol

Onderzoekers hebben een kwetsbaarheid ontdekt in het veelgebruikte Radius-authenticatieprotocol. Daarin zit een collisionbug die het mogelijk maakt een man-in-the-middle-aanval uit te voeren. Dat kan omdat de serverauthenticatie op het MD5-hashalgoritme draait.

De onderzoekers noemen de kwetsbaarheid Blast-Radius. Dat is ook waar de kwetsbaarheid zich bevindt: in het Remote Authentication Dial-In User Service-protocol. Dat is een oud, maar nog steeds veelgebruikt authenticatieprotocol dat voornamelijk nog op zakelijke netwerkapparatuur wordt gebruikt. Ook wordt het gebruikt om verbindingen te leggen in glasvezelaansluitingen of vpn's. De kwetsbaarheid wordt getrackt als CVE-2024-3596. Volgens de onderzoekers zijn alle Radius-implementaties die via UDP werken kwetsbaar. Meerdere fabrikanten hebben inmiddels patches uitgebracht voor de bug. De onderzoekers raden beheerders aan bij die specifieke fabrikanten aan te kloppen voor een oplossing. Daarnaast hebben de onderzoekers een mitigatie beschreven.

De bug is in feite een MD5-collisionaanval, maar is volgens de onderzoekers wel ingewikkelder dan een normale aanval. Radius maakt namelijk nog steeds gebruik van MD5, een hashalgoritme dat al zeker twintig jaar niet meer als veilig wordt gezien. "Hoewel een MD5-collision al in 2004 voor het eerst werd aangetoond, leek het lang niet mogelijk om dit in de context van het Radius-protocol uit te buiten", schrijven de onderzoekers.

De kwetsbaarheid zit in de manier waarop Radius een Access-Accept-response valideert bij het leggen van een authenticatie. Dat gebeurt met een MD5-hash die al na enkele minuten een time-out geeft. Daardoor leek het lang niet mogelijk een serieuze collisionaanval uit te voeren, omdat een aanvaller daar meer dan die enkele minuten voor nodig heeft.

De onderzoekers zeggen nu een zogenaamde chosen-prefix-collision uit te kunnen voeren. Dat is mogelijk, omdat Access-Request-packets geen integriteitscontroles hebben. De onderzoekers demonstreren in hun aanval dat ze op die manier de Access-Request kunnen aanpassen met een eigen prefix, zodat het makkelijker wordt een collision uit te voeren.

In de praktijk duurt het nog steeds minuten voor zo'n collision plaats kan vinden, zeggen de onderzoekers. Die hebben een proof-of-concept gemaakt waarin ze drie tot zes minuten nodig hadden om een collision te berekenen. Maar, merken de onderzoekers op, hun algoritme kan makkelijk worden geoptimaliseerd op verschillende hardware, waardoor een aanvaller met de juiste middelen tientallen tot honderden keren sneller kan opereren.

Reacties (38)

[stijnos1991]

Wat mist in dit stuk maar essentieel is om deze kwetsbaarheid uit te buiten is dat je een man-in-the-middle positie nodig hebt in het netwerk. Dat verhoogt de complexiteit van de aanval nog verder.

[Jaerie]

Wellicht achteraf toegevoegd maar de tweede zin van de inleiding meldt dit.

[crazyboy01]

Was mij eigenlijk uit die zin ook niet 100% duidelijk dat het alleen binnen hetzelfde netwerk mogelijk is. Viel wel aan te nemen natuurlijk, maar toch goed om te weten.

[Jaerie]

Man in the middle is jargon binnen de netwerk beveiliging. Het betekent niet per se dat je binnen hetzelfde netwerk moet zitten maar wel dat je op een manier het verkeer moet kunnen onderscheppen.

[AJediIAm]

Daarmee bedoel je dus dat de aanvaller fysiek tussen het systeem en de server moet zitten? En dat een positie op het zelfde wifi netwerk niet goed genoeg is om deze aanval uit te kunnen voeren?

[sfjuocekr]

Nee, dat hoeft niet.

Je kunt het verkeer ook omleiden doormiddel van ARP poisoning, zo kun je dus ook vanaf een wireless netwerk LAN clients onderscheppen.

Er zijn ook andere mogelijkheid, maar ARP poisoning is wel de meest eenvoudige.

Je kunt daarnaast bij veel switches de switch overnemen door zelf de "root switch" over te nemen met STP, niet verwarren met root user op UNIX systemen.

[Jaerie]

Man in the middle is een vaste term binnen netwerk beveiliging. Dat betekent inderdaad dat je op een manier tussen client en host moet zitten. Er zijn vele mogelijkheden hoe dit exact vorm kan aannemen, simpelweg op hetzelfde wifi-netwerk zitten zal in de meeste gevallen niet voldoende zijn.

[AJediIAm]

In de reacties zijn toch nog een aantal verschillende interpretaties van de term te vinden:
- tussen de cliënt en host
- verkeer kunnen onderscheppen
- verkeer omleiding
Als ik de details van de aanval bekijk moet voor de aanval het mogelijk zijn om verkeer tussen de cliënt en de host aangepast door te sturen, maar de aanval kan een ander apparaat op het netwerk toegang geven. De aanval kan dus fysiek tussen de cliënt en host te gaan zitten, maar ook zoals @sfjuocekr beschrijft.
Omdat het een ander apparaat toegang kan geven lijkt het me interessant om dit als malware of backdoor in te bouwen in netwerk apparatuur of een software stack.

[Jaerie]

Verkeer kunnen onderscheppen betekent dat je tussen de client en host zit. Verkeer omleiden is een manier om tussen client en host te zitten.

Verkeer kunnen aanpassen is niet een vereiste van Man in the Middle, soms is kunnen inzien genoeg voor de aanval.

Fysiek of niet-fysiek is irrelevant voor het concept van MitM. ARP poisoning/spoofing is simpelweg een voorbeeld van een specifieke MitM aanval waar je niet fysiek (zeg maar bedraad) ertussen zit, maar via het draadloze netwerk. In die zin zit je er nog steeds fysiek tussen, want je moet binnen het bereik staan.

Om een ander voorbeeld te geven waar je het niet over een lokaal netwerk hebt, reverse proxy spoofing. Hierbij maak je bijvoorbeeld de online bankieren omgeving na op een url die lijkt op de echte. Een slachtoffer klikt (via bv een phishing mail) op die url en logt in. De nepwebsite tunnelt alle requests door naar de echte banksite (vandaar reverse proxy), en kan zo dus de echte gegevens laten zien om onverdacht te lijken. Ondertussen kan de nepwebsite alle gegevens (login) inzien van het slachtoffer. Omdat die website zich dus tussen client (slachtoffer) en host (echte bank) zet, noem je dit een Man in the Middle attack.

[the_stickie]

man-in-the-middle is exact wat wat de term omschrijft. Je bevindt je (netwerktechnisch) 'tussen' de zender en ontvanger van bepaalde data. Je 'ziet' dus die data 'langskomen' en kan je data met nodige voorwaarden en voorzichtigheid loggen, manipuleren, vervalsen, blokkeren, uitlokken...

simpelweg op hetzelfde wifi-netwerk zitten zal in de meeste gevallen niet voldoende zijn.

Je hoeft zelfs niet op hetzelfde netwerk te zitten bij wifi om een mitm te doen: versleuteld verkeer meeluisteren, deauths uitsturen naar wificlients, frames loggen om later keys te berekenen is afaik een prima voorbeeld van mitm.
Ook zelf een rogue AP opzetten geeft je mitm mogelijkheden.

[Reactie gewijzigd door the_stickie op 22 juli 2024 14:34]

[wica]

Wie maakt er nog gebruik van MD5?

[Ozzy]

Je zou kunnen denken aan authenticatieprotocollen zoals Radius.

Daarnaast is het voor file checksums ook nog steeds een populair en prima bruikbaar algoritme.

[.oisyn]

Daarnaast is het voor file checksums ook nog steeds een populair en prima bruikbaar algoritme.

Wel voor data-integriteit, niet voor checks op malafide aanpassingen.

[crazyboy01]

Ik gebruik hiervoor geen MD5 (of voor welke toepassing dan ook, want echt standaard is het absoluut niet meer), maar zou je dit willen toelichten? Hoe kan de data-intregriteit betrouwbaar zijn wanneer malafide aanpassingen kunnen worden gemist? Hangt dit niet samen? En waarom doen andere algoritmes (zoals de SHA's) dit beter - om maar een aanname te doen?

Ben wel benieuwd.

[RobLemmens]

Als je de integriteit wil testen van een blob met data dan is MD5 zeker ok binnen een bestandsbeheer context ofzo. De kans dat je met een minimale wijziging in de data dezelfde hash krijgt is astronomisch klein, klein genoeg om te gebruiken als check voor een bestand om te kijken of die hetzelfde is als een ander waar je enkel de hash van hebt opgeslagen.

Daarom dat men ook zoveel rekenkracht nodig heeft om een collision te genereren, de kans dat 2 random blobs dezelfde hash genereren is 1.47*10^-29 wat in de praktijk niet vanzelf voorkomt.

Voor veel toepassingen is zoiets als SHA zware overkill en kost het je alleen maar extra cpu.

[Reactie gewijzigd door RobLemmens op 22 juli 2024 14:34]

[uiltje]

Bij MD5 en SHA-1 is de hoeveelheid rekenkracht dus substantieel minder dan bedoelt, en bij MD5 kan je dat echt in seconden doen als je over de juiste hardware beschikt. Buiten dat kan je met een enkele van te voren bekende collision sommige protocollen al om zeep helpen.

SHA-256 is behoorlijk snel op een 32-bit machine en de meeste 64 bit machines hebben tevens SHA-256 direct in de instructie-set zitten. We hebben het hier over gigabytes per seconde. Die "zware overkill" kan je prima hebben op de meeste machines.

Vreemd genoeg zijn er ook genoeg brakke MD5 implementaties in het veld. Ik heb wel meegemaakt dat een Java implementatie sneller was dan die in OpenSSL, en Java is - vergeleken met een native instructie set - voor dit soort toepassingen behoorlijk traag.

[.oisyn]

Soms wil je de data die je hebt valideren tegen iets bekends om te zien of alles wel klopt. Een voorbeeld is Steam die de integriteit van de game files checkt. Je gaat dan niet uit van malafide aanpassingen, maar van problemen met het opslag- (denk aan bit rot of bad sectors) of transport medium (de ipv4 en tcp checksums zijn bijvoorbeeld notoir slecht en faalt soms bij shady verbindingen).

De kans dat de data zo is aangepast door de elementen dat er een MD5 collision optreedt is gigantisch klein, ook al is handmatig een collision veroorzaken mogelijk. Maar goed, er zijn veel snellere non-secure hash algoritmes die beter geschikt zijn dan MD5 hiervoor, alleen zijn die niet zo standaard

Voor verificatie van authenticiteit moet je sowieso met digitale handtekeningen werken, want bij file hashes is er ook nog eens de vraag of de hash waartegen je verifiëert wel authentiek is. En uiteindelijk moet die handtekening wel weer gebaseerd zijn op een niet gecompromitteerd secure hash algoritme. Typisch SHA-2 dus.

[Reactie gewijzigd door .oisyn op 22 juli 2024 14:34]

[xorpd]

Goed punt van de niet al te beste CRC polynoom in IPv4 - daarom gebruikt iSCSI een stuk betere (en niet primitieve!) polynoom.

[xorpd]

Data-integriteit richt zich puur op accidental corruption, zoals bit flips en burst errors. Een CRC algoritme is daar goed genoeg voor. Hashes zijn cryptografische handtekeningen. In feite is MD5 nu gedegradeerd tot een controlesom, is wat .oisyn zegt.

[watercoolertje]

Hangt dit niet samen?

Naar mijn idee wel inderdaad, als je een file aan kan passen dat het dezelfde MD5 krijgt dan kan dat waarschijnlijk ook door malafide code toe te voegen, zolang je maar vaak genoeg probeert zou je op de bestaande hash uit kunnen komen.

En waarom doen andere algoritmes (zoals de SHA's) dit beter - om maar een aanname te doen?

Meer bits (SHA256 = 256 bit, MD5 = 128 bit) voor de hash die gegenereerd wordt (dus meer mogelijkheden waar je op uit kunt komen), en dus een kleinere kans dat dezelfde hash er uit komt rollen.

Als ik het online opzoek zeggen ze dat bij 128 bits de kans op een collision 1 op 2^64 en bij 256 bits is die kans 1 op 2^128. Dat is een immens verschil in kans dus dat je een collision gaat tegen komen. En dan heb je ook nog SHA met 512 bits, dat zou dan een kans van 1 op 2^256 geven

[Reactie gewijzigd door watercoolertje op 22 juli 2024 14:34]

[wica]

De eerste MD5, collision attack kwamen al rond 2010 voor. Niet veel later, was het kraken van MD5 ook relatief snel gedaan.

Als je Radius geen SHA2 SHA256 ofzo iets aankan, neem er afscheid van.

MD5 gebruiken in 2024 is not done.

[uiltje]

Even een aanvulling: een collision attack is gelijk aan "het kraken van MD5", de nadruk ligt hierbij dus op "relatief snel". Pre-image attacks zijn nog steeds niet mogelijk, zelfs niet op MD5. Dat is ook de reden waarom ze dit protocol nog veilig achtten. Maar goed, het is verstandig om MD5 inderdaad links te laten liggen, "attacks always get better, they never get worse".

[driekske]

ik mis de toepasbaarheid van de bug en (mogelijke) gevolgen. Graag de meest zwarte scenario's.

[R4gnax]

Criminelen die toegang verkrijgen tot interne bedrijfsnetwerken, vooral.
Radius wordt vziw niet veel door consumenten gebruikt.

[BlaDeKke]

Gemiste kans om md5 collision toe te lichten. Dat had interessant kunnen zijn.

@marcstevens dankuwel

[Reactie gewijzigd door BlaDeKke op 22 juli 2024 14:34]

[marcstevens]

ArsTechnica heeft ook een goede write-up: https://arstechnica.com/s...d-in-networks-everywhere/

[Recursio]

"Dat is mogelijk omdat de serverauthenticatie op MD5-hashalgortime draait." Deze zin is niet grammaticaal.

[multiplexer]

Reeds gemeld in https://gathering.tweaker...message/79528876#79528876 - gaarne niet-inhoudelijke feedback op het artikel daar delen, dan wordt het sneller opgepakt dan in de discussies hieronder, omdat de Tweakers eindredactie dat topic ook in de gaten houdt, terwijl Tijs alweer druk bezig is met het tikken van z'n volgende stukje

[Reactie gewijzigd door multiplexer op 22 juli 2024 14:34]

[kuurtjes]

Waarom geven ze telkens dit soort exploits een fancy naam? Het lijkt op angstzaaierij zodat de personen zelf bekend worden.

[TijsZonderH]

Daar heeft oud-collega Sander in 2017 een prachtig achtergrondartikel over geschreven!

[uiltje]

Er zit een erg dun velletje tussen "angstzaaierij" en iets onder de aandacht willen brengen, als er al een velletje tussen zit. We hebben het hier meer over grijswaarden denk ik . En ja, veel ontwikkelaars zijn trots en willen graag creativiteit uitstralen. Bekt toch beter dan CVE-2024-3596 of VU#456537?

[AJediIAm]

Ik vind het een hele goede naam. Makkelijk te onthouden en makkelijk te relateren aan het protocol. Ideaal voor snelle en betrouwbare communicatie.

[kuurtjes]

Dus moet elke exploit dan een naam krijgen? Ik vind het maar dom. En ik zou het zelf ook niet doen. Ik heb immers nog een UAC exploitje liggen. Hoe moet ik em noemen? UA-NOT-C? UAC-Badaboom? UAC-HahaNope?

[akooijman]

Angstzaaierij is zo'n woordje dat te pas en te onpas gebruikt wordt zonder duidelijke reden.
Code oranje: angstzaaierij! Welnee, niemand wordt bang van code oranje, wel weet iedereen dat het verstandig is om de parasol en de tuinstoelen binnen te halen.
Hier ook: er wordt melding gemaakt van een mogelijke, maar complexe dreiging. Gewone stervelingen kunnen niets met die waarschuwing, systeembeheerders gaan echt wel even verder lezen.
Bij wie zou angst gezaaid moeten worden dan? En waarom eigenlijk? Bent u bang?

[kuurtjes]

Bedankt voor de gaslighting op deze mooie ochtend.

Ik ben bang dat mensen door het bos de bomen niet meer gaan zien. De nieuwste CVE heeft immers geen naam, maar die heeft wel invloed op mij. Nee, geef mij maar gewoon de naam van de applicatie en de versie.

[DiedX]

Ok, het logo is in ieder geval van toepassing...

[Ar0xA]

Zelfs opensource radius implementaties als FreeRADIUS ondersteunen al tijden TLS (client/server certificates) of TTLS (tunneled TLS voor bv username/password).

Je zou zeggen dat je 14 jaar na de eerste MD5 collision je zou moeten schamen als je nog MD5 gebruikt maar helaas is de MD5 nog steeds vaak de meest gebruikte -default- installatie standaard

[ibmpc]

Huh, ons is geleerd dat RADIUS by default onveilig is. In de NIS2 gebieden mag RADIUS toch helemaal niet meer worden gebruikt? RADIUS is toch onveiliger dan SMB1? De zwakste schakel is al gebroken, wat heeft het patchen van deze specifieke bug dan voor nut?

[Reactie gewijzigd door ibmpc op 22 juli 2024 14:34]