Onderzoekers omzeilen multifactorauthenticatie Azure dankzij te hoge inloglimiet

Beveiligingsonderzoekers van Oasis Security zeggen een manier te hebben gevonden om de multifactorauthenticatie van Microsoft Azure te omzeilen. Dit lukte omdat de inlogperiode voor totp-codes drie minuten duurde en ze het maximaal aantal inlogingpogingen konden omzeilen.

De methode van Oasis kostte volgens het bedrijf een uur om uit te voeren en vereiste geen gebruikersinteractie. Een slachtoffer of beheerder zou ook geen melding van de aanval krijgen. Na melding van de kwetsbaarheid heeft Microsoft het probleem volgens Oasis opgelost door iets aan het inlogpogingenmaximum te veranderen. Het is niet bekend of eventuele kwaadwillende hackers de kwetsbaarheden daadwerkelijk hebben misbruikt.

De onderzoekers konden de mfa van Azure-omgevingen, die overigens binnenkort verplicht wordt, met relatieve betrouwbaarheid omzeilen. In de eerste plaats heeft een aanvaller daarvoor een werkende inlognaam met bijbehorend wachtwoord nodig. Vervolgens deden de onderzoekers zoveel mogelijk pogingen de zescijferige authenticatiecode die Azure vereist te raden. Er zijn een miljoen opties als een code uit zes cijfers bestaat.

Werkwijze

De kwetsbaarheid was uit te buiten omdat Microsoft Azure volgens Oasis een zeer lange 'buffertijd' hanteerde. Multifactorauthenticatieplatforms genereren doorgaans iedere dertig seconden een nieuwe code, maar vanwege vertragingen en tijdverschillen tussen de gebruiker en een platform wordt er in de praktijk soms een buffertijd in het systeem gebouwd. In die tijd is een technisch gezien verouderde code nog steeds geldig. Bij Azure was de buffertijd volgens de onderzoekers 2,5 minuut. Een gebruiker had met andere woorden in de praktijk drie minuten de tijd om een individuele authenticatiecode in te voeren.

Alleen op basis van deze kwetsbaarheid hadden de onderzoekers naar eigen zeggen drie procent kans om de mfa te omzeilen; ze hadden drie minuten de tijd om de juiste code te raden. Ze konden daarentegen ook misbruik maken van een bijkomende tweede kwetsbaarheid: in het systeem dat moet opmerken wanneer er te veel mislukte inlogpogingen hebben plaatsgevonden. In principe kan een gebruiker tien foute authenticatiecodes invullen voordat Microsoft verdere pogingen blokkeert.

Oasis claimt massaal gelijktijdige nieuwe sessies te hebben kunnen starten voor inlogpogingen voor hetzelfde account. De onderzoekers konden dus op hoge snelheid en systematisch proberen om binnen drie minuten en met een onbeperkte hoeveelheid inlogpogingen in te loggen. Na 70 minuten aan achtereenvolgende inlogpogingsessies van 3 minuten zouden de onderzoekers 50 procent kans hebben om de multifactorauthenticatiecode te kunnen raden.

De kans van slagen na een bepaalde tijd. Bron: Oasis Security

Reacties (55)

[Sissors]

De kwetsbaarheid was uit te buiten omdat Microsoft Azure volgens Oasis een zeer lange 'buffertijd' hanteerde.

Dat maakt toch weinig uit? Ja met een kortere buffertijd, had je een paar minder geldige codes die je kon gebruiken, en dan zou het ~2x zo lang duren anders. Het probleem is de oneindige aantal inlogpogingen die je kon doen.

[batjes]

Nou. Dit is mij ook 1 of 2 keer overkomen terwijl ik normale werkzaamheden verrichte, dat de MFA gewoon geskipt werd tijdens het inloggen. Het is me alleen niet gelukt het zelf zo te reproduceren (geen moeite ingestopt ook, vraagtekenhoofd en door)

Zo heel super is dat natuurlijk niet.

[Scriptkid]

Maar dan wordt de end user toch ook over spoeld met MFA meldingen,

Die trekt dan toch meteen aan de bel bij zijn ict afdeling en krijgt dan een wachtowoord reset voor de boeg en is de aanval weer afgeslagen.

wel bijzonder dat je zoveel concurrent sessies tegelijk kunt maken zonder issues , als je dat via powershell doet krijg je vaak al errors met de 3de sessie.

[YannickSpinner]

Een slachtoffer of beheerder zou ook geen melding van de aanval krijgen.

Volgens de onderzoekers niet. Dat heeft er vermoedelijk mee te maken dat de aanvaller dus vanuit het systeem gezien minder dan 10 verkeerde inlogpogingen doet, verspreid over talloze sessies. Je krijgt doorgaans pas een melding als je (of iemand anders) te vaak verkeerde inloggegevens probeert.

[hiostu]

Wat @Scriptkid bedoelt, is dat je als account eigenaar een melding krijgt op je telefoon voor het goedkeuren van een inlogpoging. Die moet je dan goedkeuren door het getal wat je op het scherm ziet op je authenticator im te voeren. Dat heeft niet zo veel te maken met foutieve inlogpogingen.

[WoutervOorschot]

Als je mfa op de authenticator-app van microsoft gebruikt wel. Als je echter gewoon totp gebruikt (via dezelfde app, een andere of je wachtwoordmanager) dan krijg je geen notificaties.

[YannickSpinner]

Das waar ook ja. Dan krijg je er vermoedelijk één, mits meldingen inderdaad ingeschakeld zijn. Hier zeggen de onderzoekers overigens verder niets over, dus dat is speculatie.

[iKiddo]

Je kunt altijd TOTP-codes gebruiken als fallback. Het is weliswaar even zoeken naar het knopje als je aan het inloggen bent. Het zit verborgen achter: "Having trouble? Sign in another way".

Dat is een grotere drempel voor gebruikers dan voor aanvallers.

[Franckey]

Waarom zou die fallback bestaan? Ik gebruik de Microsoft Authenticator app. Als ik die niet kan gebruiken, dan kan ik daarmee ook geen TOTP code genereren. En ik heb geen andere authenticator app ingesteld voor TOTP codes voor Microsoft.

[iKiddo]

Meestal: Als je telefoon geen internetverbinding heeft, dan kun je nog steeds de TOTP-codes gebruiken.
Voor sommigen: Als je geen Microsoft Authenticator app wil, dan kun je de TOTP-seed in een andere TOTP app stoppen.

[lazybones]

de seed voor TOTP is voor de Microsoft Authenticator app anders dan voor 3rd party apps

[michaelkamen]

Ik heb met enige regelmaat dat MFA verzoeken niet binnenkomen in de Microsoft Authenticator app.
Lijkt te maken te hebben met wifi, maar weet het nog niet zeker.
Dan is het handig als je kunt terugvallen op TOPT-codes.

[Murfy]

Omdat je in dat menu ook voor sms kan kiezen, mits ingesteld.

[supersnathan94]

The bypass was simple: it took around an hour to execute, required no user interaction and did not generate any notification or provide the account holder with any indication of trouble.

Van de website. Lijkt er dus op dat het helemaal geen meldingen genereert.

[DDX]

Niet als je geen push mfa hebt aanstaan, maar op basis van codes werkt.

[ibmpc]

Je kunt TOTP forceren vanaf de eindgebruikerskant, zodat de eindgebruiker geen pushmelding krijgt. Het verdient dus aandacht om TOTP in je tenants uit te schakelen, omdat TOTP sowieso al achterhaald is en niet veilig meer is.

[PolarBear]

Wat niet bepaald de standaard instelling is.

[DDX]

Niet als je de microsoft authenticator gebruikt nee, maar genoeg mensen die google authenticator gebruiken en die kan (helaas) niets met push berichten.

[Blokker_1999]

En als beheerder vind ik het niet leuk dat ik niet kan afdwingen dat onze gebruikers de MS Authenticator moeten gebruiken voor het bedrijfsaccount net vanwege de pushmeldingen.

[Mark87]

Als er een byod beleid is die toestaat eigen telefoons te gebruiken dan gaat het best ver om bepaalde apps te verplichten. Ik wil op mijn telefoon geen ms authenticator (ik heb al een andere waarbij de codes ook uit mijn wachtwoord manager kunnen komen). En push meldingen zet ik waar mogelijk uit, lang leve de optie die er vaak is dat uit te zetten. Anders geeft het behoorlijk wat afleiding.

[MikeN]

Dat kan gewoon via conditional access?
Zie https://learn.microsoft.c...cy-all-users-mfa-strength en ga voor 'Phishing-resistant MFA strength'.

[Reactie gewijzigd door MikeN op 13 december 2024 09:01]

[Heraz]

Volgens mij is dit gewoon een duidelijke fout van Microsoft. ‘Push’ meldingen hebben weer hun eigen problemen

[84hannes]

Mijn standaardinstelling bij apps is "no notifications". Alleen als ik echt een goede reden zie mogen apps mij lastigvallen. Dat is wellicht de reden dat ik ook handmatig de Authenticator moet starten.

[The-Source]

Als je alleen code optie aan hebt staan en geen push melding merkt de gebruiker er weinig van.

[willieverhoef]

Niet als je inlogt met authenticatie code, die geeft geen extra popup mail of zo. Je moet dan gewoon de google, ms of andere app openen om die 6 cijferige code te lezen. En vaak zijn inderdaad 2 of 3 codes nog geldig.

[vanaalten]

Ik snap 'm nog niet helemaal.

Wat ik begrijp is dat tien opeenvolgende foute gokken de limiet is voor een enkele sessie en dat ze door heel veel simultane verbindingen deze limiet omzeilen. Dan neem ik aan dat, ik noem maar wat, 3000 simultane pogingen de teller met 1 ophogen, dus dan zou je effectief 30000 pogingen per sessie kunnen doen ipv tien.

Maar, hoe speelt die tijd-limiet van drie minuten hier een rol? Heb je voor die 3000 simultane pogingen dan, ik noem maar wat, 18 seconden nodig, dus kan je in 180 seconden 30000 pogingen doen voor de gok-teller op 10 staat? En met 30000 pogingen kom je op 3% kans op goed gokken uit?

[Skix_Aces]

De TOTP code die je in de app te zien krijgt veranderd elke 30 seconden. Microsoft had echter een buffer tijd ingebouwd, waardoor deze code nog 2,5 minuut langer geldig bleef. Hierdoor heb je effectief 3 minuten de tijd om de code te raden, alvorens deze door de server als ongeldig werd verklaard.

[Dykam]

Niet zozeer een comment op jou, maar uit relevantie.

Ik snap niet dat dat die 3 minuten zelfs maar een beetje relevant is volgens de onderzoeker. Het is sowieso normaal om een een code 30 seconden langer geldig te maken. Dus dat is bij Microsoft maar 3 keer langer.

Of die aanval nou 24 uur duurt of 72, dat is volgens mij niet zo heel interessant. Het is niet alsof het een fout was die de aanval van een jaar naar een dag terug brengt, oid.. Het enige relevante IMO is dat er een onbeperte brute force mogelijk was.

[jvdmeer]

Die drie minuten is heel relevant. Want dat betekent dat er bijna 6 codes geldig zijn. Namelijk de nieuwe, diegene die 30 seconden geleden nieuw was, diegene die 1 minuut geleden geldig was... enz... tot de code die drie minuten geleden geldig was.

Dus de kans op goed gokken is in 1x van 1:1000000 men een factor 6 verbeterd naar 1:166667.

[Dykam]

Mijn comment was misschien niet duidelijk genoeg. Sowieso is het maar een factor 3, gezien het vrij standaard is om 2 codes geldig te hebben (huidige en vorige). Daarnaast is zelfs een factor 6 echt totaal niet boeiend, het is pas interessant als het om meerdere magnitudes gaat. 100 keer zo snel bijv.

[sympa]

Sterker nog, er zijn dus 5 codes die tegelijk geldig zijn. Want de huidige code, die van 30 seconden geleden, die van 60 seconden geleden...
Daardoor gaat het raden dus 5 keer zo snel.

[PolarBear]

Dat is overigens niet alleen bij Microsoft zo, andere platformen accepteren ook nog een verlopen code. Wellicht niet zo lang.

[barbarbar]

We hebben hier de TOTP codes ingesteld dat er max 5 foute pogingen in 5 minuten mogen zijn, daarna account gelocked. Immers is een foute TOTP code invoeren, terwijl je wel de gebruikersnaam en ww weet al heel snel verdacht. Met nog een boel rate limiting op de naam/ww inlog, als een account meer dan 10x inlogt in 5 minuten wordt het IP geblocked voor dat account voor een dag.

D'r zijn best veel dingen waar je rekening mee moet houden om het veilig te maken, dat ze bij Microsoft ook dingen over het hoofd zien geeft wel aan hoe lastig het is. Ze willen natuurlijk ook geen helpdesk die overspoeld wordt als er ergens een scriptkiddie allerlei accounts gelocked krijgt. Voor een kleiner bedrijf is dat wat minder van belang.

[Reactie gewijzigd door barbarbar op 12 december 2024 17:03]

[Dykam]

Het probleem is dat je op die manier iemand makkelijk uit zijn account kan sluiten. Ik vermoed dat daar rekening mee gehouden is, maar duidelijk niet op een goede manier.

[cdwave]

Is ook een prima manier om in te breken...

He met Klaas hier, m'n account is gelockt, kunnen jullie 'm even resetten?

Heb dat jaren geleden voor de lol eens geprobeerd met een collega bij een groot bedrijf, en de helpdesk was heel behulpzaam en gaf mij een nieuw wachtwoord en ik kon zo inloggen in zijn account.

Gelukkig is het met de behulpzaamheid van helpdesks niet meer zo goed gesteld.

[DDX]

En dit hebben ze (niet) bij Microsoft gemeld / wat is hun reactie ?
Lijkt mij toch redelijk eenvoudig op te lossen voor Microsoft.

of je bekijkt de bron (maar wel handig om dat ook hier te vermelden) :

Vulnerability timeline and Microsoft response:
24/06/2024 - Microsoft Acknowledgment of the issue
04/07/2024 - Microsoft Deployed a temporary fix
09/10/2024 - Microsoft Deployed Permanent Fix

[Reactie gewijzigd door DDX op 12 december 2024 16:45]

[anpat]

Volgens mij lees je maar half,

Na melding van de kwetsbaarheid heeft Microsoft het probleem volgens Oasis opgelost door iets aan het inlogpogingenmaximum te veranderen.

[DDX]

Dat zinnetje zag ik over het hoofd
@YannickSpinner misschien wel handig om het iets duidelijk in het artikel te benoemen ?

[Reactie gewijzigd door DDX op 12 december 2024 16:48]

[vrow]

Het spijt me, en ik krijg vast een boel minnetjes, maar: nee, je moet gewoon het artikel beter lezen.

Als je eens over een zin heen leest, dat kan gebeuren. Maar dat is dan toch echt niet de schuld van de auteur. Ik lees ook wel eens over een zin heen, geen probleem. Moet Yannick die zin nu dan in vette letters, lettergrootte 14 zetten ofzo?

En ook als je verder leest, zie dat de hele rest van het artikel in de verleden tijd is geschreven. Ook dat impliceert al dat het lek is opgelost. Sterker nog, ook de inleiding is zo geschreven wat ook meteen al de indruk wekt dat het al is opgelost.

[YannickSpinner]

Bedankt voor de suggestie. Over het hoofd zien kan altijd gebeuren! Ik vind het opbouw van het artikel daarentegen prima, het staat vrij ver bovenaan.

Daarbij een algemene regel, als we iets over een kwetsbaarheid publiceren, is het probleem altijd al gefixt (zie responsible disclosure) of wordt nadrukkelijk vermeld dat deze periode verlopen is en dat de kwetsbaarheid nog actief misbruikt kan worden. Dit laatste komt gelukkig zelden voor.

[Hermessz]

"Na melding van de kwetsbaarheid heeft Microsoft het probleem volgens Oasis opgelost door iets aan het inlogpogingenmaximum te veranderen"

[markg85]

Ach, deze idiote tak van "beveiligingsonderzoek"... Kijk, vroeger noemde men dit gewoon een brute force aanval of "script kiddies". Nu is het "een kritiek beveiligingslek" met een lekker happende naam als "AuthQuake"... De bron zelf noemt het ook "kritiek" wat ook nogal overdreven is. Ugh...

Een quote uit de bron, vetgedrukt wat hier even belangrijk is:

When users first arrive at the login page they are assigned with a session identifier.

After typing a valid email and password, users are asked to further verify their identity, Microsoft supports a variety of MFA methods, including a verification code from an application. Using such an application, users type in the 6-digit code to complete their authentication.

Up to 10 consequent failed attempts were allowed for a single session.

→ Lack of rate limit
By rapidly creating new sessions and enumerating codes, the Oasis research team demonstrated a very high rate of attempts that would quickly exhaust the total number of options for a 6-digit code (1M). Simply put – one could execute many attempts simultaneously.

Dus wat heb je nodig?

• Een al geldige gebruikersnaam en wachtwoord!
• Brute force

Alleen al bij het hebben van die geldige gebruikersnaam en wachtwoord is er al iets grandioos mis en zou die gebruiker een nieuw wachtwoord moeten instellen. In organisaties gebeurd dat vaak om de x maanden (zeg een kwartaal). Dus de kans dat dit "kritieke lek" echt kritiek is... nee niet echt. Lijkt me alsnog wel handig als microsoft bij het snel openen van vele sessies binnen een bepaalde tijd dat detecteert en daarmee is het "lek" ook al gedicht.

[Reactie gewijzigd door markg85 op 12 december 2024 16:50]

[vrow]

2FA is juist ontwikkeld voor de gevallen waarin het wachtwoord per ongeluk op straat is komen te liggen.
Dan moet 2FA je juist beschermen. 2FA is niet bedoeld om mensen te irriteren en het inlogproces zo ingewikkeld mogelijk te maken, zoals veel mensen wel denken :-)

Dus als de 2FA dan te omzeilen is door heel snel te raden, dan is dat inderdaad niet goed ingeregeld.
Ze zijn vergeten om de rate limiting goed in te stellen. En dat is niet slim.

[deadinspace]

Ik vind dat je best wel een punt hebt dat dit overdreven neergezet wordt voor wat het is.

En toch is je bericht gemodereerd op 0, in plaats van +1 ofzo. Waarom? Ik denk door de toon van je bericht.

Je begint al gelijk met "idioot" en "ugh", en je gebruikt aan de lopende band scare quotes. Zelfs als je dat negeert, dan is de vibe van je hele bericht gewoon... Chagerijnig.

Ik denk dat dat ervoor zorgt dat je (valide!) punt verloren raakt, en dat veel mensen afhaken op je bericht of je modereren als "0: zeurkous". Het maakt in deze wereld niet alleen uit wat je zegt, maar ook hoe. Ironisch genoeg is dat ook jouw kritiek op het artikel

Nouja goed, dat wilde ik even aankaarten. Doe er mee wat je wil. My 2 cents, etc etc

[markg85]

Ha, dankjewel voor de feedback

Ja, beveiligingsonderzoekers staan bij mij gelijk onderaan de respect ladder. Dit komt door bijvoorbeeld de CPU bugs van een paar jaar geleden waar hele trailers (als in een film) voor werden gemaakt om hun onderzoek op te hypen. Sindsdien kijk ik vol argwaan en onbegrip naar wat beveiligingsonderzoekers zeggen en wat daadwerkelijk het probleem is. En dat komt vervolgens weer terug bij berichten als dit.

Je heb helemaal gelijk! Ik kan het zeker anders verwoorden dat het meer overkomt als constructieve kritiek i.p.v. zeuren Zal dat de volgende doen!

[aikebah]

Ach, deze idiote tak van "beveiligingsonderzoek"... Kijk, vroeger noemde men dit gewoon een brute force aanval of "script kiddies". Nu is het "een kritiek beveiligingslek" met een lekker happende naam als "AuthQuake"... De bron zelf noemt het ook "kritiek" wat ook nogal overdreven is. Ugh...

Een quote uit de bron, vetgedrukt wat hier even belangrijk is:

[...]


Dus wat heb je nodig?

• Een al geldige gebruikersnaam en wachtwoord!
• Brute force

Alleen al bij het hebben van die geldige gebruikersnaam en wachtwoord is er al iets grandioos mis en zou die gebruiker een nieuw wachtwoord moeten instellen.

Ik denk dat je geen idee hebt hoe vaak die eerste vereiste bij phishing-testen nog fout gaat bij grote bedrijven. Is een stuk minder ondenkbaar dan je wellicht denkt dat een hacker geldige usernaam/wachtwoord weet te bemachtigen van een bestaande gebruiker.

[ibmpc]

Was dit alleen voor Azure of ook voor Entra? En was het mitigeerbaar met een phishing resistant policy?

[PolarBear]

Azure inloggen = Entra

[ibmpc]

Volgens mij kun je het artikel ook lezen als de Azure app in Entra en hoeft het dus niet voor heel Entra te gelden. Zo geldt de verplichte MFA policy voor privileged rollen alleen voor de admin portal app en niet voor Graph.

[Ruthhl3ss]

Conditional Access of Per User MFA staat niet het artikel wat een groot verschil maakt in de MFA methodiek.

Er is meer informatie nodig over de Azure configuratie van de tenant om te achterhalen of dit daadwerkelijk interessant is.

[Ruuddie]

Als ik het zo lees, is de voornaamste bug dat je dan wel maar 10x pogingen hebt een code in te vullen, maar dat je binnen die poging dan wel 1000x iets kon sturen ofzo? Omdat hij dat je dat precies tegelijk stuurt, heeft ie niet door dat je er 1000 doet binnen die 1 seconde. Of begrijp ik het verkeerd?

[Ruthhl3ss]

Het feit dat het artikel niet verteld hoe de tenant geconfigureerd is (Entra per user MFA of Conditional Access) maakt het lastig beoordelen of dit daadwerkelijk een probleem is.

Van per user MFA is "algemeen" bekend dat deze niet persistent is en je soms zonder MFA laat inloggen. Ik vind het artikel te vaag en vraagt om meer uitleg. Uiteraard moeten de problemen rondom per user MFA opgelost worden maar het gros van de klanten gebruikt Conditional Access als MFA methode voor Entra.

Ook het bron artikel bevat niet de term Conditional Access. Daarom kan ik lastig beoordelen of de tenant waar ze deze test mee hebben uitgevoerd goed geconfigureerd is.

[SPee]

Blij dat ze de buffertijd niet hebben verkort.
Ik heb soms problemen met een slechte internetverbinding op mijn werk laptop, waardoor het scherm nog niet geladen is, maar ik al wel de authenticator notificatie op mijn telefoon heb. Al meerdere keren de melding "u was te langzaam met invoeren, probeer opnieuw" gehad, terwijl ik toch echt zsm na het zien van de nummers deze heb ingevoerd.
Een nog kortere periode zou dat voor vele gewoon onwerkbaar maken.

[ibmpc]

Inmiddels ingelezen in wat dit probleem exact is. Een paar dingen.

Dit geldt dus niet alleen voor Azure, maar voor heel Entra.
Dit geldt alleen voor het onveilige TOTP protocol
Dit geldt niet voor phishing resistant

Dus als je meer tijd nodig hebt, dan kun je bijv. Windows Hello gebruiken voor het aanloggen op een tenant. Dan ben je en phishing resistant en je hoeft geen wachtwoorden meer te gebruiken, wat je gebruiksgemak ten goede komt.