Shulou(Shulou.com)05/31 Report--

How to carry out in-depth analysis of CVE-2020-17049 Kerberos Bronze Bit attacks, I believe that many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

On November 10, 2020, Microsoft released a patch to fix the Kerberos KDC security function bypass vulnerability (CVE-2020-17049 Kerberos Bronze Bit Attack), with a severity level. In December 2020, foreign security vendors publicly released verification scripts and detailed technical analysis of the vulnerability and named it Kerberos Bronze Bit Attack (Bronze bit attack). At the same time, the exploitation tools of the vulnerability were also disclosed on github, which greatly increased the risk of the vulnerability being widely exploited.

1. Vulnerability background

The Kerberos protocol is named after the three fierce dogs who guard hell in ancient Greek mythology, so there are three participants in Kerberos authentication, namely, the Client that accesses the service, the Service that provides the service, and the KDC (Key Distribution Center) key distribution center. There are two services in KDC, namely authentication service Authentication Service (referred to as AS) and ticket granting service Ticket-Granting Service (referred to as TGS). In the domain environment of windows, KDC is generally in Domain Controller (referred to as DC). Kerberos is based on symmetric encryption authentication, and each principal in Kerberos has a key that is known only to the principal and the KDC.

1.1 introduction of Kerberos protocol

When Client accesses a service on Server, it first proves its identity to AS, and then initiates an authentication request to Server through the TGT issued by AS. The process is divided into three parts:

Interaction between The Authentication Service Exchange:Client and AS

Interaction between The Ticket-Granting Service (TGS) Exchange:Client and TGS

Interaction between The Client/Server Authentication Exchange:Client and Server.

1.1.1 The Authentication Service Exchange

As shown in the figure above, Client encrypts the current timestamp with the user key, places it in the AS_REQ message along with the user name, and then sends the AS_REQ message to KDC. KDC retrieves the user key through the user name and uses the user key to try to decrypt the timestamp. If the decryption is successful, it proves that the user key is correct. After successful verification, the session key is generated, and then the session key is placed in the KRB_AS_REP message and returned to Client. The schematic structure of AS_REP is shown below:

The AS_REP message includes the user name, enc_part, and TGT. Enc_part is encrypted using a user key. It includes fields such as service name and flag, as well as a session key generated by KDC. Client can decrypt the session key with a user key. TGT (Ticket-Granting Ticket, ticket granting ticket, or golden ticket) is encrypted using the KDC key. It includes fields such as the flag, the user name of the requesting service, and the session key generated by KDC. The returned TGT indicates that the user has been successfully authenticated by KDC.

1.1.2 The Ticket-Granting Service (TGS) Exchange

As shown in the figure above, Client encrypts the current timestamp using the session key, places it in the TGS_REQ message along with the requested service name and TGT, and then sends the TGS_REQ message to KDC. KDC needs to verify the TGT after receiving the KRB_TGS_REQ, so KDC decrypts the TGT through its own key encryption, obtains the session key decryption timestamp from the decrypted TGT for verification, and returns a TGS_REP message if the verification is successful. The schematic structure of TGS_REP is shown below:

The TGS_REP message includes the user name, enc_part, and ST. Enc_part is encrypted using a session key, which includes fields such as the requested service name and flag, as well as the service session key generated by KDC. Client can use the session key to decrypt the service session key. ST (Service Ticket, service ticket, or silver ticket) is encrypted using the service key and includes fields such as the flag, the user name of the requesting service, and the service session key generated by KDC. You can see that the structure of ST is similar to that of TGT, because TGT can be seen as a special service ticket, which is the service ticket of TGS (Ticket-Granting Service). Here is a detailed description of the structure of ST:

Service session key: the service session key generated by KDC can be decrypted by Client and Service.

Flag: the flag bits of Kerberos tickets include forwardable, updatable, normalized, updatable OK, etc., of which ForWardable will be discussed in detail later.

PAC: Privilege Attribute Certificate (privilege attribute certificate), PAC is to distinguish between different permissions of users. The PAC here uses the KDC key and the service key for encryption to prevent tampering.

1.1.3 The Client/Server Authentication Exchange

After Client receives the KRB_TGS_REP, it uses the session key to decrypt the service session key, and the Client can interact with the service directly without using KDC as the middleman.

You can see that after verifying the timestamp, Service also uses the service key decryption PAC to verify whether the user requesting the service is authorized to access the service. At the same time, Service can also choose to send the PAC to KDC for verification. KDC uses its key to decrypt and verify whether the PAC is correct. If it is correct, it means that the PAC has not been tampered with. If all of the above authentications are successful, Service gives Client access to the resources it requests, otherwise it denies access.

1.2 Kerberos delegation

Delegation simply means that A uses Kerberos authentication to access service B in the domain, while B uses A's identity to request service C in the domain. For example, when client accesses the HTTP service on Server1, and the HTTP service needs to request the database of server2, but Server1 does not know whether client has the database access permission of server2, then the HTTP service will use the identity of client to access the database of server2. If client has database access permission of server2, the access will be successful.

Delegation in Kerberos can be divided into unconstrained delegation (Unconstraineddelegation) and constraint delegation (Constrained delegation), which are described below.

1.2.1 unconstrained delegation

The user sends ST and TGT to access the Service1, and then the service can use the user's TGT to request the ST of other services from TGS, and then simulate the user to operate.

You can see that because the unconstrained delegate needs to send the user's TGT to the Service1, then the Service can use the TGT to mimic whether the user gets any other ST, which is extremely insecure.

1.2.2 constraint delegation

Due to the insecurity of unconstrained delegation, Microsoft has released the function of constraint delegation in windows2003. In constraint delegation, client does not send TGT directly to the service, but restricts the authentication information sent to service1. Service1 is not allowed to use this TGT to access other services on behalf of User. This process uses a set of Kerberos protocol extensions called S4U2Self (Service forUser to Self) and S4U2Proxy (Service forUser to Proxy).

S4U2Proxy: the user requests to access the service1 through the domain controller, and the domain controller verifies and returns the service1 service ticket ST1. The user sends this ST1 to the service1 to authenticate with the service1 and establish a connection. If the service1 is allowed to be delegated to the service2, the service1 can use the S4U2Proxy protocol to forward the ST1 that the user sends to himself (the ST1 must be forwarded) to the domain controller authentication server to request access to the ST1 of the service2, after which the service1 can use the newly acquired ST2 to simulate the user to access the service2. As shown in the following figure:

S4U2Self (Protocol conversion): in the figure above, Client authenticates with Service1 through Kerberos protocol, but when users authenticate with Service1 in other ways (such as NTLM authentication, form-based authentication, etc.), users cannot provide Service1 with the service ticket ST that requests the service, so the server cannot further use S4U2Proxy protocol to request access to Service2. S4U2Self protocol is the solution to this problem. The service configured with TrustedToAuthForDelegation requests the authentication server to access its own forwardable service ticket for the user. The schematic diagram of S4U2Self is shown below:

Through S4U2Self Service1, you can obtain a service ticket ST1 that requests its own service, and the Cname field of the ST1 is identified as Client, after which you can use this service ticket through S4U2Proxy to request a ticket to access the Service2 from the domain controller.

1.3 delegation based on resource constraints

Resource-based constraint delegation (RBCD) is a new feature in Windows Server 2012. Compared with traditional constraint delegation, it no longer requires domain administrator privileges to set relevant properties. RBCD gives permission to set delegation to the machine itself, which modifies the msDS-AllowedToActOnBehalfOfOtherIdentity property to determine who can be delegated to control me.

2. Vulnerability analysis and poc recurrence 2.1loophole analysis

In the previous content, we have introduced the authentication process of the Kerberos protocol and the relevant knowledge of Kerberos delegation. Before introducing the CVE-2020-17049 vulnerability, let's briefly introduce how attackers use constraint delegation to attack.

Assume that the attacker has obtained the password hash value of Service1 and that there is a delegate trust relationship between Service1 and Service2 (Service1 is configured to constrain delegation to Service2 or Service2 accepts resource constraint-based delegation from Service1). If Service1 allows protocol conversion (with the TrustedToAuthForDelegation attribute configured), you can use the GetST.py script in the impacket suite to obtain the service ticket ST2 of the Service2 with the specified identity. The specific attack flow is shown in the following figure:

With the service ticket ST2, an attacker can impersonate a target user to interact with Service2.

Because of the harmfulness of delegated attacks, Microsoft officially provides a variety of configurations to reduce the harm of delegated attacks. You can start by disabling protocol translation (that is, turning off the TrustedToAuthForDelegation property), as shown in the following figure.

Second, you can configure domain accounts in AD as "sensitive accounts and cannot be delegated".

Finally, you can add intra-domain accounts to the "Protected Users" security group, whose members cannot be authenticated by delegation.

If at least one of the above configurations is set for an account in a domain, the "ForWardable" of the service ticket will always be set to 0 when applying for a service ticket for the account in that domain. That is, Service1 can still obtain the service ticket ST1 of the account in this domain through the S4U2self protocol, but because the ForWardable flag bit of the service ticket ST1 is 0, then the service ticket ST1 cannot be used in the S4U2 proxy to obtain other service ticket, as shown in the following figure.

The structure diagram of TGS_REP with "ForWardable" set to 0 is shown in the following figure.

If you take a closer look at the image above, you can see that ST1 is encrypted using the Service1 key. This means that Service1 can decrypt ST1 and modify the forwardable value, and then re-use the Service1 key to encrypt and send it to KDC. The forwardable flag is not in PAC, so KDC cannot detect whether the value has been tampered with. The specific attack is shown as follows:

After bypassing the restrictions, the attacker can impersonate the target user to interact with Service2.

2.2POC recurrence

The environment used in this section is a domain-controlled environment of Windows Server 2012 and two normal in-domain PC machines of Windows 10.

2.2.1 example of constraint delegation attack

First of all, we need to configure the test environment on the domain control, and we configure Service1 (intra-domain Windows102004 machine) to delegate constraints to Service2 (intra-domain Windows10 machine) (disable protocol conversion through the "use Kerberos only" option).

Also set the domain administrator account in the domain to "sensitive account and cannot be delegated" and add it to the "Protected Users" security group.

Obtain the password hash of the Service1 (Windows102004 machine in the domain) by means of mimikatz or secretsdump.py in impacket.

Try to use getST.py directly to get the service ticket ST2 for Administrator access to Service2 (the Windows10 machine in the domain).

You can see that because Administrator is protected, the service ticket ST1 obtained using S4U2self is not forwardable and cannot be used in S4U2 proxy, resulting in an error.

Next we use the newly modified getST.py and add the-force-forwardable parameter to modify the service ticket ST1.

You can see that through the-force-forwardable parameter, we modify the previously non-forwardable service ticket ST1 to be forwardable, and then use the service ticket ST1 to apply for access to the Service2 service ticket ST2. You can then access Service2 as Administrator by importing the service ticket ST2 into memory.

2.2.2 example of delegation attack based on resource constraints

In the example of an attack with constraint delegation, we need to control the service account Service1 in a domain and the service account is configured with a constraint delegation to the target service account Service2. In the actual infiltration process, it is difficult to obtain the above conditions. More often, a webshell is uploaded on a site, and the permissions obtained by connecting to the webshell are generally relatively small. Let me show you how to exploit resource-constrained delegation and CVE-2020-17049 vulnerabilities to elevate power on the target machine in this case.

First, suppose we have connected to the webshell of a target machine in the domain, and the permission obtained by connecting to the webshell is iis apppool\ defaultapppool, which is not in the local administrator and only has read and write permissions in the directory where the current webshell resides.

Upload our malicious program exp.exe through Webshell and execute the malicious program. The function of the malicious program in the domain is to generate a machine account evil1 that does not exist, and modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the target machine Win10 to the SID of evil1, that is, configure Win10 to accept delegates based on resource constraints from evil1. The msDS-AllowedToActOnBehalfOfOtherIdentity of Win10 can be modified through iis apppool\ defaultapppool because in the Windows system, the network identity of iis apppool\ defaultapppool is a machine account, and the machine account has the permission to modify its own msDS-AllowedToActOnBehalfOfOtherIdentity attributes.

An attempt was made to run the getST.py prompt service ticket ST1 directly with the machine account password, but failed to run S4U2 proxy.

Get the password hash value of evil1 through mimikatz.

Reuse getST.py and add the-force-forwardable parameter to modify the service ticket ST1.

Then use the modified service ticket ST1 to apply for access to the Service2 service ticket ST2. You can then access Service2 as Administrator by importing the service ticket ST2 into memory.

Phellodendron mandshurica (Thunb.)

After reading the above, have you mastered how to conduct an in-depth analysis of CVE-2020-17049 Kerberos Bronze Bit attacks? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.