Nieuwe brute-forcing-fout in Azure Active Directory-wachtwoord heeft geen oplossing

Stel je voor dat je onbeperkte pogingen hebt om iemands gebruikersnaam en wachtwoord te raden zonder betrapt te worden. Dat zou een ideaal scenario zijn voor een sluipende dreigingsactor die serverbeheerders achterlaat met weinig tot geen zicht op de acties van de aanvaller, laat staan ​​de mogelijkheid om ze te blokkeren.

Een nieuw ontdekte bug in de Active Directory (AD)-implementatie van Microsoft Azure maakt precies dat mogelijk: brute-forcing met één factor van de AD-referenties van een gebruiker. En deze pogingen zijn niet aangemeld bij de server.

In juni van dit jaar ontdekten onderzoekers van Secureworks Counter Threat Unit (CTU) een fout in het protocol dat wordt gebruikt door Azure Active Directory Seamless Single Sign-Onservice.

“Deze fout stelt dreigingsactoren in staat om brute-force-aanvallen met één factor uit te voeren tegen Azure Active Directory zonder aanmeldingsgebeurtenissen te genereren in de tenant van de beoogde organisatie”, leggen de onderzoekers uit.

Diezelfde maand meldde Secureworks de fout aan Microsoft, die vervolgens in juli bevestigde dat dit gedrag bestond, maar besloot dat het “door ontwerp” was.

Deze maand waarschuwt Secureworks zijn klanten voor de fout, volgens een bericht dat door een bron met Ars is gedeeld.

Secureworks e-mailt zijn klanten over de Active Directory-fout van Azure.

Vergroten / Secureworks e-mailt zijn klanten over de Active Directory-fout van Azure. Ax Sharma

Azure AD naadloze SSO-service meldt gebruikers automatisch aan bij hun zakelijke apparaten, verbonden met hun werkpleknetwerk. Als naadloze SSO is ingeschakeld, hoeven gebruikers hun wachtwoorden, of meestal zelfs hun gebruikersnamen, niet in te voeren om zich aan te melden bij Azure AD. “Deze functie biedt uw gebruikers eenvoudig toegang tot uw cloudgebaseerde applicaties zonder dat er extra on-premises componenten nodig zijn”, legt Microsoft uit.

Maar, net als veel andere Windows-services, vertrouwt de naadloze SSO-service op het Kerberos-protocol voor verificatie. “Tijdens de naadloze SSO-configuratie wordt een computerobject met de naam AZUREADSSOACC wordt gemaakt in het on-premises Active Directory-domein (AD) en krijgt de service-principalnaam (SPN) toegewezen https://autologon.microsoftazuread-sso.com“, leggen CTU-onderzoekers uit. “Die naam en de wachtwoordhash van deAZUREADSSOACC computerobject worden verzonden naar Azure AD.”

Het volgende autologon-eindpunt met de naam ‘windowstransport’ ontvangt Kerberos-tickets. En naadloze SSO vindt automatisch plaats zonder enige gebruikersinteractie:

De authenticatieworkflow is gedemonstreerd met de volgende afbeelding:

Demonstratie van het Kerberos-protocol.

Vergroten / Kerberos-protocoldemonstratie.Secureworks

Daarnaast is er een usernamemixedeindpunt op …/winauth/trust/2005/gebruikersnaammixed die gebruikersnaam en wachtwoord accepteert voor verificatie met één factor. Om een ​​gebruiker te authenticeren, wordt hier een XML-bestand met zijn gebruikersnaam en wachtwoord naar verzonden usernamemixed eindpunt.

XML-bestand met gebruikersnaam en wachtwoord.

Vergroten / XML-bestand met gebruikersnaam en wachtwoord.Secureworks

De authenticatieworkflow voor dit eindpunt is veel eenvoudiger:

Autologon gebruikersnaam/wachtwoord aanmeldingsproces.

Vergroten / Autologon gebruikersnaam/wachtwoord aanmeldingsproces.Secureworks

En dit is waar de fout sluipt. Autologon probeert de gebruiker te verifiëren bij Azure AD op basis van de verstrekte referenties. Als de gebruikersnaam en het wachtwoord overeenkomen, is de verificatie geslaagd en reageert de Autologon-service met XML-uitvoer die een verificatietoken bevat, ook wel bekend als DesktopSSOToken, die naar Azure AD wordt verzonden. Als de authenticatie echter mislukt, wordt er een foutmelding gegenereerd.

Het zijn deze foutcodes, waarvan sommige niet correct zijn vastgelegd, die een aanvaller kunnen helpen bij het uitvoeren van onopgemerkte brute-force-aanvallen.

Foutcodes gegenereerd wanneer Autologon-verificatie mislukt.

Vergroten / Foutcodes gegenereerd wanneer Autologon-verificatie mislukt.Secureworks

“Succesvolle verificatiegebeurtenissen genereren aanmeldingslogboeken… Echter, de verificatie van autologon [step] naar Azure AD is niet vastgelegd. Door deze omissie kunnen dreigingsactoren gebruik maken van de usernamemixed eindpunt voor niet-gedetecteerde brute-force-aanvallen”, leggen CTU-onderzoekers uit in hun beschrijving.

De AADSTS-foutcodes die worden gebruikt tijdens de Azure AD-verificatiewerkstroom worden hieronder weergegeven:

Onderzoekers van Secureworks stellen dat de meeste beveiligingstools en tegenmaatregelen die gericht zijn op het detecteren van brute-force- of wachtwoordspray-aanvallen, afhankelijk zijn van log-in gebeurtenislogboeken en zoeken naar specifieke foutcodes. Dit is de reden waarom het een probleem is om geen zicht te hebben op de mislukte aanmeldingspogingen.

“[Our] analyse geeft aan dat de autologon-service is geïmplementeerd met Azure Active Directory Federation Services (AD FS)”, leggen de CTU-onderzoekers uit. “Microsoft AD FS-documentatie raadt aan om internettoegang tot de windowstransport eindpunt. Die toegang is echter vereist voor naadloze SSO. Microsoft geeft aan dat de usernamemixed eindpunt is alleen vereist voor oudere Office-clients die ouder zijn dan de Office 2013-update van mei 2015.”

De fout is niet beperkt tot organisaties die naadloze SSO gebruiken. “Bedreigingsactoren kunnen de autologon misbruiken usernamemixed eindpunt in elke Azure AD- of Microsoft 365-organisatie, inclusief organisaties die Pass-through Authentication (PTA) gebruiken”, leggen de onderzoekers uit. Hoewel gebruikers zonder een Azure AD-wachtwoord onaangetast blijven.

Omdat het succes van een brute-force-aanval grotendeels afhangt van de sterkte van het wachtwoord, heeft Secureworks de fout in zijn beschrijving beoordeeld als ‘gemiddeld’.

Op het moment van schrijven zijn er geen oplossingen of oplossingen bekend om het gebruik van deusernamemixed eindpunt. Secureworks stelt dat het gebruik van Multi-factor authenticatie (MFA) en voorwaardelijke toegang (CA) uitbuiting niet zal voorkomen, omdat deze mechanismen pas optreden na succesvolle authenticatie.

Ars nam ruim voor publicatie contact op met zowel Microsoft als Secureworks. Microsoft heeft niet gereageerd op ons verzoek om commentaar. Secureworks reageerde vreemd genoeg met een uitnodiging voor een toekomstig online evenement, maar gaf geen commentaar op de kwestie.

Zoals hierboven vermeld, lijkt Microsoft dit eerder een ontwerpkeuze dan een kwetsbaarheid te beschouwen. Als zodanig blijft het onduidelijk of en wanneer de fout zou worden verholpen, en organisaties kunnen kwetsbaar blijven voor sluipende brute-force-aanvallen.

By Admin

Leave a Reply

Your email address will not be published. Required fields are marked *