Office365 – jak se dostat dovnitř bez znalosti hesla
Dneska bych se s vámi rád podělil o jeden krátký (kdo mne čtete tak víte, že příliš krátký nebude) článek k bezpečnosti Office365 a odtajním vám největší slabinu cloudových služeb, a proto že jsem člověk zabývající se primárně Microsoft technologiemi, tak vám i ukážu jak je možno se chránit.
Úvodem
Všichni určitě víte co je aplikace Azure AD Connect (kdo neví, tak se jedná o aplikaci, která provádí synchronizaci identit do cloudového prostředí společnosti Microsoft). Microsoft na začátku roku uvolnil verzi, která umožňuje využít službu Azure AD Connect k zajištění přístupu pomocí Seamless Single Sign On (jednotné přihlášení bez znalosti hesla, dále také SSO). Toto přihlášení je založeno na Kerberos autentizaci, jak jsem psal v tomto článku. Tato funkcionalita je obrovským posunem, jelikož nemusíte provozovat ADFS a WAP server, abyste mohli provádět SSO do Office365, Azure, Intune, atd…
SSO a Kerberos je v tomto právě to místo, které je nebezpečné, byť obě cesty jsou vlastně tím nejbezpečnějším co můžete získat, pokud pomineme multi-faktorovou autentizaci (dále také MFA). To co vám dále ukážu vlastně vede jen k tomu, že MFA je bezpodmínečnou nutností a to minimálně pro VIP uživatele a privilegované účty a také jeden z důvodů, proč by neměl být synchronizovaný účet Global Adminem v Office365 službě.
Tím jsme si tedy řekli o čem dneska budeme psát a nyní se pojďme podívat na celý problém a jeho řešení.
Vlastní průnik do Office365 služby
Moje infrastruktura postavená nad lokální doménou defense-ops.local sedí na nějakém serveru v mém datovém centru a na ADFS serveru mám aktuálně nainstalován Azure AD Connect a nastaveno SSO (jak je uvedeno na obrázku níže)
Na koncovém zařízení (klientské PC s Windows 10) jsou nastaveny v Trusted Site a Intranet Site speciální weby, jak je uvedeno třeba v tomto článku a to zejména z toho důvodu, aby SSO fungovalo. Pokud vás zajímá, jak SSO do Office365 vlastně funguje, pak se podívejte třeba v tomto článku nebo jich najdete spoustu i na stránkách Microsoftu přímo.
Osobně jsem si dneska ráno říkal, když tedy do Office365 pro SSO je používán Kerberos, tak musí přeci fungovat i Pass-the-ticket a mělo by to fungovat i pomocí Golden Ticket a tak jsem se rozhodl testovat.
Nejprve jsem se tedy přihlásil na klientskou stanici a otestoval, že SSO funguje jak má pomocí Internet Exploreru a byl jsem samozřejmě bez problému přihlášen do Office365.
Na klientské stanici jsem tedy stáhl poslední verzi aplikace Mimikatz (strašně známý nástroj pro získávání hashů, tiketů, atd..) a spustil pár příkazů s uživatelem a právy lokálního admina.
Čímž se mi do složky spuštění exportovali všechny tickety daného uživatele, které byly aktuálně dostupné v „klist“ na dané stanici.
Nyní jsem tedy složku s tickety stáhnul na mou útočící virtuálku a opět pomocí Mimikatz jsem nahrál tickety do systému, jak je uvedeno níže.
Čímž jsem krásně získal celou session daného uživatele na počítač, který nebyl v doméně a ještě pod účtem, který nemá práva do Office365 a co jsem k tomu potřeboval? Představivost, mimikatz, práva lokálního administrátora s přístupem do Office365, stanici v doméně.
Abych mohl využít SSO do Office365, musel jsem, ale upravit v dané session nastavení Internet Exploreru a tak jsem si připravil .reg file, který jsem spustil z příkazové řádky a následně otevřel okno prohlížeče.
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains]
@=““
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\defense-ops.com]
„*“=dword:00000001
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\lync.com]
„*“=dword:00000001
„https“=dword:00000002
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com]
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon]
„https“=dword:00000001
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftonline.com]
„*“=dword:00000001
„https“=dword:00000002
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\nsatc.net]
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\nsatc.net\aadg.windows.net]
„https“=dword:00000001
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\office365.com]
„*“=dword:00000001
„https“=dword:00000002
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\outlook.com]
„*“=dword:00000001
„https“=dword:00000002
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\sharepoint.com]
„*“=dword:00000001
„https“=dword:00000002
No a nyní už stačilo jen spustit Internet Explorer z dané příkazové řádky v cestě C:\Program Files\Internet Explorer\iexplore.exe, otevřít stránku https://portal.office.com a zadat uživatelské jméno, které jsem si našel v ticketu (chce to trošku hledání, aby jste zjistili skutečnou emailovou adresu (to co má ten uživatel za zavináčem), ale když jste ve vnitřní síti, tak není nic jednoduššího než si vypsat informace z Global Catalogu Active Directory, který je pro všechny uživatele v doméně Read Only).
No a co se stalo? Při kliknutí do řádku pro heslo, jsem byl automaticky přesměrován a přihlášen do Office365 a získal tak přístup s právy daného uživatele k veškerému obsahu v Office365.
Když budeme šikovní tak si ze zálohy nebo snapshotu doménového řadiče vytáhneme Golden Ticket, kterým podepíšeme cokoliv. Což ve výsledku znamená, že si můžeme klidně vystavit takový ticket pro CTO/CFO/CISO/CEO a pak přistupovat k datům v On-Premise, ale také v Office365 a log bude vždy korektní, jelikož se jednalo o uživatele, který měl platný lístek pro přístup.
Lze tomu zabránit?
No jasně, že lze. Dělá to někdo? Bohužel ne. Dá se udělat něco, aby to útočník neměl tak snadné a abychom se o takové činnosti minimálně dozvěděli případně ji můžeme i eliminovat. Řešením může být určitě nástroj, který najdete v licenci Enteprise Mobility + Security (dále také EMS) skrývající se pod názvem Advanced Thread Analytics (dále také ATA). Pokud tento nástroj nasadíte, pak je takovéto chování vždy detekováno a vy máte možnost reagovat na základě doporučení, které vám ATA dává automaticky.
No, nebo vám i přímo řekne, že byla použita technika Golden Ticket.
Pokud máte na daném operačním systému nasazený i antivirový software Microsoft Defender z Windows 10, pak je nástroj Mimikatz automaticky smazán jako malware, ale šikovný Sript Kiddie si překompiluje zdorjáky Mimikatz (open source na GitHubu) a nejsem si jist zda bude nástroj detekován.
Předposlední možností je integrace na Operations Management Suite (dále také OMS), který vám řekne, že byl z koncového zařízení volán tento nástroj, a že jej OMS detekovalo. Případně máte možnost ATA integrovat do KPCS ATOM a tím získat jednotný pohled nad takovouto bezpečnostní hrozbou a to včetně zaslání alertu. V ATA může útočník však logy smazat, ale v případě integrace s KPCS ATOM to již udělat nemůže, jelikož do prostředí OMS je přidělován přístup explicitní a třeba na Live Account Microsoftu a hlavně admin ani nikdo jiný nemá k vlastnímu datovému zdroji přístup.
Poslední možností, kterou máte i v případě použití technik jako Pass-the-ticket, Pass-the-hash nebo Golden Ticket je implementace multi faktorové autentizace a to minimálně pro všechny privilegované účty v cloudu. Tuto funkcionalitu máte v licence Azure AD Premium nebo také v EMS, proto doporučuji pro privilegované účty tuto licenci zakoupit.
Závěrem
Rád bych, abyste si odnesli jednu základní myšlenku a rozhodně to není ta, že Cloud je vlastně nebezpečný. Cloud je bezpečný jen tak, jak jsou bezpečné koncové systémy a jak jsou disciplinovaní uživatelé a hlavně administrátoři. Proto pamatujte, že útok na cloudové prostředí (Amazon, Azure, G-Apps, Office365, aj..) nebude nikdy veden z vnějšího perimetru, protože proražení bezpečnostního mechanismu Microsoftu nebo jiných vendorů je téměř nemožné. Útok půjde přes vaše prostředí a VY musíte zamezit tomu, aby VAŠE identity nebyly odcizeny a vaše prostředí kompromitováno.
A když už se tak stane (a ono se to stane), pak rychlost reakce na vznik bezpečnostního incidentu musí být co nejkratší.
