THREAT RESEARCH BLOG POST

Weakness Within: Kerberos Delegation

 

 

May 30, 2018 | | Oleg Alexandrov

During a Black Hat USA 2015 presentation, Sean Metcalf noted the security risks of Kerberos unconstrained delegation. Inspired by his talk and additional delegation articles including this one, CyberArk Labs conducted further research on the delegation mechanism.

In this article, we highlight the potential risks of misconfigured delegation services or users, offer possible mitigations and introduce a tool developed by CyberArk Labs to expose this risk quickly.

Overview

Delegation is used when a service requires access to another service on a different computer (i.e., backend server, database server) on behalf of another user. For example, let’s say a user requests data via a web server, but the data needed is stored in a database on a different server. It is possible, but not ideal from a security perspective, to grant the web server account direct access to the database. Access to data should be controlled because different users have different privileges. Properly managing access to information requires delegation.

Delegation is one of four impersonation types supported in Windows 2000 and later versions. Two types of the delegation levels can be used to allow a service to impersonate a user: Kerberos unconstrained delegation (Kerberos delegation) and Kerberos Constrained Delegation (KCD).

The KCD feature was released with Windows 2003, as Microsoft realized that unconstrained delegation exposes privileged credentials. The Kerberos unconstrained delegation functionality remains, probably due to backward compatibility.

Unconstrained Delegation

A server that is trusted for unconstrained delegation is actually allowed to impersonate (almost) any user to any service within the network. When a user requests a Service Ticket (ST) from a DC to a service, which is enabled for delegation, the DC will copy the client’s Ticket Granting Ticket (TGT) and attach it to the ST, which will later be presented to the service. When the user accesses the service with the ST, the user’s TGT will be extracted and saved in the server’s LSASS for later use. As a result, the service will be able to impersonate the user to any service within the network.

From the attacker’s point of view, servers with unconstrained delegation are prime targets. If a server trusted for unconstrained delegation is compromised, the attacker will have access to all of the TGTs of the users that used the service. Using the TGT ticket, an attacker can access all of the resources available in the network with the compromised user’s permissions.

How to Enable or Disable Delegation in our Domain:

Each Kerberos account can be configured by these steps:

  1. Open the Users and Computers (dsa.msc)
  2. Open server properties
  3. Go to delegation tab
  4. Select “Trust this computer for delegation to any service (Kerberos only)” to enable. Select “Do not trust this computer for delegation” to disable.

Figure 2 – Configure unconstrained delegation

Attacker’s Point of View
Discovering computers with unconstrained delegation is a straightforward task using ActiveDirectory PowerShell module, and it could be done by every domain user. A machine trusted for unconstrained delegation will have “TrustedForDelegation = True,” so an attacker could rely on it to search for all computers in the domain trusted for unconstrained delegation.

Figure 3 – Find computers allowed for unconstrained delegation

After spotting the machines trusted for delegation, the attacker could aim to compromise the servers/computers. When the server is compromised, the attacker will gain access to all of the TGT’s stored on that server, and consequentially, he might be able to compromise the domain.

Mitigation

  1. Avoid using unconstrained delegation. Instead, configure delegation with constrained delegation, as servers trusted for constrained delegation store only STs and not TGTs. The impersonation will be allowed only for a specific set of services.
  2. Configure all of the sensitive accounts (e.g., domain admins) to have “Account is sensitive and cannot be delegated” option enabled. Domain admins are the most privileged accounts in the domain, so they are also the most lucrative for an attacker. The fewer computers with domain admins TGT’s, the smaller the privileged attack surface.
  3. Use the “Protected Users” security group. Membership in the Protected Users group is meant to be restrictive and secure by default. If the domain level is Windows Server 2012 R2 or above, users in this group cannot be delegated by using constrained or unconstrained delegation.
  4. Keep delegation servers secured. Set firewall rules according to server purpose and delegation configuration. Keep servers patched and limit privileged access.

Constrained Delegation

Microsoft realized that unconstrained delegation is a potential risk for a domain-based network. Therefore, it developed and released the constrained delegation feature with Windows 2003 and included the Kerberos protocol extension called S4U. The extension consists of two parts, and each one has a different purpose. To clarify, we’ll explain each extension in detail.

Constrained delegation is used in conjunction with S4U2Proxy extension, which provides a service that obtains ST to another service on behalf of a user. The ST will be obtained only if the demanded Service Principal Name (SPN) is in the msDS-AllowedToDelegateTo (A2D2) field of the requesting service. The S4U2Self extension is needed in case Kerberos authentication is not supported. A user can authenticate a service with a non-Kerberos protocol (e.g., NTLM), but the delegation to the second service will be accomplished using Kerberos. This action is called protocol transition. The extension allows a service to obtain a ST on behalf of a Kerberos security principal, and delegated user credentials are not required for this process. The configuration field for this extension called TrustedToAuthForDelegation(T2A4D).

The purpose of constrained delegation is to limit access of a delegation machine/account to specific services while impersonating users, unlike unconstrained delegation that allows delegation to all services.

From the attacker point of view, a server with protocol transition disabled will have delegated users ST tickets, which the attacker can use for the specific services specified in the ST. Servers with protocol transition enabled will allow the attacker to impersonate any user without access to a user’s password.

How to Enable or Disable Constrained Delegation:

  1. Open the Users and Computers (dsa.msc)
  2. Open server properties
  3. Go to delegation tab
  4. Select “Trust this computer for delegation to specified services only” to enable. Select “Do not trust this computer for delegation” to disable.
  5. Select “Kerberos only” if you do not want to allow protocol transition, otherwise select “Use any authentication protocol”
  6. Add only the services to which the delegation is allowed

Attacker’s Point of View
Discovering the users or computers trusted for constrained delegation with PowerShell ActiveDirectory module is still a straightforward task, as it was demonstrated in the section of unconstrained delegation. The only difference is the filter option. Now the attacker will search for services of interest, due to the limitation of the constrained delegation. For example, this could be DC services e.g. cifs, LDAP, to gather domain info, or MSSQL service to extract data from DB. The field that specifies if constrained delegation is enabled is “msDS-AllowedToDelegateTo”. This field also contains a list of services to which the delegation is allowed. Another filter option the attacker has is the servers with protocol transition enabled, which can be found by the field“TrustedToAuthForDelegation (T2A4D) = True”

Figure 4 – Computers with constrained delegation without protocol transition

Figure 5 – Users allowed to delegate with protocol transition

After spotting the servers/users trusted for delegation, the attacker will aim to compromise them. When a server is compromised, the attacker will gain access to all ST stored on that server or will have the ability to use the S4U2Self extension.

Mitigation

  1. Configure all the sensitive accounts e.g. domain admins to be “Account is sensitive and cannot be delegated”
  2. Use the “Protected Users” security group. Membership in the Protected Users group is meant to be restrictive and secure by default. If the domain level is Windows Server 2012 R2 or above, users in this group cannot be delegated by using constrained or unconstrained delegation.
  3. Avoid using protocol transition
  4. Keep delegation servers secured. Set firewall rules according to server purpose and delegation configuration. Keep servers patched and limit privileged access.
  5. Use strong passwords for service accounts trusted for delegation.

Summary

The delegation feature is a complex task and has significant security implications. Attackers are well aware that delegation can be abused, so it is essential to mitigate the risk by configuring this feature correctly. Otherwise, your domain is exposed to risk.

It’s advisable to avoid unconstrained delegation in your organization. If you have historically used servers configured to unconstrained delegation, you should change it as soon as possible. Instead, use the constrained delegation, while avoiding using the protocol transition option and limiting the service delegation trust.

Free Tool

CyberArk Labs developed a free, open source tool called Mystique. This tool will show all the delegation types, trusts and risks in the domain. It can also be used to test delegation for misconfiguration.

References

 

 

Share This