Shulou(Shulou.com)06/02 Report--

What is the principle and utilization of MS14068 and gold and silver bills in Kerberos? in order to solve this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

I. Preface

The following details about the principle and utilization of MS14068 and gold and silver bills, a classic loophole that has been exposed by Kerberos. MS14068 is a classic loophole. The editor makes an explanation on gold and silver bills and enhanced gold bills.

II. MS14068

MS14068 is a privilege escalation vulnerability that enables ordinary users to elevate their rights to domain control privileges. Attackers can elevate privileges by constructing specific request packets. First of all, let's talk about how to use it.

1. Mode of utilization

Experimental environment:

Domain: YUNYING.LAB

Domain control: WindowsServer 2008 R2 x64 (DC)

Intra-domain host: Windows7 x64 (S1): domain account ts1

Required tools:

Pykek

Mimikatz

Attack flow:

Before the experiment, you need to check whether the KB3011780 patch is installed on the domain control host, which can be checked through systeminfo.

First, access the shared folder controlled by the domain through dir on the host S1 in the domain, which denies access.

Second, through the Pykek tool to exploit the vulnerability, I use here is the python script after the compilation of the exe file.

Parameter description:

-u domain account + @ + domain name, this is ts1+@+yunying.lab

-p is the password of the current user, that is, the password of ts1

-s is the Sid value of ts1. You can obtain the Sid value of users through whoami/all.

-d is the domain control of the current domain

Successful execution of the script generates a ccache file in the current directory.

Third, use mimikatz to import the generated ccache file. Before import, use the command klist purge under cmd or use kerberos::purge in mimikatz to delete the current cached kerberos ticket.

Once again, dir access to the domain control share has been successfully accessed.

2. Loophole principle

In the process of using the MS14068 tool, we can see that S1 and the domain controller 192.168.254.130 (essentially with the KDC installed on the domain controller) have four interactions with KRB_AS_REQ, KRB_AS_REP, KRB_TGS_REQ and KRB_TGS_REP.

Here is how the vulnerability is exploited according to the process and tool source code:

KRB_AS_REQ

First, the program builds AS_REQ through the build_as_req function, where you can see that the parameter pac_request is set to false.

In other words, after setting this parameter, you will apply to KDC for a TGT ticket that does not contain PAC, which is Microsoft's default design, as detailed in the link below.

Https://docs.microsoft.com/en-us/previous-versions/aa302203(v=msdn.10)#security-considerations

Through the PCAP package, you can see the include-pac:False field in the AS-REQ request more visually. This is the first factor causing this loophole.

KRB_AS_REP

After AS initiates the request, KDC (AS) returns a TGT ticket that does not contain PAC to Client. In this case is tgt_a.

Grab the bag and see the TGT ticket that starts with 268fdb.

KRB_TGS_REQ

The attack script uses two key functions to implement this process, first constructing PAC through build, and then constructing the contents of TGS-REQ through the build_tgs_req function.

Build_pac

When Client receives the TGT returned by AS without PAC, it starts to construct PAC through the build_pac function in the script.

Here we focus on chksum1 and chksum2 in PAC, that is, the two digital signatures of PAC, PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM, mentioned in the introduction of PAC.

Note that the value of the first parameter server_key [0] and kdc_key [0] is actually the program-specified RSA_MD5, while the value of Key is None, but in principle this encryption should be determined by KDC. In other words, the Key that encrypts the digital signatures of PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM should be the Server password HASH and the KDC password HASH, respectively. Here, the Key is directly None, and then it is encrypted directly using the RSA_MD5 method.

This is the second factor in the vulnerability, which can be verified by looking at the checksum function.

At the same time, we also need to pay attention to the parameter user_sid, which is split by the build_pac function and then reconstructs the value of the highly privileged sid. In this case, the value of user_sid is Smur1-5-21-4249968736-1423802980-663233003-1104. after segmentation, the domain_sid is Smuri 1-5-21-4249968736-1423802980-663233003.

Among them, 512,520,518,519 are the sid numbers of different groups. 513 was DOMAIN USERS group. In this way, a PAC containing the high-privilege group SID is constructed.

Build_tgs_req

Among the parameters of the build_tgs_req function, authorization_data corresponds to the pac generated by build_pac.

Here, PAC is passed into build_tgs_req and encrypted using subkey.

From the following figure, you can see that subkey is actually a string of 16-bit random numbers generated by the function generate_subkey.

The problems that have arisen so far are:

A. By default, the value of Include-pac is allowed to be False in the domain (not a vulnerability, but a mechanism designed by Microsoft for some specific scenarios)

The digital signature in B and PAC can be specified by the Client side, and the value of Key can be empty

The encryption method of C and PAC can also be specified by Client, and the value of Key is the 16-bit random number generated by the generate _ subkey function.

D. The constructed PAC contains the SID content of the high permission group.

That is to say, through these points, Client completely forges a PAC and sends it to KDC, and KDC decrypts the forged PAC and verifies the digital signature through the encryption algorithm specified by the Client side in the request, and verifies it.

By grabbing the packet, you can see the TGT (beginning of 268fdb) that will be received in this process and the PAC content encrypted with ARCFOUR-HMAC-MD5.

KRB_TGS_REP

After KDC successfully verifies the forged PAC, it returns a new TGT to the client, and the TGT will include the PAC generated by Pykek. Normally, what is returned here is a ST ticket sent to the client for authentication.

When the Pykek tool receives the new TGT, it saves it to generate an ccache file. That is to say, Client has already obtained a normal TGT ticket (beginning with 564eab) that contains high-privilege PAC content.

Using Mimikatz to access DC shared folders using TGT

At this point, we import the ticket through mimikatz and use dir\\ dc.yunying.lab\ c$ to access the domain-controlled shared folder.

You can see that the client initiates two TGS-REQ requests at this time. Focus on the first time, the ticket used in this case is the TGT imported using mimikatz, that is, the tgt_b returned in the above KRB_TGS_REP process (beginning with 564eab).

After the request, a CIFS ticket for dc.yunying.lab (domain control) is returned, that is, the ST (Service Ticket) ticket in the normal process (beginning with 234062):

At this time, it is found that there is no AP_REQ process in the captured package, because in Kerberos, the AP_REQ process is placed in the first request of the service, here in the Session Setup Request of SMB (other protocols are the same, for example, the HTTP protocol is placed in the GET request).

Then respond in the Session Setup Response of SMB, that is, the AP-REP process.

At this point, Client is able to access domain-controlled shared folders without authorization.

3. Defense and detection

This vulnerability is a 14-year-old vulnerability, most of which occur in domain environments of windowsserver 2008 and windowsserver 2003, so security patches are already available for download and installation, and users can avoid risks by installing KB3011780 patches on domain controls.

At the same time, we can make a preliminary screening according to the above-mentioned feature that include-pac is marked as False.

It can also be found through windows logs, such as logging in to the target server with an ID of 4624, ID of 5140 indicating that the network shared object is accessed, and so on.

The main problem in this vulnerability is that KDC will verify the validity of PAC according to the encryption algorithm of the digital signature in PAC specified by the client, as well as the encryption algorithm of PAC. This allows the attacker to modify the SID in the PAC by forging the PAC, causing the KDC to determine that the attacker is a highly privileged user, resulting in a privilege escalation vulnerability.

III. Brief introduction of GoldenTicket

Golden Ticket (hereinafter referred to as golden ticket) is a forged TGT (TicketGranting Ticket), because as long as you have a high-permission TGT, you can send it to TGS in exchange for the ST of any service. It can be said that with the golden ticket, you have the highest authority in the domain.

The conditions for making golden tickets:

1. Domain name

2. Sid value of the domain

3. Domain KRBTGT account password HASH

4. Forge a user name, which can be arbitrary

Experimental environment

Domain: YUNYING.LAB

Domain control: WindowsServer 2008 R2 x64 (DC)

Domain host: Windows7 x64 (S1): user ts1

Required tools

Mimikatz

Experimental process

To generate the golden ticket, you need to use the password hash value of krbtgt, which can be obtained through the

Lsadump::dcsync / domain:yunying.lab / user:krbtgt

Command to get the value of krbtgt. If you have already obtained the KRBTGT HASH in other ways, you can also proceed directly to the next step.

After getting the KRBTGT HASH, use the kerberos::golden function in mimikatz to generate the golden ticket golden.kiribi, that is, the forged TGT.

Parameter description:

/ admin: forged user name

/ domain: domain name

/ sid: Sid value. Note that the last-following value is removed.

Hash value of / krbtgt:krbtgt

/ ticket: the name of the generated ticket

The use of golden tickets

Import golden.kiribi into memory through the kerberos::ptt function (Pass The Ticket) in mimikatz.

Domain-controlled shared folders have been successfully accessed through dir.

The ticket imported in this way takes effect within 20 minutes, it can be imported again if it expires, and any user can be forged.

IV. Brief introduction of SilverTickets

Silver Tickets (hereinafter referred to as silver ticket) is a fake ST (Service Ticket). Because TGT has defined the service authorized to Client in PAC (through the value of SID), silver ticket can only access the specified service.

The conditions for making silver tickets:

1. Domain name

two。 The Sid value of the domain

3. The password HASH of the service account of the domain (not krbtgt, but domain control)

4. Fake user name. It can be any user name. This is silver.

Experimental environment

Domain: YUNYING.LAB

Domain control: WindowsServer 2008 R2 x64 (DC)

Domain host: Windows7 x64 (S1): user ts1

Required tools

Mimikatz

Experimental process

First of all, we need to know the password HASH of the service account. Here, we also take the domain control as an example to check the hash value of the current domain account administrator through mimikatz. Note that instead of using the HASH of the Administrator account, you are using the HASH of DC$.

At this time, the hash value of DC is obtained, and the silver ticket is generated through mimikatz.

Parameter description:

/ domain: current domain name

/ sid: Sid value, which is the same as the gold ticket. Take the front part.

/ target: target host, this is dc.yunying.lab

/ service: service name. Here you need to access the shared file, so it is cifs.

/ rc4: the Hash value of the target host

/ user: forged user name

/ ptt: indicates a Pass TheTicket attack, which imports the generated ticket into memory, or you can use / ticket export and then use kerberos::ptt to import

At this point, you can see the generated ticket by looking at the kerberos ticket for the current session through klist.

Use dir\\ dc.yunying.lab\ c$ to access the shared folder of DC.

When the silver ticket is generated, there is no KRBTGT password, so you cannot forge TGT tickets, you can only forge ST tickets encrypted by the Server password, and you can only access the specified service.

5. EnhancedGolden Tickets

In the Golden Ticket section, it is explained that the password hash value of krbtgt can be used to generate a golden ticket, so that the domain control authority can be obtained and any service of other hosts in the domain can be accessed. However, the ordinary golden ticket cannot be used across domains, that is, the permission of the golden ticket is limited to the current domain.

1 the limitation of ordinary golden ticket

Why is the ordinary golden ticket restricted to use in the current domain?

In the previous article, we talked about the concepts of domain tree and domain forest, and said that YUNYING.LAB is the root domain of the other two domains (NEWS.YUNYING.LAB and DEV.YUNYING.LAB). The biggest difference between the root domain and other domains is that the root domain has control over the whole domain forest. The domain is based on the Enterprise Admins group (described below) to achieve this kind of permission division.

2 Experimental demonstration

Experimental environment

Root domain: YUNYING.LAB domain control: DC.YUNYING.LAB

Subdomain: NEWS.YUNYING.LAB domain control: NEWSDC.NEWS.YUNYING.LAB

Subdomain: DEV.YUNYING.LAB domain control: DEVDC.DEV.YUNYING.LAB

All operating systems are WindowsServer 2008 R2 x64

Use the tool:

Mimikatz

Experiment procedure:

First of all, use mimikatz to generate a common golden ticket on NEWSDC (domain control of NEWS.YUNYING.LAB). The real environment will be in the host in the domain, so it is easy to demonstrate here, so in domain control, the principle and result are the same.

Kerberos::golden / admin:administrator / domain:news.yunying.lab / sid:SID / krbtgt:XXXXX / ptt

The SID number of the NEWS.YUNYING.lab domain is used here, and access to the DC shared folder of the root domain is denied.

The specific reasons are explained below.

Enterprise Admins group

The EnterpriseAdmins group is a group of users in the domain that exists only in the root domain of a forest. The members of this group, that is, the Administrator users in the YUNYING.LAB (not the local Administrator, but the Administrator in the domain) have full administrative control over the domain.

Through the whoami command on the domain control of yunying.lab, you can see that the RID of the Enterprise Admins group is 519 (the last three digits)

Domain Admins group

You can see that there is no EnterpriseAdmins group in a subdomain, and the group with the highest permissions in a subdomain is the Domain Admins group. The screenshot is the Administrator user in the subdomain news.yunying.lab, which has the highest permissions in the current domain.

You can also see that there is no SID number of the EnterpriseAdmins group in the news.yunying.lab subdomain through the whoami command.

This is the reason why the golden ticket created with mimikatz in the subdomain cannot be used across domains. Through whoami, you can see that the SID number of the Enterprise Admins group in YUNYING.LAB is:

Smur1-5-21-4249968736-1423802980-663233003-519

The SID number in the NEWS.YUNYING.lab domain is:

Smuri 1-5-21-3641416521-285861825-2863956705-XXX

Mimikatz receives the SID number through the / sid option and then splices the RID number (512519, etc.) at the tail. The complete SID of the EnterpriseAdmins group generated after splicing is:

Smur1-5-21-3641416521-285861825-2863956705-519

This SID does not exist in the whole domain forest, so the golden ticket generated by mimikatz in the sub-domain cannot cross-domain or access the resources of other domains. In a domain forest, the domain control authority is not the end point, but the domain control right of the root domain is the end point of domain penetration.

3 break through the limit

Ordinary gold bills are limited to the current domain, and in 2015 researchers outside Black Hat USA China proposed an enhanced version of gold bills that broke through domain restrictions. The cross-domain golden ticket can be made through the Sid value of the previous domain saved by the host in the SIDHistory attribute in the LDAP library when the domain is migrated. There is no migration here, just take the SID number of the root domain as a demonstration.

If you know the SID of the root domain, you can use mimikatz to create a ticket with EnterpriseAdmins group permissions (the highest permission in the domain forest) through the hash value of the KRBTGT of the subdomain. The environment is the same as the generation of the ordinary golden ticket above.

First of all, we delete the Kerberos ticket for the current session through klist purge, or we can delete it through kerberos::purge in mimikatz.

Then regenerate the new golden ticket containing the root domain SID through mimikatz

Kerberos::golden / admin:administrator / domain:news.yunying.lab / sid:XXX / sids:XXX / krbtgt:XXX / startoffset:0 / endin:600 / renewmax:10080 / ptt

Startoffset and endin represent offset and length, respectively, and renewmax represents the longest time of the generated ticket.

Note that the password HASH of the krbtgt of the root domain YUNYING.LAB is not known here, and the password HASH of KRBTGT in the subdomain NEWS.YUNYING.LAB is used.

Then visit DC through dir. The shared folder of YUNYING.LAB has been found to be accessible successfully.

At this time, the ticket has control of the entire domain forest. We know that the condition for making enhanced golden tickets is through SIDHistory. The defense method is to perform SIDHistory filtering during host migration in the domain, which erases the contents of the SIDHistory attribute. The use of MS14068 and gold and silver bills are mainly used to enhance and maintain intra-domain permissions, which usually need to be used in combination with other intra-domain attacks, such as obtaining the NTLM HASH of the domain controller.

This is the answer to the question about the principle and utilization of MS14068 and gold and silver bills in Kerberos. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.