V červenci jsem dělal bezpečnostní audit jedné větší AD infrastruktury a jen tak mimochodem jsem objevil jednu velmi nepříjemnou věc. Vzniklo to v kombinaci RODC a Office365 DirSync nástroje. A byla to věc pekelně nepříjemná. Dokonce jsem to reportoval do MS, ale pánové to na security bouletin nepovažovali. Tvrdí, že předchozí kompromitace účtu (prior account compromise) nerovná se bezpečnostní zranitelnost (security vulnerability). Já taky ne.
Já si totiž myslím, že pokud instalační program Office365 DirSync sám takovou kompromitaci způsobuje, tak to je spíš pěkný průser.
Office365 DirSync a MSOL_ účet
DirSync pro Office365 je nástroj, který umí synchronizovat parametry uživatelských účtů z on-premisses Active Directory do Office365 Azure AD. Umí také vycucávat heše (hash) hesel přímo z AD a zapisovat je na účty v Office365 AAD, takže uživatelé mají stejné heslo jak v on-premisses tak v cloudu. A to může být právě ten kámen úrazu.
DirSync je ve skutečnosti FIM (Forefront Identity Manager) ořezaný o téměř všechny management agenty, takže umí pouze cucat z AD a z AAD. K tomu, aby mohl stahovat data z Active Directory používá uživatelský účet, kterému se musí na úrovni domény přidělit oprávnění (permission) pro replikaci.
Pokud nesynchronizujete hesla, stačí mu Replicate Directory Changes. To ho opravňuje, aby si stáhnul všechno z AD databáze, kromě tajný informací. Nemůže si stáhnou heše hesel, ani jiné confidential atributy. Confidentia attribute jsou třeba privátní klíče certifikátů při zapnutém Credentials Roamingu - msPKIAccountCredentials, nebo tajné údaje k TPM a BitLockeru - msTPM-OwnerInformation, nebo msFVE-RecoveryPassword a msFVE-KeyPackage, a nebo KDS klíče v atributech msKds-RootKeyData.
Pokud není synchronizace hesel, tak mu stačí jen v podstatě veřejné informace. To je ok.
Ale pokud děláte synchronizaci hesel, tak jeho replikační účet musí mít Replicate Directory Changes All oprávnění (permission). To si potom může stáhnout celý obsah AD. To zahrnuje heše hesel členů Domain Admins. To zahrnuje také heše účtu krbtgt, pomocí kterých se generují Kerberos tikety.
Pokud by se někomu podařilo získat heslo (nebo heš) k takovému DirSync účtu, stal by se okamžitě pánem celého AD forestu. Pomocí hash krbtgt účtu by si mohl vytvářet "zlaté Kerberos tikety" a pomocí hash účtů Domain Admins z libovolné jediné domény celého forestu by se stal pánem celého forestu.
Jen pro pořádek uveďme, že oprávnění Replicate Directory Changes ani Replicate Directory Changes All neumožňují do AD něco vložit - replikace je vždycky pouze download a žádná "push replikace" neexistuje.
Je tedy jasné, že DirSync účet je potřeba do krve chránit.
Jak k ochraně takového účtu přistupuje DirSync instalační program
Instalace DirSync si prostě takový účet sama vytvoří. Dá mu jméno MSOL_randomnumber a umístí ho nenápadně do CN=Users kontejneru. A neřekne vám o tom ani slovo.
To by ještě tak nevadilo, protože heslo k tomu účtu nezná nikdo jiný, než DirSync - je uloženo v jeho SQL databázi. Jenže opravdu ho nezná nikdo jiný?
A vstupuje do hry RODC
RODC jsou řadiče domény určené do nebezpečných provozů, kde je riziko kompromitace citlivých účtů. Proto se do RODC nereplikují ve výchozím stavu hesla (hash) účetů skupin jako jsou Domain Admins, Enterprise Admins, nebo právě krbtgt účtu. Pokud chcete, aby se tam nějaké účty (přesněji jejich heše) replikovaly, musíte je explicitně vyjmenovat. Můžete také pro některé skupiny explicitně zakázat replikaci. Zákaz je vždy silnější než povolení.
Tomu se říká Password replication policy pro RODC. Existuje skupina, která je ve výchozím stavu vynechána z replikace do RODC. Jmenuje se Denied RODC password replication group. Pokud do ní dáte nějaký účet, tak se jeho heslo (hash) do RODC nereplikuje. Jednoduché a efektivní.
A tady je to kouzlo. Nebo spíš průser. V onom prostředí měli v password replication policy pro jejich několik RODC vloženou skupinu Domain Users. Bezpečnostně to nevadilo, protože všechny citlivé účty měli explicitně zablokované. Takže v RODC byly jen necitlivé účty uživatelů, které tam byly oprávněně. Jistě, to jsem jim vytýkal už dřív, že je lepší tam dát nějakou konkrétní skupinu a ne rovnou Domain Users, ale co už, když blokují striktně ty nebezpečné účty.
Pokud o nich vědí.
Takže jsem zjistil, že se ten DirSync automatický MSOL_randomnumber účet replikuje na všechna jejich RODC. Při kompromitaci libovolného RODC by měli kompromitaci celého forestu.
Proč? Protože ten propracovaný DirSync instalátor vytváří automaticky ultra-super-účet, nikomu o tom neřekne a ani ho nedá do Denied RODC password replication group.
Jak zabezpečit DirSync pro Office365?
Pokud používáte DirSync a synchronizujete hesla, dávejte na to obzvláště pozor. Onen MSOL_somenumber účet je kritický, je roven skupině Domain Admins. Ideálně ho dejte rovnou do Denied RODC password replication group a dávejte na něho zvýšený pozor.
A samozřejmě si uvědomte, že musíte dát slušnou bezpečnost i tomu DirSync serveru. Stejnou, jakou dáváte ostatním řadičům domény (DC, domain controller). Pokud jim nějakou dáváte :-)
Tak dobrý den!
Nějaké moje další článečky o Office365 a DirSync najdete zde a zde například.