The Double Hop Problem
Enterprise environments worldwide rely heavily on Microsoft’s Active Directory (AD). In simple terms, Active Directory provides central server(s) that contain a database of all user and computer objects within a domain. This enables centralized management and provisioning of users. For example, it allows you to log in using your domain credentials on a flex working computer that you’ve never used before.
The latest versions of Active Directory utilize the Kerberos protocol (MIT, 1989), of which Microsoft implemented its own version. Battle-tested and extensively analyzed, the original Kerberos protocol provides secure mechanisms for authenticating to other services in a network after a user has been initially authenticated within the domain.
The Kerberos protocol is actually quite simple (for the dedicated reader, you find more information about the protocol at [1], which is out of scope for this article).
The first two steps are performed whenever a user logs into their computer using username and password:
- A Ticket-Granting Ticket (TGT) is requested from the Kerberos Domain Controller (KDC). A new TGT is also requested if the previous one expires (usually every 10 hours, but with a maximum of 10 years in Microsoft’s implementation).
- A TGT is returned by the KDC after several security checks.
Later, the user might want to use an internal web application, for instance, to register their hours. To provide a seamless user experience, authentication to the internal web application is also performed using Kerberos: - The user contacts the KDC again to request a Ticket-Granting Service (TGS) ticket for the web application, supplying his TGT in the process.
- A TGS is returned by the KDC after performing several checks.
- The user then uses his TGS to authenticate to the web application (referred to as the ‘Resource Server’ in the image).
- The Resource Server either accepts or denies the request based on the user’s permissions, and further communication between the user and the web application proceeds.
It is also noteworthy that a server in Microsoft’s Kerberos implementation exposes several services to users, including:
- CIFS (Common Internet File System) service provides users access to the file system of a Windows server.
- HOST service grants users access to Scheduled Tasks on Windows servers.
- MSSQL service gives access to database service.
While the original Kerberos protocol provides secure authentication mechanisms, attack paths within a Kerberos-enabled are still possible. For instance, in Microsoft Active Directory environments attackers can steal TGTs and TGSs from other users, either from memory (in Windows) or from files (in Linux, which can also be joined to the Microsoft Active Directory). These stolen tickets can then be abused by a malicious actor to authenticate to different services in the network, impersonating other users.
Double Hop
The Double-Hop problem arises from the practical need for users to have their authentication seamlessly usable across multiple connections. A common example is a user authenticating to a web application that, in turn, needs to authenticate to a database on another machine, using previously provided credentials, to access only services that that user is authorized to access. For example, a user should only be able to request their own previous timesheets, not those of other users.
Unconstrained Delegation (UD)
Microsoft initially proposed UD in 2000 as a solution to the Double-Hop problem. When a service is enabled for UD, the frontend service (application tier) can act on behalf of a user to the backend service (data tier). To achieve this, the user requests an additional “Forwardable” TGT from the KDC, which it then sends to the frontend service along with its other authentication requests. The frontend service, in turn, uses this Forwardable TGT to request a TGS for authentication to the data tier.
However, this implementation has significant drawbacks because UD places no restrictions on the Forwardable TGT. Consequently, instead of being limited to authenticating to the data tier, the application tier can authenticate to any service in the domain. Attackers can exploit this by compromising a system with UD enabled and then waiting for (or tricking) highly privileged users into connecting to it. This allows attackers to use the Forwardable TGT to move laterally from the frontend service to critical servers in the domain, depending on the permissions of the user that connected to the frontend service.
Constrained Delegation (CD)
CD, introduced in 2003, was designed to address the vulnerabilities of UD. It limits the scope of the delegation by explicitly specifying in the domain which specific services the frontend service is allowed to delegate to (e.g., the MSSQL service on the data tier server). Since this functionality is not natively supported by the original Kerberos protocol, Microsoft implemented two extensions: S4U2Self and S4U2Proxy.
The frontend service first uses S4U2Self to request a TGS as any user to itself from the KDC. Then, still impersonating the user, it uses this TGS along with S4U2Proxy to request a TGS specifically for the backend service. While this represents a significant improvement over UD, certain attack paths from the frontend service to the backend service remain viable. This is primarily due to two factors:
A compromised frontend service can request the two TGSs as any user in the domain, including highly privileged accounts like Domain Administrators (DA).
The Service Principal Name (SPN) of the target service is not encrypted within the requested TGT. This potentially allows attackers to specify any service on the target machine.
For instance, if the frontend service is compromised, it can request a TGS as the DA and authenticate to the CIFS service instead of MSSQL on the data tier. This would grant the attacker or malicious user the ability to read and modify any file on the Windows server hosting the data tier.
Resource-based Constrained Delegation (RBCD)
Typically, only highly privileged users such as Domain Administrators can enable (Un)constrained Delegation. To delegate these privileges more granularly, Microsoft introduced RBCD in 2012. In this mode, instead of registering the backend service on the frontend service object, the frontend service is specified on the backend service object within the domain. The frontend still utilizes S4U2Self and S4U2Proxy to authenticate as a user to the backend service. However, a similar attack path to CD works for RBCD as well.
Conclusion
Although delegation attacks require significant initial compromise to be exploitable, they represent a potential threat that system administrators must be aware of. These attacks can create attack paths within an Active Directory environment that are not immediately obvious. Over the years, Microsoft has proposed various solutions to the Double-Hop problem, each addressing the issue to varying degrees while simultaneously introducing new risks and attack paths.
Active Directory has been under continuous development for a quarter of a century. While many security considerations adopted by Microsoft in the past are now outdated and no longer considered secure on a theoretical level (e.g., MD4, RC4), it’s understandable that Microsoft cannot simply issue a comprehensive software upgrade to every Active Directory environment worldwide due to backwards compatibility concerns. It is not in Microsoft’s business interests to potentially disrupt the environments of entire corporations. The viable path to secure Active Directory environments is for Microsoft’s clients to invest adequately in prevention and security monitoring.