Digging into MS14-068, Exploitation and Defence

The vulnerability, known by the identifier MS14-068 (CVE-2014-6324), allows any authenticated domain user to escalate their privileges to domain administrator. As a result, an authenticated attacker is able to completely compromise the domain. Most concerning of all it was revealed that this issue was being exploited in the wild!

This post will discuss the technical details of this vulnerability and provide a brief guide for exploiting this issue in a couple of common scenarios that may be encountered during a penetration test.

Kerberos enables users to authenticate to services via a trusted third party. This allows authentication to be centralised so that all the remote services in a network do not require access to user secrets for authentication purposes. The following steps provide a brief overview of the initial stages of the Kerberos protocol in a Windows domain:

The user authenticates with the trusted third party known as the Key Distribution Centre (KDC) — the domain controller in a Windows domain — by sending a message containing their identity and a timestamp encrypted with their password as proof of identity.

If the user authenticated successfully then the KDC constructs a ticket granting ticket (TGT) that will be used by the client to request tickets for other services. The TGT is a service ticket for the Ticket Granting Service (TGS) which is also running on the KDC.

Simplified example of a TGT

A Kerberos ticket, such as a TGT, contains identifying information about a user and their roles. In a Windows domain this structure is known as the Privilege Attribute Certificate (PAC) which stores information that includes the account name, ID and group membership information. In order to protect the integrity of the PAC it is signed by the KDC using secret keys known only to the KDC and the target service. One signature uses the target service account’s key and the other uses a key known only by the KDC. This allows the KDC or the target service to verify that the PAC has not been tampered with after creation. Furthermore, the entire ticket is encrypted using the target service’s secret key.

In the case of the TGT the account of the target service is the krbtgt account. Therefore, both signatures on the PAC are keyed with the krbtgt account’s key and the ticket is encrypted with that same key.

The ticket also contains a session key for use in future communication with the TGS. The TGT is returned by the KDC in a message that also contains the TGS session key encrypted with the secret key of the user.

The request for a service ticket from the TGS contains three major components:

• The name of the service that will be accessed
• The TGT which is encrypted with the krbtgt key
• An authenticator: the user ID and a timestamp encrypted with the TGS session key

The TGS can decrypt the presented TGT in order to recover the session key. This key is then used to decrypt the authenticator. The TGS is now able to verify that the ID contained in the authenticator matches the TGT, that the TGT has not expired, and the PAC has a valid signature. If the the information presented is acceptable then the information from the PAC in the TGT is copied into a new service ticket.

The PAC in the new ticket is signed once using the key of the target service and then again with the krbtgt key. The ticket itself is encrypted using the key of the target service.

The client can use the ticket returned by the TGS as a proof of identity with which to access the target service.

On 18th November a critical security patch was released by Microsoft to fix an issue in the way the KDC validates the signature of the PAC. This vulnerability would allow a PAC to be forged that would be accepted by the KDC as legitimate. Since the PAC contains the groups that the user is a member of it would be possible to abuse the flaw to create a fake PAC claiming they are a member of the domain administrators group.

The underlying issue was relatively simple. Instead of requiring one of the three signature types prescribed by the MS-PAC specification, the KDC service would accept any checksum type that is implemented in the low-level cryptographic library. The supported checksums included unkeyed algorithms such as plain MD5 or even CRC32. Therefore, it is possible to forge a PAC without knowledge of any secret keys by ‘signing’ it using CRC32.

This issue was easy to verify by making a small modification to Mimikatz so that the PAC in a golden ticket is ‘signed’ using CRC32:

The following screenshot shows the ‘signatures’ on the PAC in the TGT generated by the patched version of Mimikatz:

CRC32 PAC Signature

Although this test of MS14-068 is successful, Mimikatz still requires the krbtgt key in order to encrypt the TGT. We managed to create a forged PAC, but it doesn’t seem possible to put it into a TGT without knowledge of the target service’s secret key (i.e. the krbtgt account’s hash). If this key is available then the standard golden or silver ticket attacks apply, so MS14-068 is unnecessary.

The observation made by Sylvain Monné, and neatly exploited in his proof of concept (PyKEK), is that the PAC does not necessarily need to be included in the encrypted ticket. Instead, a forged PAC can be placed in the enc-authorization-data segment of the TGS-REQ message. Although this field is encrypted, it is protected with a key known to the user. Either the TGT session key or a sub-session key (specified in the authenticator) can be used. The second trick is to request a valid TGT that does not contain a PAC by setting the PA-PAC-REQUEST parameter in the AS-REQ to false. This is done to ensure there are no conflicts between the legitimate PAC in the TGT and the forged PAC included elsewhere.

So, in order to perform the exploit, only the ID and password of a standard domain user are required. These details are necessary to request a PAC-less TGT, recover the session key that is returned, and encrypt the authenticator in the TGS-REQ.

The following image shows a simplified example of a TGS-REQ message to exploit MS14-068. A valid TGT is included, but it does not contain a PAC. Instead, a malicious PAC created by the user has been included in the enc-authorization-data field. This PAC claims that the user is a member of a number of privileged groups, including the domain administrators, and has been ‘signed’ using plain MD5.

TGS-REQ containing a forged PAC to exploit MS14-068

The steps taken by PyKEK to exploit MS14-068 are as follows:

1. Request a TGT without a PAC by sending an AS-REQ with PA-PAC-REQUEST set to false.
2. Forge a PAC claiming membership of domain administrators. ‘Sign’ it using plain MD5.
3. Create a TGS-REQ message with krbtgt as the target. The TGT from the first step is used along with the fake PAC encrypted with a sub-session key.
4. Send this to a vulnerable domain controller.

The KDC service will accept the forged PAC and return a new TGT which contains a PAC. This TGT can be injected into memory using Mimikatz to be used during the standard Kerberos authentication flow.

Interestingly this entire issue is a repeat of CVE-2011-0043 (MS11-013), albeit in a different area of code. At that time the issue was identified as a “Kerberos Unkeyed Checksum Vulnerability” and due to “the Microsoft Kerberos implementation [supporting] a weak hashing mechanism, which can allow for certain aspects of a Kerberos service ticket to be forged”. Furthermore, this issue was reported by the MIT Kerberos team after the same vulnerability was fixed in their implementation in 2010 (CVE-2010-1324). Given that the issue was found to be being actively exploited prior to the patch being released it is possible that MS14-068 has been used by advanced attackers for a few years now.

As well as the above mentioned Python Kerberos Exploitation Kit (PyKEK), there is a second toolkit which contains a function exploit: Golden PAC module in Impacket.

At the time of writing, these attacks work against domain controllers running Windows 2008 (R2), and earlier, but not against Windows 2012. The only other requirement is a valid domain account username and password.

The only sure method for detecting a vulnerable system is to look at its patch level (or by attempting to exploit it). However, the Responder tool from SpiderLabs includes a script that will perform basic vulnerability detection by checking the uptime of the server to see if it has been rebooted since the patch was released.

This check can yield false negatives as a domain controller may have been rebooted without the patch having been applied. For example, the following check shows an un-patched system that has been restarted:

The first demonstration is against the target when you have normal network level access. This means you have your DNS server set to the domain’s DNS server (probably your target DC).

It is important when working with Kerberos that your system clock is synced with the target host. Kerberos generally allows a 5 minute skew by default, but we can use tools to find the target’s time from an unauthenticated perspective. For example, the net command:

Or with the nmap smb-os-discovery script:

After setting your local system time, we need to get the user’s SID. We can query this remotely with the net tool:

We can combine the Domain SID with the user RID to get the target user’s SID: S-1-5-21-2928836948-3642677517-2073454066-1105.

The next step is to generate our Kerberos ticket with PyKEK. We need to supply the following arguments:

• -u USERNAME@FQDN.DOMAIN.NAME (our username)
• -d TARGET.FDQN.DOMAIN.NAME (the domain controller)
• -p PASSWORD (our password)
• -s SID (our SID)

The following command has generated a forged TGT for user01 and stored it in the TGT_user01@metasploitable.local.ccache file:

To use this ticket, which is in the Credential Cache (ccache) format, we need to move it to the /tmp directory where the Kerberos tools look for tickets:

and even use winexe to execute commands:

In order to get a reverse shell, we can set up a Metasploit delivery mechanism such as Powershell Web Delivery:

We then pass the powershell command line to winexe to run as a service:

The result is a reverse shell with administrative privileges on the domain controller. At this point we can create a permanent back-door on the domain to maintain access even if the vulnerability becomes patched in the future.

The Golden PAC module included in Impacket makes post exploitation easier by performing it automatically for you. Once a TGT containing a forged PAC has been created it is used to create an SMB connection to the domain controller and the PsExec technique is used to gain command execution:

The second scenario is exploiting a target user who we have compromised remotely, such as via a phishing attack. We assume that we have a shell on the user’s machine, and have recovered their password (e.g. by escalating to SYSTEM and using Mimikatz to dump it).

We need to be able to talk to the domain controller in order to use the exploit scripts. So, we add a port forward to meterpreter to pivot port 88 (kerberos) over our implant:

The FQDN for the target system should also point to localhost so that traffic is forwarded via meterpreter. This can be done with a simple addition to /etc/hosts:

The user’s SID can be discovered via the command line:

We know have all the information required to use PyKEK to generate our privileged TGT:

Although Mimikatz can load our ccache file using the kerberos::ptc command, at present the Meterpreter Kiwi module only has support for .kirbi files. We can convert our ccache file to kirbi using Mimikatz as follows:

Now we can load the Kiwi Mimikatz extension into meterpreter, install our ticket, and access resources as a Domain Administrator:

We can then use create a service remotely, like PSEXEC to get a reverse shell:

Pivoting native tools via Meterpreter to exploit this issue can prove difficult. Forwarding TCP port 445 allows you to use smbclient, however tools such as Winexe require ephemeral DCE-RPC ports so unless you are creating a VPN to your target this would be painful to use remotely. Hopefully more support for this soon.

Also, it’s worth keeping your eye on the current_user_psexec module as it may simplify the post exploitation steps in future. We have made a pull request that introduces Kerberos support, by targeting hostnames instead of IP addresses, to this module:

There are a few common issues that may prevent the MS14-068 exploits from working correctly. For example, if the DNS server isn’t resolving correctly you can have trouble authenticating with the Kerberos token. Here are a couple of tricks if you have problems exploiting the issue:

• Check your local system time is in sync with target
• Try with full domain name in CAPITALS, e.g. MSFDC01.METASPLOITABLE.LOCAL
• Try without the FQDN (i.e. just the Netbios name), e.g. msfdc01 or MSFDC01
• Add the addresses to your /etc/hosts file
• Use Wireshark to check the DNS requests, you may see incorrect requests like MSFDC01.METASPLOITABLE.LOCAL.METASPLOITABLE.LOCAL

The only solution for preventing this attack is to apply the patch. If this hasn’t been done already then it may be too late. Microsoft have indicated just how serious this issue is in their blog post giving additional information on the issue:

This guidance just highlights how important it is to apply security patches in a timely manner.

In the same post, Microsoft provided advice on detecting exploitation of MS14-068. They indicated that login events with a mismatch between the SID and the account name had been observed in the wild. However, the public exploits that have been recently released do not have this same indicator when used correctly. Therefore, only those with well developed monitoring infrastructure are likely to identify any access anomalies that indicate compromise and attempts to exfiltrate data.

This vulnerability demonstrates that if an organisation’s security relies heavily on a single control, such as whether the user is in a particular domain group, they are at risk from attackers defeating that control and gaining easy access to sensitive information. Security must come from understanding which assets are important, where they are located, and restricting routes to those assets so that, for example, a single compromised desktop cannot access them. The number of access routes to critical data should be minimized and hardened to prevent initial exploitation and local privilege escalation. They should also be heavily monitored for signs of compromise, such as accounts trying to access resources they shouldn’t or accounts being added to privileged groups, or early indicators of an attacker trying to gain a foothold, such as EMET or software restriction exceptions.

A key goal of attackers seeking to compromise a company’s assets is to escalate their privileges to make discovery and access to the information they seek easier. Therefore, a vulnerability such as MS14-068 is highly valuable to them as it allows total access to the domain from a simple phishing attack on a single desktop user. The fact that exploitation of this issue was found in the wild also shows that attackers are not just researching 0-days in browsers and file viewing software, but are also actively researching later stages of compromise such as lateral and vertical movement.

MS14-068 is an exciting prospect for penetration testers as it may provide us with an easy privilege escalation route in engagements over the next few years. However, the worrying flip-side to this is that sensitive corporate and national networks are likely to be vulnerable to such an easy attack. Even worse, it will be difficult to be certain of the integrity of networks that have been patched.

• Additional information about CVE-2014-6324
• Microsoft Security Bulletin MS14-068 – Critical
• Microsoft Security Bulletin MS11-013 – Important
• MIT krb5 Security Advisory 2010-007
• A Quick Look at MS14-068
• mimikatz presentation by Benjamin Delpy – Passwords#14
• MS-PAC: Privilege Attribute Certificate Data Structure