Det har i åratal varit allmänt känt att lokala Windows Active Directory-nätverk är sårbara för så kallade NTLM relay- (New Technology Lan Manager) och pass-the-hash-attacker som kan göra så att angripare kan röra sig lateralt inom nätverken och få tillgång till fler maskiner och resurser.
Eftersom vissa av dessa attacker exploaterar avvägningar i designen i de protokoll som används i Windowsnätverk kan de helt enkelt inte säkerhetsuppdateras med uppdaterad mjukvara. För att skydda sig behöver organisationer tillämpa ett djupare försvar och vidta åtgärder som innebär striktare konfigurationer och fler kontroller.
Med anammandet av hybrida nätverk, där delar av nätverken är lokala och andra delar ligger i molnet, behöver företag luta sig mot tjänster som Azure Active Directory (Azure AD) för att olika maskiner ska kunna autentisera sig mot varandra. Men Azure AD är ganska annorlunda jämfört med ett lokalt AD eftersom det använder andra protokoll och kommer med nya funktioner som utvidgar nätverksfunktionerna för organisationer. Men enligt flera presentationer under förra årets säkerhetskonferens Black Hat USA ger detta även nya öppningar för angripare.
Från pass-the-hash till pass-the-certificate
Pass-the-hash är en attack där hackare extraherar hashade versioner av lokalt lagrade inloggningsuppgifter från komprometterade maskiner och använder dessa för att autentisera sig mot andra maskiner. NTLM relay är en metod där man genskjuter autentiseringsförfrågningar mellan en klient och en server och vidarebefordrar meddelanden mellan de två parterna så att angriparen blir autentiserad istället för klienten. Dessa attackmetoder används ofta av sofistikerade hackergrupper vid riktade attacker.
Traditionella pass-the-hash- och relä-attacker fungerar dock inte mot Azure AD eftersom Azure AD inte använder NTLM eller Kerberos – standardprotokollen som används vid autentisering mot Windowsnätverk – utan Azure AD använder OAuth, SAML, OpenID och ett nytt protokoll som heter NegoEx som i sin tur är en utökning av det standardiserade protokollet Generic Security Services Application Program Interface (GSSAPI) som Kerberos bygger på.
Enligt forskaren Mor Rubin på Microsoft kommer NagoEx att aktiveras på alla enheter som anluter till Azure AD och är den mekanism genom vilka olika Azure AD-anslutna enheter autentiserar sig mellan varandra. Handskakningen i autentiseringen i NegoEx lutar sig mot ett klientcertifikat som är unikt för varje användare och som ges ut av Azure AD med en giltighet på en timme.
Under Black Hat-konferensen demonstrerade Rubin hur en relä-attack kan genomföras mot en NegoEx-handskakning på ett liknande sätt som det kan utföras mot NTLM. Han visade sedan hur en angripare kan komma över klientens peer-to-peer-certifikat och sedan använda det certifikatet för att autentisera sig mot andra maskiner. Med andra ord är dessa attacker ekvivalenta med NTLM-, relä- och pass-the-hash-attacker, men i en kontext av Azure AD-anslutna enheter oavsett olikheterna i de protokoll som används.
Rubin föreslår att företag kontrollerar loggarna på sina Azure AD-maskiner efter autentiseringsförfrågningar från klienter vars namn och ipadress inte matchar eller efter autentiseringsförfrågningar via certifikat utställda till användare som inte är associerade med den maskin förfrågningen gäller. Rubins presentation var kulmen på den forskning han började med förra året och blev också en premiär för verktyget Negoexrelayx, som är ett relä-verktyg för NegoEx under öppen källkodslicens.
Utnyttjande av externa identiteter i Azure AD
I en annan presentation under Black Hat-konferensen, med fokus på specifika Azure AD-attacker som inte finns i lokala AD-installationer, demonstrerade den nederländske forskaren Dirk-Jan Mollema på Outsider Security hur han hittade ett sätt att utnyttja funktionen med externa identiteter för att skapa en bakdörr till Azure AD-konton.
Externa identiteter är en funktion i Azure AD som organisationer kan använda för att ge externa användare tillgång till vissa resurser. Dessa användare kan tillhöra en annan del av Azure AD eller så kan de autentiseras genom en extern tillhandahållare och identifieras endast med en e-postadress. Denna funktion är populär bland organisationer som arbetar med externa konsulter men även för att ge access för it-tjänsteleverantörer som hanterar prenumerationer.
Externa användare kan bjudas in av någon med administratörsrättigheter genom Azure AD-gränssnittet och detta genererar en inbjudningslänk som skickas med epost till den externa användaren. Problemet, som Mollema hittade, är att inbjudningar även kan genereras och accepteras programmatiskt genom Azure ADs API som kallas AAD Graph.
Det visade sig också att inte många kontroller genomfördes när man interagerar med denna funktion genom API:et. För det första kunde vilken användare som helst inom en Azure AD-avdelning göra förfrågningar mot API:et och se vilka inbjudningar som hittills inte lösts in, för det andra kunde vilken inbjudan som helst lösas in genom API:et utan någon validering och kunde länkas till ett annat externt konto än det som avsågs. För det tredje hade administratörerna ingen möjlighet att avgöra om en inbjudan kapats genom gränssnittet.
Attacken kunde också ta sig runt listan över tillåtna domäner för externa samarbeten i Azure AD-avdelningen eftersom inbjudningen kunde genereras för en e-postadress inom en domän, men sedan kapas och länkas till ett konto som inte fanns i listan. Som lök på laxen kan det finnas automatiska regler som automatiskt ger ett konto som löser in en inbjudan en högre privilegienivå, vilket leder till eskalering av privilegier.
Mollema drog sedan attacken ett steg längre. Genom att analysera hur de externa identiteterna såg ut i Microsoft Graph – ett API för utvecklare – istället för AAD Graph, insåg Mollema att vissa av egenskaperna som associerades med en identitet kunde modifieras genom MS Graph, givet rätt privilegier. Ett av dessa attribut är en egenskap hos utgivaren som definierar identitetsleverantören, och en av valmöjligheterna var helt enkelt ”epost”. Detta används för externa användare som endast identifieras med e-postadressen och som så långt inte har ett Microsoft- eller Azure AD-konto.
Sedan tittade Mollema på vem som kunde modifiera dessa attribut och fann att utöver administratörer kunde applikationer som användare loggar in i, och har de rätta privilegierna, också modifiera identiteter, och användare kan också modifiera sina egna identiteter genom MS Graph. Detta öppnade dörren för intressanta attacker, som att lägga in bakdörrar i existerande konton om en angripare får tillfällig tillgång till dem genom att stjäla en access-token, eller genom att få tillfällig kontroll över en dator där användaren har en aktiv session.
Om kontot dessutom råkar vara användarens administratör kan angriparna skapa bakdörrar för alla konton genom att lägga till externa identiteter till dem och länka dem till e-postadresser som angriparna kontrollerar. De kan även göra detta för globala administratörer eftersom de har rättigheter att modifiera deras identiteter genom MS Graph.
Baksidan med att modifiera en identitet på detta sätt är att det bara ändrar den primära autentiseringsmetoden från användarnamn och lösenord till autentisering via en extern e-postadress. Om kontot även är säkrat med multifaktorautentisering kan angriparen fortfarande inte logga in.
Men Mollema fann ett sätt att runda detta också. För det första använde han det tillfälligt komprometterade offerkontot för att generera en inbjudan för angriparens externa konto. Angriparen accepterade sedan inbjudan vilket fick till följd att ett gästkonto skapades för angriparen i offrets avdelning. Angriparen loggade sedan in med gästkontot och konfigurerade multifaktorautentisering för det kontot.
Angriparen raderade sedan gästkontot med hjälp av offrets konto. Emedan detta raderar gästkontot som är associerat med angriparens externa konto, rensar det inte kontots multifaktortoken utan den ligger kvar i en buffer. Så angriparens externa konto fortsätter att ha en aktiv token i offrets Azure AD-avdelning även om det associerade gästkontot är borta. Angriparen kan sedan skapa en bakdörr till offrets konto och lägga till sitt konto som en identitet, och därefter kommer angriparen inte längre att behöva autentisera sig med multifaktorautentisering. Detta rundar offrets flerfaktorsskydd.
Hur man motverkar sårbarheter i molnbaserad autententisering i Azure AD och andra
Microsoft har redan skapat uppdateringar mot de sårbarheter som Mollema upptäckte, så de attacker han beskrev fungerar inte längre. Men hans fynd visar hur komplext autentisering kan vara i nya molnmiljöer. Introduktionen av nya funktioner, som att tillåta engångslösenord per epost som en identitetsleverantör eller externa identiteter, kan alltid resultera i logiska fel som kan öppna för genvägar.
Mollema råder organisationer att regelbundet ta bort alla gästkonton med oinlösta inbjudningar, att låsa ned rätten att skapa gästinbjudningar och för inställningarna för gästernas rättigheter, begränsa Azure AD-avdelningar som kan samarbeta externt, införa multifaktorautentisering för alla applikationer, och nagelfara accessloggarna för tecken på potentiella utnyttjanden av gästkonton.