Článek přečtěte do 10 min.

Synchronizační funkce společnosti Microsoft pro správu identit v hybridních prostředích nejsou bez rizika. V tomto článku Tenable Research zkoumá, jak lze využít potenciální slabiny těchto možností synchronizace.

Synchronizace účtů identit mezi Microsoft Active Directory (AD) a Entra ID je důležitá pro uživatelské prostředí, protože bezproblémově synchronizuje uživatelské identity, přihlašovací údaje a skupiny mezi místními a cloudovými systémy. Tenable Research zároveň ukazuje, že následující možnosti synchronizace mohou představovat riziko kybernetické bezpečnosti, které přesahuje hybridní nájemce:

  • již známá role Directory Synchronization Accounts Entra
  • nová role On Premises Directory Sync Account Entra
  • novou aplikaci Microsoft Entra AD Synchronization Service

V roce 2024 společnost Microsoft představila dvě nová opatření pro posílení zabezpečení pro hybridní synchronizaci Entra ID. Navzdory těmto vylepšením si však účty synchronizace adresářů i nové role On Premises Directory Sync Account zachovávají přístup ke kritickým rozhraním API pro synchronizaci. Nová aplikace „Microsoft Entra AD Synchronization Service" navíc odhaluje privilegované ADSynchronization.ReadWrite.Alloprávnění a představuje další potenciální cestu útoku, kterou musí bezpečnostní týmy bedlivě sledovat.

V tomto technickém blogu rozebíráme změny, které společnost Microsoft provedla u každé ze svých možností synchronizace, prozkoumáváme, kde byla zavedena nová rizika, a poskytujeme pokyny, jak vám Tenable Identity Exposure může pomoci monitorovat a zabezpečit vaše hybridní synchronizační prostředí.

Synchronizace adresářů Role účtů: Kde to všechno začíná

V hybridních prostředích jsou Entra ID – poskytovatel identity v sadě produktů Entra společnosti Microsoft – a Active Directory (AD) synchronizovány prostřednictvím specifického servisního účtu v Entra ID (nazývaného "SYNC_…_"pro Entra Connect a "ADToAADSyncServiceAccount"pro Entra Cloud Sync). Tomuto účtu služby je přiřazena role Entra s názvem Účty synchronizace adresářů a je skrytý v Azure Portal / Entra Admin Center.

V srpnu 2024 společnost Microsoft v rámci svého úsilí o posílení zabezpečení oznámila, že odstranila nepoužívaná oprávnění z privilegované role Účty synchronizace adresářů.

snímek obrazovky s oznámením společnosti MIcrosoft týkající se omezených oprávnění k účtům synchronizace adresářů

V Tenable Research nás zajímalo: jak může synchronizace Entra ID <-> AD nadále fungovat po tomto snížení oprávnění?

Odpověď: naše testy ukázaly, že role Directory Synchronization Accounts je stále privilegovaná, protože může pokračovat ve volání synchronizačního API.

V prosinci 2024 společnost Microsoft oznámila druhé posílení zabezpečení představením nové aplikace s názvem Microsoft Entra AD Synchronization Service.

Snímek obrazovky oznámení společnosti MIcrosoft pro obecnou dostupnost služby Microsoft Entra AD Synchronization Service

Tenable Research jsme byli na tuto novou aplikaci přirozeně zvědaví. jak to vypadá? Jaké jsou jeho vlastnosti? Má to API? Má nebo odhaluje zajímavá oprávnění?

Odpověď: Tato aplikace zpřístupňuje ADSynchronization.ReadWrite.Alloprávnění API, které je privilegované, protože umožňuje volání rozhraní API pro privátní synchronizaci.

Synchronizace adresářů Účty Role Entra zůstává privilegovaná

V červnu 2024 jsem prozkoumal roli „Účty synchronizace adresářů" v článku Skrytá vytrvalost s rolí „Účty synchronizace adresářů" v Entra ID. Vysvětlil jsem dva způsoby, jak byla role privilegována:

  • měl privilegovaná oprávnění Entra; a
  • měl implicitní oprávnění v soukromém nezdokumentovaném rozhraní API „Azure AD Synchronization" (to na adrese https://adminwebservice.microsoftonline.com/provisioningservice.svc).

Poslední jmenovaná je také nazývána Služba poskytování synchronizace" od Dr. Nestori Syynimaa, který ji implementoval v AADInternals.

Srpnová aktualizace zabezpečení zavedla řadu změn v roli Účty synchronizace adresářů, ale odstranily tyto změny úspěšně oprávnění této role?

Snížená oprávnění v roli Účty synchronizace adresářů

Role Účty synchronizace adresářů měla dříve 48 oprávnění role Entra. V důsledku zpřísnění zabezpečení prošel drastickým snížením, kdy Microsoft všechny odstranil a nahradil je pouze jedním :microsoft.directory/onPremisesSynchronization/standard/read . Nyní, když má role pouze toto oprávnění ke čtení, již není privilegovaná, což by vás mohlo vést k domněnce, že není nebezpečná.

snímek obrazovky s pokyny „nepoužívat

Dříve tato role zahrnovala microsoft.directory/applications/credentials/updatemicrosoft.directory/servicePrincipals/credentials/update, což umožňovalo útočníkům přidávat přihlašovací údaje do privilegovaných aplikací/instancí služeb, aby se mohli ověřit jako tyto instanční objekty a využívat jejich oprávnění. Díky tomu byla role privilegovaná.

Fabian Bader v roce 2023 popularizoval podobnou techniku ​​zneužívání této role převzetím privilegovaných aplikací prostřednictvím oprávnění microsoft.directory/applications/owners/updatemicrosoft.directory/servicePrincipals/owners/update. Poté , co Microsoft tato oprávnění odstranil, aktualizoval svůj článek From on-prem to Global Admin bez resetování hesla.

Ale oprávnění pro Synchronization API byla implicitní v roli Directory Synchronization Accounts, tj. nebyla uvedena jako oprávnění role Entra v samotné roli. Tak co s nimi?

Oprávnění rozhraní API pro implicitní synchronizaci jsou stále přítomna

Protože jsou implicitní, věděl jsem, že jediný způsob, jak otestovat jejich privilegia, bylo jednoduše to vyzkoušet a zjistit, co se stalo.

Vytvořil jsem uživatele, přiřadil mu pouze roli Účty synchronizace adresářů a použil odpovídající příkazy sady nástrojů AADInternals, jako Set-AADIntAzureADObjectSet-AADIntUserPassword. Ty nadále fungovaly jako před zpřísněním zabezpečení společnosti Microsoft. Zde je důkaz s obnovením hesla:

PS C:\> Import-Module -Name AADInternals
[...]
PS C:\> $at = Get-AADIntAccessTokenForAADGraph
Logging in to Microsoft Services
Enter email, phone, or Skype: @.onmicrosoft.com
Password: 
PS C:\> $userid = (Read-AADIntAccesstoken $at).oid
PS C:\> Connect-AzureAD -AadAccessToken $at -TenantId  -AccountId $userid
[...]
PS C:\> Get-AzureADUserMembership -ObjectId $userid | Where-Object 
ObjectId    DisplayName                         Description
--------    -----------                         -----------
  Directory Synchronization Accounts  Only used by Azure AD Connect service.
PS C:\> Set-AADIntUserPassword -AccessToken $at -SourceAnchor  -Password 
CloudAnchor  Result  SourceAnchor
-----------  ------  ------------
CloudAnchor  0       

To Resultznamená 0, že reset hesla fungoval.

Dospěl jsem k závěru, že tato implicitní oprávnění zůstávají v roli Účty synchronizace adresářů přítomna, a proto je tato role stále privilegovaná. Lze jej použít k vytváření a úpravě uživatelů, resetování jejich hesla a správě synchronizovaných skupin. To není tak překvapivé; Předpokládal jsem, že tomu tak bude, protože jak jinak by mohl proces synchronizace AD ​​<-> Entra ID pokračovat v práci po masivním snížení oprávnění?

Před chvílí jsem přemýšlel, zda to nebylo možné prostřednictvím microsoft.directory/passwordHashSync/allProperties/allTaskspovolení Entra v roli, ale jak vidíme, funguje to i bez něj, takže tato hypotéza je zamítnuta. Je to skutečně implicitní a skryté povolení.

Při zneužívání soukromého nezdokumentovaného rozhraní API synchronizace Azure AD samozřejmě existují určitá omezení . Toto rozhraní API je například určeno pouze pro správu hybridních uživatelů. V Entra ID můžete mít také cloudové uživatele a hybridní uživatele. Dříve bylo toto API povoleno dotýkat se obou typů uživatelů. To nebylo nutné a v případě zneužití by to mohlo vytvořit větší rádius výbuchu, než je nutné. Microsoft to vyřešil omezením výkonu tohoto API pouze na hybridní uživatele.

Což je mimochodem jeden z důvodů, proč máme indikátor expozice v Tenable Identity Exposure, abychom ověřili, že privilegované účty v Entra ID jsou pouze cloudové. Ale i přes tato omezení můžeme souhlasit s tím, že role Účty synchronizace adresářů je dostatečně riskantní, aby vyvolala obavy.

A co nová role On Premises Directory Sync Account Entra?

Microsoft oznámil snížení oprávnění jako součást svého počátečního posílení zabezpečení v srpnu 2024. Všimli jsme si , že se věci pohnuly před měsícem, když jsem objevil novou zajímavou roli s názvem On Premises Directory Sync Account. Tato nová role je velmi podobná roli Účty synchronizace adresářů, kterou velmi dobře znám. Oba jsou skryté v Azure Portal / Entra Admin Center. Role On Premises Directory Sync Account je dokonce nezdokumentovaná. Je to pravděpodobně proto, že je nemají používat zákazníci. Přesto oba zůstávají přítomni a jsou k dispozici pro zneužití útočníky.

Není mi jasné, jaké byly důvody společnosti Microsoft pro vytvoření nové role On Premises Directory Sync Account. Možná je to určeno pro použití s ​​Entra Cloud Sync a starým pro Entra Connect, jak si také myslel Nathan McNulty. Z popisů Entra Connect a Entra Cloud Sync to není jasné a oba synchronizační software stále používají starou roli Directory Synchronization Accounts. Pokud máte někdo tušení, dejte mi prosím vědět!

Zde jsou podrobnosti o obou rolích pocházejících z Microsoft Graph API:

Stará role Nová role
Zobrazovaný název Účty pro synchronizaci adresářů Účet On Premises Directory Sync
ID d29b2b05-8046-44ba-8758-1e26182fcf32 a92aed5d-d78a-4d16-b381-09adb37eb3b0
Popis Používá se pouze službou Microsoft Entra Connect. Používá se pouze synchronizačním účtem Microsoft Entra Connect.
Bohatý popis Tato role je automaticky přiřazena službě Microsoft Entra Connect a není určena ani podporována pro žádné jiné použití. Tato role je automaticky přiřazena k účtu Microsoft Entra Connect Sync Account a není určena ani podporována pro žádné jiné použití.
Oprávnění microsoft.directory/onPremisesSynchronization/standard/read microsoft.directory/onPremisesSynchronization/standard/read
je privilegovaný falešný falešný

Přirozeně mě napadlo, jestli existuje rozdíl při volání rozhraní Synchronization API, ale ukázalo se, že obě role umožňují stejné operace. Zde je stejný důkaz jako dříve, tentokrát s uživatelem s rolí On Premises Directory Sync Account:

PS C:\> Import-Module -Name AADInternals
[...]

PS C:\> $at = Get-AADIntAccessTokenForAADGraph
Logging in to Microsoft Services
Enter email, phone, or Skype: @.onmicrosoft.com
Password: 

PS C:\> $userid = (Read-AADIntAccesstoken $at).oid

PS C:\> Connect-AzureAD -AadAccessToken $at -TenantId  -AccountId $userid
[...]

PS C:\> Get-AzureADUserMembership -ObjectId $userid | Where-Object 

ObjectId    DisplayName                         Description
--------    -----------                         -----------
  On Premises Directory Sync Account  Only used by Microsoft Entra Connect Sync Account.

PS C:\> Set-AADIntUserPassword -AccessToken $at -SourceAnchor  -Password 
CloudAnchor  Result  SourceAnchor
-----------  ------  ------------
CloudAnchor  0       

Jak jsme poznamenali u staré role Directory Synchronization Accounts, nová role On Premises Directory Sync Account se také může dotknout pouze hybridních uživatelů a nemůže upravovat aplikace/instantory služeb Entra, protože ani ona nemá potřebná oprávnění. Navíc nejnovější verze Entra Connect (2.4.129.0 v době vzniku tohoto blogu) nadále vytváří uživatele s názvem On-Premises Directory Synchronization Service Account s přiřazenou starou rolí Directory Synchronization Accounts.

Tenable považuje obě synchronizační role Entra za privilegované

Podle nové funkce privilegovaných rolí a oprávnění Entra ID nejsou tyto role považovány za privilegované. Nová funkce označí některá oprávnění jako privilegovaná, která pak přejdou na všechny role, které mají alespoň jedno privilegované oprávnění. Protože role Účty synchronizace adresářů a Účty místní synchronizace adresářů nemají privilegovaná oprávnění, nejsou označeny jako privilegované.

Tenable s tímto závěrem zdvořile nesouhlasí kvůli možnosti zneužití těchto rolí.

Nyní si promluvme o této nové aplikaci: Microsoft Entra AD Synchronization Service

Ne, Entra „AD" není překlep. A i když název může vést k závěru, že se jedná o zcela novou nabídku, zdá se, že název pravděpodobně naznačuje jeho funkci jako mostu mezi Entra [ID] a AD.

Microsoft popisuje službu Entra AD Synchronization Service jako „vyhrazenou aplikaci první strany, která umožňuje synchronizaci mezi Active Directory a Microsoft Entra ID". Je popsána jako určená pro nájemce zákazníků používající službu Microsoft Entra Connect Sync nebo Microsoft Entra Cloud Sync. Zatímco Microsoft o této nové aplikaci komunikoval v prosinci a zpřístupnil ji všem tenantům, prozatím se nepoužívá. Alespoň ne veřejně. Mým cílem zde o tom diskutovat je zvýšit povědomí o tom, že ačkoli tato aplikace ještě není obecně používána, je dostupná a již otevřená pro potenciální zneužití.

Jako aplikace první strany je objekt aplikace (neboli „registrace aplikace") hostován v tenantovi společnosti Microsoft, zatímco odpovídající objekt Service Principal (SP) (neboli „podniková aplikace") je vytvořen v tenantovi zákazníka (viz níže). Níže jsou uvedeny klíčové charakteristiky této hlavní služby (získané prostřednictvím rozhraní Graph API):

Atribut Hodnota
displayName Synchronizační služba Microsoft Entra AD
id Není relevantní, protože je u každého nájemce jiný
appId 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016
appOwnerOrganizationId f8cdef31-a31e-4b4a-93e4-5f571e91255a
(známý tenant „Microsoft Services", kde je registrováno mnoho aplikací první strany)
servicePrincipalNames [„6bf85cfa-ac8a-4be5-b5de-425a0d0dc016"]

V mém testovacím tenantovi tento SP nemá udělena žádná oprávnění k aplikaci/delegovaná oprávnění. Její související aplikace však poskytuje dvě oprávnění:

  • oprávnění aplikace (appRoles): ADSynchronization.ReadWrite.Alls IDab43b826-2c7a-4aff-9ecd-d0629d0ca6a9
  • delegované oprávnění (publishedPermissionScopes): ADSynchronization.ReadWrite.Alls ID0b41ed4d-5f52-442b-8952-ea7d90719860

SP nemá nastaveno žádné heslo/klíč/federovaná pověření. Entra ID zablokovalo mé pokusy přidat nějaké ( CannotUpdateLockedServicePrincipalProperty), což je podle mého názoru způsobeno zámkem vlastnosti instance aplikace.

Jak tedy získat tento SP ve svém nájemci, pokud jej ještě nemáte? Entra Connect jsem již měl v testovacím tenantovi, takže jsem jej musel přeinstalovat, což spustilo vytvoření SP. Podle protokolů auditu jej překvapivě vytvořil uživatel klasické synchronizační služby ( "SYNC_…_"pro Entra Connect):

snímek obrazovky protokolu auditu služby synchronizace služby Microsoft Entra AD

Možná jste si na výše uvedeném obrázku všimli následující zajímavé vlastnosti Credential:[]

Pozoroval jsem totéž u jiných SP, takže to můžeme ignorovat.

Nebezpečí ADSynchronization.ReadWrite.All

Nyní vím, že aplikace „Microsoft Entra AD Synchronization Service" zpřístupňuje jediné oprávnění: ADSynchronization.ReadWrite.All. Toto oprávnění je k dispozici jako oprávnění aplikace i jako delegované oprávnění. Tak jsem to zkusil použít s klientem Service Principal.

  1. Vytvořte registraci aplikace
  2. V nabídce „Oprávnění API" klikněte na „Přidat oprávnění" a vyhledejte API „Microsoft Entra AD Synchronization Service":snímek obrazovky klientské aplikace pro synchronizační službu Microsoft Entra AD
  3. Vyberte typ „oprávnění aplikace". Je jen jeden, jak už vím, tak ho zkontroluji a přidám:Snímek obrazovky žádosti o oprávnění API ve službě Microsoft Entra AD Synchronization Service
  4. Udělení souhlasu správce:snímek obrazovky klientské aplikace pro oprávnění API služby synchronizace služby Microsoft Entra AD
  5. Přidělte přihlašovací údaje klientské aplikaci, abyste umožnili ověření jako její SP

Nyní, když mám nového klienta SP s tímto oprávněním uděleným na rozhraní Microsoft Entra AD Synchronization Service API, jak jej používat?

Na Microsoft Entra AD Synchronization Service SP nemám ponětí (např. URL odpovědi), kde je odpovídající API. Ale vím, že to souvisí se synchronizací a předpokládám, že to má nahradit obvyklý servisní účet. Pokusím se tedy získat přístup k rozhraní API pro synchronizaci. Toto je API, o kterém jsme hovořili dříve v tomto blogu – soukromé nezdokumentované API „Azure AD Synchronization" na adrese https://adminwebservice.microsoftonline.com/provisioningservice.svc, nazývané také „ Služba zajišťování synchronizace " od Dr. Nestori Syynimaa, který ji implementoval do AADInternals.

Tenable Identity Exposure považuje „ADSynchronization.ReadWrite.All" za nebezpečné

Tenable Identity Exposure má dva indikátory expozice související s tématem nebezpečných oprávnění API:

Byly zaměřeny na nebezpečná oprávnění pro Azure AD Graph a MS Graph API, ale po tomto výzkumu jsme je rozšířili o ADSynchronization.ReadWrite.Alloprávnění pro Microsoft Entra AD Synchronization Service API (viz snímek obrazovky níže).

Snímek obrazovky klientské aplikace Tenable Identity Exposure pro synchronizační službu Microsoft Entra AD

Zde bych chtěl zdůraznit, že většina online zdrojů a nástrojů se zaměřuje na kontrolu oprávnění udělených pro dvě nejznámější API — oprávnění Azure AD Graph a MS Graph API, např. RoleManagement.ReadWrite.Directory. Tím, že se organizace zaměří pouze na tato dvě rozhraní API, riskují, že přehlédnou nebezpečné oprávnění v rozhraní Microsoft Entra AD Synchronization Service API. K řešení těchto oprávnění můžete použít Tenable Identity Exposure, nebo můžete zkontrolovat své skripty/nástroje a lépe zabezpečit prostředí hybridní identity.

Závěr

I po zpřísnění úsilí společnosti Microsoft v roce 2024 zůstává hybridní synchronizace Entra ID kritickým bodem expozice. Role ‚Účty synchronizace adresářů' a ‚Účet synchronizace adresářů v místním prostředí' si stále zachovávají implicitní přístup k citlivým synchronizačním rozhraním API a nová aplikace ‚Microsoft Entra AD Synchronization Service' zavádí výkonné oprávnění ADSynchronization.ReadWrite.All – vytváří další riziko v případě zneužití.

Bezpečnostní týmy by měly proaktivně monitorovat tyto role a oprávnění ve svých prostředích, zacházet s nimi jako s privilegovanými a zajistit, aby byly průběžně vyhodnocovány z hlediska rizik expozice. Tenable Identity Exposure zohledňuje tyto vyvíjející se expozice, které pomáhají obráncům zůstat napřed.

Společnost Tenable Research bude tento vývoj i nadále sledovat, aby našim zákazníkům poskytla co nejpřesnější ukazatele – zajistí vám viditelnost potřebnou k ochraně vašich hybridních identitních prostředí.

Pro více informací nás neváhejte kontaktovat.

Zdroj: Tenable