10.3 Delegace (Delegation)

Delegace v Kerberosu řeší tzv. Kerberos double-hop issue (problém dvojitého skoku). Nastává ve chvíli, kdy se klient autentizuje vůči systému A (např. webovému serveru), a tento systém A se následně potřebuje autentizovat jménem klienta vůči systému B (např. databázovému serveru), aby mu mohl poskytnout požadovaná data.

Práva pro delegaci mohou být přidělena jak uživatelským, tak počítačovým účtům. Rozeznáváme tři základní typy delegace:

1. Unconstrained delegation (Neomezená delegace)

Dostupná již od Windows Server 2000. Účty s povolenou neomezenou delegací mají nastavený příznak TRUSTED_FOR_DELEGATION.

Princip a rizika Unconstrained delegace
Při komunikaci se systémem A (který má neomezenou delegaci) vloží klient do požadavku svůj vlastní přeposlaný (forwarded) TGT. Systém A si tento TGT uloží do mezipaměti (cache) a může jej použít k vyžádání servisních lístků pro jakoukoliv jinou službu v celé doméně (tedy včetně systému B).

Bezpečnostní problém: Pokud útočník zkompromituje systém A s neomezenou delegací, získá přístup k TGT všech klientů, kteří se na něj připojí. Útočník navíc může použít útok zvaný Print spooler attack (tzv. coercing) a donutit např. samotný doménový řadič k autentizaci vůči kompromitovanému systému A (s využitím služby Print Spooler přes MS-RPRN RPC), čímž získá jeho vysoce privilegovaný TGT. K tomu se používají nástroje jako SpoolSample nebo printerbug.py.

2. Constrained delegation (Omezená delegace)

Představena ve Windows Server 2003 z důvodu značných rizik neomezené delegace.

Princip a rizika Constrained delegace
Tato forma je omezena pouze na konkrétní systémy. Využívá atributu msDS-AllowedToDelegateTo, který definuje seznam služeb, ke kterým se může daný systém (A) delegovat jménem klienta. Zde je nutné využít dvou Kerberos rozšíření od Microsoftu:
  • S4U2self (Service for User to Self): Systém A si jménem klienta vyžádá tzv. forwardable service ticket (propustný servisní lístek) pouze pro sebe, bez nutnosti asistence klienta. Tím překlene proces úvodní autentizace (užitečné např. u webových autentizací formátem, než je Kerberos).
  • S4U2proxy (Service for User to Proxy): Systém A vezme tento forwardable service ticket klienta a poskytne jej společně se svým vlastním TGT doménovému řadiči. Následně dostane servisní lístek pro systém B.
Pokud je nastaven flag TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION, může být použita tzv. Protocol Transition (můžeme použít pro přihlášení k systému A jakýkoliv protokol, a on přesto může zařídit delegovaný lístek k B - u klasické je nutno použít Kerberos).

Problém: Systém A může impersonovat jakéhokoliv uživatele (kterýkoliv účet) vůči systému B definovanému v povoleném seznamu, a navíc jméno služby v získaném servisním lístku pro B není šifrováno a může být dodatečně modifikováno. Známý útok se jmenuje Kerberos Bronze Bit Attack (CVE-2020-17049, dnes opraveno), kdy útočník manipuloval lístky účtů, u kterých by to standardně vůbec nemělo být možné, aby je prohnal delegací (modifikací bitů v lístku).

3. Resource-based constrained delegation (RBCD)

Zavedeno ve Windows Server 2012. Hlavní myšlenka je otočení směru delegace. Místo aby systém A říkal, ke komu může přistupovat (systém B), systém B určuje, kdo k němu smí delegovat identitu (tedy který systém A).

Princip a zneužití RBCD
RBCD se konfiguruje přímo v cílovém objektu (systému B) na atributu msDS-AllowedToActOnBehalfOfOtherIdentity. Problémem a slabinou zde je, že k úpravě tohoto atributu pro určitý účet B stačí mít oprávnění modifikovat jeho objekt (což často mají uživatelé nebo počítačové účty, kteří jej vytvořili).

Útok probíhá tak, že jakmile útočník dokáže modifikovat msDS-AllowedToActOnBehalfOfOtherIdentity systému, typicky vytvoří nový falešný účet počítače v AD (dle politiky MachineAccountQuota smí běžný uživatel vytvořit až 10 nových počítačových účtů). Poté nastaví atribut tak, aby systém věřil jím vytvořenému počítačovému účtu. Z pozice vytvořeného stroje následně pomocí RBCD požádá o lístek na kompromitovaný systém pro administrátora.