10.8 Zkouškové okruhy

Tato sekce obsahuje vypracované odpovědi na zkušební okruhy vztahující se ke kapitole 10 (Active Directory).

Otázka 31: LDAP: what is it and how to test it.
LDAP (Lightweight Directory Access Protocol) je otevřený síťový protokol určený k přístupu a údržbě distribuovaných adresářových informačních služeb (např. Active Directory). Běží typicky na portu 389/TCP nebo 636/TCP (pro zabezpečené LDAPS). V rámci AD zajišťuje strukturované dotazování a manipulaci s doménovými objekty (uživatelé, skupiny, stroje, pravidla).

Jak testovat (how to test it):
  • Anonymní spojení (Null/Anonymous bind): Nejprve se zjišťuje, zdali lze k LDAP přistoupit bez platných autentizačních údajů a jestli server neodpoví s detailními údaji o Active Directory topologii nebo dovolí vyhledávat skrze BaseDN.
  • Enumerace (Enumeration): Po vytvoření platného (nebo anonymního) připojení lze zkoumat a získávat citlivá data (skupiny, účty s kerberoasting/as-rep možností, struktura hesel v Description poli, SPN atd.) pomocí nástrojů typu PowerView nebo ldapsearch.
  • Sběr dat (Data collection pro BloodHound): Lze použít nativního LDAP a API přístupu pomocí programu Sharphound k přečtení atributů a exportu topologie s právy (ACLs/ACEs) pro grafovou vizualizaci k nalezení skrytých eskalací.
Otázka 32: Active Directory and Kerberos basics.
Active Directory (AD): Je adresářová služba a databáze vyvinutá Microsoftem pro centrální správu sítí Windows (tzv. Domain networks). Jádro se nachází na serverech nazývaných Doménové řadiče (Domain Controllers - DC), které sdílejí databázi ntds.dit. Logickou hierarchii řídí Forests, Trees a Domains s následným členěním do OUs (Organization Units). Podporují bezpečnostní prvky a aplikaci politik (Group Policy Objects).

Kerberos: Hlavní autentizační síťový protokol uvnitř Active Directory. Klient nezadává a neposílá heslo přes síť ke službě (až na NTLM fallbacky). Identitu ověřuje u důvěryhodné třetí strany — tzv. KDC (Key Distribution Center na doménovém řadiči) ve dvou krocích. KDC v prvním vydává hlavní identitní lístek TGT (Ticket Granting Ticket) přes Authentication Server a ve druhém vyměňuje z předloženého TGT lístku pro uživatele finální servisní lístky (Service Ticket) pro konkrétní službu v doméně, přes službu Ticket-Granting Server (TGS). Lístky pracují čistě se jmény (hostnames) a silně závisí na čase.
Otázka 33: AS-REP Roasting/Kerberoasting: what is it, how does it work, why does it work?
Jedná se o offline hrubou sílu směřovanou proti kryptografickým hashům Kerberos komunikace, u nichž lze získat šifrované "tikety" bez znalosti cílového hesla.

AS-REP Roasting: Cílí na starší uživatelské účty se zapnutým parametrem "Do not require Kerberos preauthentication". Útočník odešle za uživatele falešný prvotní AS_REQ, server si neověří jeho totožnost heslem a automaticky odpoví AS_REP, jehož část tvořící TGT pro uživatele je šifrována právě jeho uživatelským hashem (klíčem). Stačí to rozlouskat a získá čisté heslo uživatele.

Kerberoasting: Cílí na aplikační (servisní) doménové účty mající nastavené ServicePrincipalName (SPN) (ne běžné uživatele bez služeb). Jakýkoliv běžný (útočníkem i malými právy kompromitovaný) uživatel mající validní TGT v doméně se může řadiče doptat na servisní lístek k aplikaci přes TGS_REQ. Řadič odpoví lístkem pro server. V této struktuře lístku je opět část určená serveru, zašifrovaná hashem právě daného aplikačního účtu (aby ji server na druhé straně přečetl). Útočník toto šifrování vyjme, nedoručí jej a rozlouská offline. Proč to funguje? Protože každý se validně může pokusit na službu přihlásit a KDC nevidí důvod mu to nedat. Úspěšnost závisí na slabých heslech obětí.
Otázka 34: Silver/golden ticket: what is it, when can we craft it?
Tyto techniky zneužívají znalost hesla pro falešné podepsání autoritativních struktur, abychom ošálili samotnou síť a získali naprostá oprávnění i pro fiktivní lidi bez asistence bezpečnostních prvků (řadič). Slouží k dominanci na daném uzlu.

Silver Ticket (Stříbrný lístek): Falešně podvržený Service Ticket (TGS) umožňující jakoukoliv administrátorskou roli čistě k jedné kompromitované službě/serveru na síti. Můžeme ho sestavit (craft it) jen, pokud zjistíme zranitelností (či Kerberoastingem) hash daného lokálního Service účtu té aplikace. Provedeme k ní AP_REQ s podepsaným TGS. Služba věří tomu, co podepíšeme.

Golden Ticket (Zlatý lístek): Falešně podvržený nadřazený Ticket Granting Ticket (TGT) lístek pro absolutně neomezený přístup všude do všech počítačů (generuje platné stříbrné lístky do všech míst). Můžeme jej vytvořit jedině a pouze v případě, kdy plně zkompromitujeme samotný doménový řadič (nebo celou doménu) a stáhneme z něj tajný hash speciálního účtu `krbtgt`. Pomocí klíče `krbtgt` si vytvoříme TGT tvrdící, že jsme např. členem skupiny Domain Admins, pošleme žádost TGS a ta bez zaváhání přilepí administrátorská práva k čemukoliv. Skvělá perzistence na dny i roky.
Otázka 35: Delegation: why is it needed, what types exist, how can it be exploited?
Proč je to potřeba: Problém "dvojitého skoku" (Double-hop issue). Klient komunikuje bezpečně s Web aplikací (A), aplikace se za něj musí zeptat (vystupovat pod jménem klienta s jeho oprávněními) na data vůči SQL databázi (B). Protokoly jako Kerberos neumožňují prosté znovupoužití stejného lístku a identity jinam.

Typy a jejich exploitace (zneužití):
  • Unconstrained delegation (Neomezená): Nejstarší forma. Služba "A" dostane propustný TGT lístek klienta a má volnou ruku vyžádat pro jakoukoliv službu "B", "C" nebo "Z" nový lístek z pozice uživatele klienta (uloží si u sebe lístek pro příště). Lze tvrdě zneužít, kdy my (útočník) se staneme správcem stroje "A" a trikem MS-RPRN (printerbug) přinutíme doménový řadič a kohokoliv vysokého z organizace, aby se autentizoval u stroje "A" a zanechal nám tam svůj TGT. Získáme tak klíče k administraci všeho.
  • Constrained delegation (Omezená): Účet služby "A" si může po odsouhlasení od řadiče říct pouze a jenom o služby jasně zakódované v parametru AD msDS-AllowedToDelegateTo (např. SQL/SERVER). Exploiting: Obcházení probíhá pomocí napadení "A", následné manipulaci S4U2self (získat si jakýkoliv servis lístek kompromitované identity) a Bronze bit attack pro obejití "Forwardable" omezení bitů TGS požadavku.
  • Resource-based constrained delegation (RBCD - Omezená kýmkoliv zespoda): Cílový server "B" řekne, který server "A" za něj smí mluvit. Může to na něm do atributů msDS-AllowedToActOnBehalfOfOtherIdentity přidat uživatel/stroj, co má právo server "B" v AD měnit a vytvářet. Může se tam nabourat a přidat účet, pro který to půjde podvrhnout.