Not a Security Boundary
6 likes4,203 views
1. The document discusses breaking trusts between Active Directory forests by leveraging compromised unconstrained delegation and the "printer bug" to coerce authentication across forest boundaries. 2. It explains how a compromised server with unconstrained delegation in one forest can be used to extract ticket granting tickets (TGTs) that can then be reused to access resources in a separate, trusting forest. 3. The "printer bug" allows remotely forcing authentication and is used to extract TGTs from the separate forest to circumvent typical cross-forest security restrictions. This bypasses the assumption that forests provide a security boundary when two-way trusts exist between them.
![CVE-2019-0683 Timeline
46
✘ March 12, 2019
○ Kerberos full delegation block is backported to Server 2008[R2]
✘ May 14, 2019
○ A new trust flag will be introduced in case you need full delegation
across trusts
○ "EnableTGTDelegation” set to “no” for all new trusts
✘ July 9, 2019
○ Start of enforcement of new trust flag
○ "EnableTGTDelegation” ignored from this point forward](https://image.slidesharecdn.com/notasecurityboundary-190321093533/85/Not-a-Security-Boundary-46-320.jpg)
![thanks!
Any questions?
[will | lee]@specterops.io
@harmj0y | @tifkin_
47](https://image.slidesharecdn.com/notasecurityboundary-190321093533/85/Not-a-Security-Boundary-47-320.jpg)
Not a Security Boundary
- 1. Not A Security “Boundary” Breaking Trusts
- 2. Red teamer and offensive engineer SpecterOps.io I write lots of code :) 2
- 3. Red teamer, hunter, researcher SpecterOps.io I love shiny things :) 3
- 4. 4 Microsoft’s “What Are Domains and Forests?” documentation
- 5. What If... Full ticket-granting-tickets could move across the trust from ForestA to ForestB 5 A computer in ForestA authenticates* to a computer ForestB We had a way to easily extract and reuse these TGTs while in ForestB? *bonus if we can force the authentication step :)
- 6. Kerberos in 60 seconds OK maybe a few minutes ;) 6 1.
- 7. Kerberos tl;dr ✘ Kerberos is dense, and we don’t have time to explain the entire protocol ○ Instead we’ll focus on a few key terms and points that are necessary to understand the nuances of the trust attack ✘ For a more in depth explanation, see Sean Metcalf’s post at https://bit.ly/2JhbAXl 7
- 8. Kerberos tl;dr 1. An account authenticates to a domain controller (DC/KDC) by encrypting some data with with a key derived from the user’s password (e.g. RC4_HMAC(NTLM hash) or AES128/256_HMAC keys) 2. If auth is successful, the DC returns a ticket granting ticket (TGT) to the user that contains a privileged attribute certificate (PAC) ○ The PAC is encrypted with the hash of the krbtgt (Kerberos ticket- granting-ticket service) account and contains auth information like the user’s SID and groups they’re in. 8
- 9. Kerberos tl;dr 3. The account requests a service ticket to a particular service principal name (SPN) by presenting the TGT to the domain controller 4. The DC returns a service ticket with the same auth info as the TGT. 5. The user sends the service ticket to the target service/machine, which decides whether to grant the user access. 9
- 10. 10
- 11. 2. Delegation When You Need to be Someone Else 11
- 12. The Reason Delegation is Needed 12 User Front End Back End Auth To Front End Service “Pretend” to be User
- 13. Unconstrained A user requests a forwardable TGT and sends it to the remote service with the service ticket. The remote service extracts the TGT from the service ticket and uses it to impersonate the user. Traditional Constrained The service requests a ticket to itself as another user (S4U2self) The service uses this ticket to request a service ticket to another service as that user (S4U2proxy). Service must be specified in msDS-AllowedToDelegateTo Resource-based Constrained ACL in a field (msDS- AllowedToActOnBehalfOfOthe rIdentity) on the target resource that dictates who can perform S4U2proxy to the resource 13 Delegation Types
- 14. Unconstrained Madness ✘ UNCONSTRAINED DELEGATION IS DANGEROUS! ✘ If an attacker can compromise a server with unconstrained delegation, they can obtain the TGT for any (non-protected) user who authenticates to that server ✘ In modern domains, only domain controllers are configured for unconstrained delegation by default ○ But we often see “misconfigurations” in the field :) 14
- 15. 15
- 17. Trusts 101 ✘ Trusts link up the authentication systems of two domains ○ This allows authentication traffic to flow between them ✘ This is done by each domain negotiating an “inter-realm trust key” that’s used to encrypt Kerberos referral tickets ✘ Access is passed around with via these referrals and “inter-realm ticket granting tickets" 17
- 18. Trusts 201 ✘ Trust directions/transitivity: ○ One-way - one domain trusts the other ○ Two-way - both domains trust each other (2x one-way trusts) ○ Transitive - A trusts B and B trusts C, so A trusts C ✘ The main trust type categories we care about: ○ Intra-forest - parent/child, cross-link (all transitive) ○ Inter-domain - forest (transitive), external (non-transitive) 18
- 19. Privilege Attribute Certificates (PAC) ✘ Recall: When you first authenticate, you receive a TGT ○ Inside each TGT is a PAC ○ A TGT’s PAC contains the user/group SIDs that identify the user 19 Ticket Granting Ticket Privilege Attribute Certificate (PAC) User S-1-5-21-2532535433-4733566781-1284343941-1001 Groups S-1-5-21-2532535433-4733566781-1284343941-1353 S-1-5-21-2532535433-4733566781-1284343941-2604 ExtraSids S-1-5-21-3416895347-7456555532-9337766299-519 CORPitadmin CORPFileShareAccess CORPHelpDesk ACMEEnterprise Admins
- 20. SID Filtering ✘ During auth to another domain, the remote domain (the “trusting domain”) analyzes the SIDs in the TGT’s PAC ✘ Depending on the trust type, the remote domain removes (“filters”) SIDs under various circumstances (see MS-PAC section 4.1.2.2) ✘ E.g. when authenticating from ForestA to ForestB, the PAC from ForestA should not contain SIDs for a default set of privileged groups in ForestB. ✘ Other cross-domain/forest group memberships can be exploited 20
- 21. Intent of SID filtering Stop a compromised trusted domain/forest from compromising a trusting domain/forest. How well does this work in practice? Let’s find out... 21
- 22. Why The Domain != A Security Boundary 22
- 23. Why The Domain != A Security Boundary ✘ The SID for “Enterprise Admins” is NOT filtered out by default for inter-realm tickets if both domains are within the same forest ○ So if you can set your sidHistory to be “Enterprise Admins” (i.e. ExtraSids in the PAC), you can escalate from a child domain to the forest root domain! 23
- 24. Forests == A Security Boundary? 🤔 ✘ SID filtering of sensitive groups DOES protect across Forest boundaries ○ Hence, people have assumed that Forests were a security boundary :) 24
- 25. Sidenote: “Authenticated Users” in Referrals 25
- 26. Sidenote: Delegation and Trusts 26
- 27. So what? Let’s review ✘ Delegated TGTs (like some TGTs found on unconstrained servers) are usable across Forests boundaries. ✘ A compromised unconstrained delegation server means an an attacker can extract TGTs of users who auth to that machine, even if that user connects from another forest! ✘ Hmm…...can we coerce accounts to authenticate to an unconstrained delegation server? 27
- 28. 28
- 29. 4. The “Printer Bug” Our Final Ingredient 29
- 30. Printer Bug Overview ✘ Abuses the old enabled-by-default Print System Remote Protocol (MS-RPRN). ✘ RPC Methods: RpcRemoteFindFirstPrinterChangeNotification(Ex) ○ Purpose: “<ComputerA>, please send <ComputerB> a notification when ____ happens” (e.g. when there’s a new print job) ○ When invoked, ComputerA will authenticate to ComputerB ✘ This a way to coerce authentication. There are others and likely more to come. 30
- 31. Reference: Printer Bug Details ✘ Print System Remote Protocol (MS-RPRN) ○ SMB-RPC (TCP 445) ○ Named Pipe: pipespoolss ○ RPC UUID: 12345678-1234-ABCD-EF00-0123456789AB ○ Opnum 62 - RpcRemoteFindFirstPrinterChangeNotification ○ Opnum 65 - RpcRemoteFindFirstPrinterChangeNotificationEx ✘ The RPC server is accessible by “Authenticated Users” on Windows >= 8 if the Spooler service is started (Server & Workstations have it enabled by default). ○ Supposedly this will change in the future…. ○ On Windows < 8 , seems possible if hosts have shared a printer. ○ Independently discovered by Elad Shamir (@elad_shamir) 31
- 32. Weaponization ✘ SpoolSample - https://github.com/leechristensen/SpoolSample 32 LABDC01$ authenticated to WIN10
- 33. 5. Breaking Forest Trusts Smash Smash Smash 33
- 34. Scenario ✘ An attacker completely compromises ForestB ○ This includes ForestB’s DC with unconstrained delegation ;) ✘ ForestB shares a two way forest trust with ForestA ✘ Tools Used: ○ Rubeus TGT monitoring/extraction ○ SpoolSample coerced authentication (the “printer bug”) ○ Mimikatz DCSync m/ 34
- 35. DCB DCA <- two-way forest trust -> Compromised Forest (FORESTB) Victim Forest (FORESTA) The “printer bug”
- 37. tl;dr 37 The compromise of any server with unconstrained delegation (domain controller or otherwise) can not only be leveraged to compromise the current domain and/or any domains in the current forest, but also any/all domains in any foreign forest the current forest shares a two-way forest trust with!
- 38. Public Reaction? (mostly good, but…) “Still a security boundary as long as it is not a two way trust AD forest/domain” 38 “Step 1: Have forest root domain admin credentials. Step 2: Have things be grossly misconfigured.” “I just don't think I've heard anyone claim a boundary still exists when a 2-way trust is in place.”
- 39. Why This Matters ✘ This attack works with default, modern configurations for Active Directory forests as long as a two-way forest trust is in place. ✘ The security of ForestA is now completely dependent on the security of ForestB (think acquisitions…) ○ Even if ForestA has *near perfect* security it can be completely compromised by the takeover of a single unconstrained delegation server in ForestB! 39
- 40. Microsoft: A Great Example ✘ We reported this to MSRC in the fall of last year ○ The associated Microsoft engineering teams determined that it wasn’t a vulnerability they would patch, but it would be something they might harden in the future (i.e. v.Next) ✘ After we published details (and defensive guidance) they decided this decision was a mistake, and soon released an advisory (and eventually a patch!) ✘ We applaud Microsoft/MSRC at admitting their error and handling the resulting situation in the best way possible! 40
- 41. 41
- 43. ✘ “Selective authentication is a security setting that can be set on interforest trusts. It provides Active Directory administrators who manage a trusting forest more control over which groups of users in a trusted forest can access shared resources in a trusting forest.” ✘ However, this is focused on administrative users ○ Domain controller objects often need the “Allowed to authenticate” right on foreign domain controllers in order for the system to work correctly Selective Authentication 43
- 44. Disabling Kerberos Full Delegation Across Trusts 44 ✘ To prevent ForestA from accepting delegated TGTs from ForestB: ○ netdom trust foresta.local /domain:forestb.local /EnableTGTDelegation:no ✘ This flips the TRUST_ATTRIBUTE_CROSS_ORGANIZATION_NO_TGT_DELEGATION bit to prevent delegated TGTs from transiting the forest boundary ✘ This has to be done on each end of the trust(s)!
- 45. CVE-2019-0683 Details 45 ✘ As mentioned, Microsoft recently recognized this issue as CVE- 2019-0683 ✘ A patch is being slowly rolled out (see next slide) that disables TGT delegation across forest trust boundaries by default ✘ On the roadmap (July 2019) ○ “...adding a new safe default configuration for unconstrained Kerberos delegation across Active Directory forest trusts.”
- 46. CVE-2019-0683 Timeline 46 ✘ March 12, 2019 ○ Kerberos full delegation block is backported to Server 2008[R2] ✘ May 14, 2019 ○ A new trust flag will be introduced in case you need full delegation across trusts ○ "EnableTGTDelegation” set to “no” for all new trusts ✘ July 9, 2019 ○ Start of enforcement of new trust flag ○ "EnableTGTDelegation” ignored from this point forward
- 47. thanks! Any questions? [will | lee]@specterops.io @harmj0y | @tifkin_ 47
- 48. References ✘ Breaking Forests Trusts (Red) - https://bit.ly/2Ck1HlW ✘ Breaking Forests Trusts (Blue) - https://bit.ly/2Y2Etd5 ✘ Attack Demo Video - https://bit.ly/2ULitRW ✘ Microsoft Advisory - https://bit.ly/2ObHAv2 ✘ Microsoft Updates Timeline - https://bit.ly/2ugBZdM ✘ CVE-2019-0683 details - https://bit.ly/2CopVLR 48