Kerberos Vulnerability in MS14-068 (KB3011780) Explained

Thanks to Gavin Millard (@gmillard on Twitter), we have a graphic that covers the issue quite nicely (wish I had of thought of it!)
Kerb-MS14-068-twitterpic-BoardingPass-Pilot

Exploit Code is now on the net!
As of December 4th, 2014, there is Proof of Concept (POC) code posted that exploits MS14-068 by Sylvain Monné by using Python to interact with an unpatched DC generating the invalid Kerberos ticket and then Mimikatz to use the ticket.
UPDATE: I have successfully tested the MS14-068 exploit in my lab and posted detailed information including WireShark pcaps and DC event logs.

MS14-068 References:

I wrote up a description of the issue that should help explain MS14-068 (KB3011780) without too much Kerberos technical overhead.

For more detail, please read my earlier blog post on MS14-068 (KB3011780).
Get Domain Controller patch status with this sample PowerShell script: Get-DCPatchStatus (rename file extension to .ps1).

Note that Windows Server 2012 impact is less vulnerable than previous Windows versions (i.e., it’s much harder to exploit on Windows Server 2012/2012R2), but all Domain Controllers should be patched ASAP, starting with DCs running Windows Server 2008R2 and below. Patch servers next and workstations last to support “defense-in-depth.” Additionally, Azure Active Directory doesn’t expose Kerberos over any external interface and is not affected by this vulnerability.

Introduction:

Active Directory leverages the Kerberos protocol for authentication. The vulnerability patches an issue with how the Domain Controller validates group membership in Kerberos tickets (hint: this issues is that the ticket is always validated by the DC if the checksum is set to certain values which are invalid).

According to Microsoft: “When this security bulletin was issued, Microsoft was aware of limited, targeted attacks that attempt to exploit this vulnerability.”

This is FAR worse than the Kerberos “Golden Ticket” issue since an attacker doesn’t need the domain Kerberos service account (KRBTGT) NTLM password hash (only accessible from a Domain Controller with domain-level admin privileges) for exploit. The attacker simply modifies the existing TGT by changing the group membership to have access to everything in Active Directory and creates a specific invalid checksum for the PAC signature causing the DC to validate it.

 

MS14-068 Issue Overview:

Simply stated, the vulnerability enables an attacker to modify an existing, valid, domain user logon token (Kerberos Ticket Granting Ticket, TGT, ticket) by adding the false statement that the user is a member of Domain Admins (or other sensitive group) and the Domain Controller (DC) will validate that (false) claim enabling attacker improper access to any domain (in the AD forest) resource on the network. This is all done without changing the members of existing AD groups.
Continue reading

MS14-068: Vulnerability in (Active Directory) Kerberos Could Allow Elevation of Privilege

Active Directory leverages the Kerberos protocol for authentication. The vulnerability patches an issue with how the Domain Controller validates group membership in Kerberos tickets (hint: the ticket is always validated by the DC if the checksum is set to certain values). Microsoft KB3011780 patches this issue.

According to Microsoft: “When this security bulletin was issued, Microsoft was aware of limited, targeted attacks that attempt to exploit this vulnerability.”

Note that Windows Server 2012 impact is less vulnerable than previous Windows versions (i.e., it’s much harder to exploit on Windows Server 2012/2012R2), but all Domain Controllers should be patched ASAP, starting with DCs running Windows Server 2008R2 and below. Patch servers next and workstations last to support “defense-in-depth.” Additionally, Azure Active Directory doesn’t expose Kerberos over any external interface and is not affected by this vulnerability.

MS14-068 References:

Get Domain Controller patch status with this sample PowerShell script: Get-DCPatchStatus (rename file extension to .ps1)

Exploiting MS14-068:

As of December 4th, 2014, there is Proof of Concept (POC) code posted that exploits MS14-068 by Sylvain Monné by using Python to interact with an unpatched DC generating the invalid Kerberos ticket and then Mimikatz to use the ticket.
UPDATE: I have successfully tested the MS14-068 exploit in my lab and posted detailed information including WireShark pcaps and DC event logs.

Kerberos TGT PAC Invalid PAC Signature Checksum validation Issues in MS14-068:

Benjamin Delpy (author of Mimikatz) describes the actual vulnerability with how the PAC signature is checked during his presentation at Passwords 2014 (2 video from the top). I extracted the relevant slide from this presentation (shown below).
There were issues with PAC signature validation in 2011, so going back and looking at MS11-013 is a good start to dig in and see what the actual issue is with MS14-068’s issue with invalid PAC signature checksum validation.

According to his presentation, Benjamin notes the following:

  • Before the MS11-013 patch, the PAC signature was valid if the checksum size was less than or equal to 20 (checksum <= 20)
  • After the MS11-013 patch, the PAC signature was valid if the checksum size was less than or equal to 20 (checksum <= 20) and the checksum is KEYED.
  • After MS14-068 patch, Microsoft added an additional verification step to ensure the checksum type is KRB_CHECKSUM_HMAC_MD5 (or AES in NT6)

py-Passwords2014Slides-PACsigVuln-MS14068

 

Here’s how Kerberos works (in a nutshell):

Ticket Granting Ticket (aka logon ticket)

1. Joe User logs on with his Active Directory user name and password to a domain-joined computer (usually a workstation). The computer takes the user’s password and runs a one way function (OWF) creating a hash of the password (typically the NTLM hash). Hashing the password is like taking a steak and running it through a meat grinder. The ground beef that is the result can never be reassembled back into the same steak we started with.
This is used to  handle all Kerberos requests for the user (as well as other authentication methods such as NTLM).

2. Kerberos authentication is initiated by sending a timestamp (PREAUTH data) encrypted with the user’s password-based encryption key (password NTLM hash).

3. The user account (JoeUser@adsecurity.org) requests a Kerberos service ticket (TGT) with PREAUTH data (Kerberos Authentication Service Request or AS-REQ).

4. The Domain Controller’s Kerberos service (KDC) receives the authentication request, validates the data, and replies with a TGT (Kerberos AS-REP). The TGT has a Privileged Attribute Certificate (PAC) which contains all the security groups in which the user is a member. The TGT is encrypted and signed by the KDC service account (KRBTGT) and only the domain KRBTGT account can read the data in the TGT.
[The vulnerability exists where the PAC is not correctly validated and the exploit requests a TGT without a PAC]

At this point, the user has a valid TGT which contains the users group membership and is used to prove the user is who they claim to be in further conversations with a Domain Controller (KDC). The TGT is sent to the Domain Controller every time a resource ticket is requested.

Ticket Granting Service ticket (aka resource access ticket)

5. When the user wants to access an AD resource (a file share for example), the user’s TGT from step 4 is presented to a Domain Controller (KDC) as proof of identity with a request for a resource ticket to a specific resource (Service Principal Name). The DC determines if the TGT is valid by checking the TGT’s signature and if valid, generates a resource access ticket (TGS) signed/encrypted with the KRBTGT account and a part encrypted with the Kerberos service account’s session key which the destination service uses to validate the TGS.
Note: The DC doesn’t validate the user has the appropriate access to the service, it only validates the TGT and builds a TGS based on the TGT information.

6. The resource service ticket (TGS) is sent to the user by the Domain Controller and is used for authentication to the resource. At this point, all communication has been between the user’s computer and the Domain Controller (KDC).

7. The user’s computer sends the user’s resource service ticket (TGS) to the service on the resource computer. If the destination service is a file share, the TGS is presented to the CIFS service for access.

8. The destination service (CIFS in this example) validates the TGS by ensuring it can decrypt the TGS component encrypted with the service’s session key. The service may send the TGS to a DC (KDC) to validate the PAC to ensure the user’s group membership presented is accurate. The service reviews the user’s group membership to determine what level of access, if any, the user has to the resource.


PAC Validation
described in the blog post Understanding Microsoft Kerberos PAC Validation:

The Privilege Account Certificate (PAC) is an extension element of the authorization-data field contained in the client’s Kerberos ticket. The PAC structure is defined in [MS-PAC] and conveys authorization data provided by domain controllers (DCs) in an Active Directory-enabled domain. It contains information such as security identifiers, group membership, user profile information, and password credentials.

Note: This does not solve the Golden Ticket or Silver Ticket issues since those are technically valid Kerberos tickets.

The Kerberos Golden Ticket is a valid TGT Kerberos ticket since it is encrypted/signed by the domain Kerberos account (KRBTGT). This crafted TGT requires an attacker to have the Active Directory domain’s KRBTGT password hash (typically dumped from a Domain Controller). Mimikatz fully supports generating Golden Tickets.

The Kerberos Silver Ticket is a valid Ticket Granting Service (TGS) Kerberos ticket since it is encrypted/signed by the service account configured with a Service Principal Name for each server the Kerberos-authenticating service runs on. While a Golden ticket is encrypted/signed with the KRBTGT, a Silver Ticket is encrypted/signed by the service account (computer account credential extracted from the computer’s local SAM or service account credential). We know from the Golden Ticket attack (described above) that the PAC isn’t validated for TGTs until they are older than 20 minutes. Most services don’t validate the PAC (by sending the TGS to the Domain Controller for PAC validation), so a valid TGS generated with the service account password hash can include a PAC that is entirely fictitious – even claiming the user is a Domain Admin without challenge or correction. Mimikatz fully supports generating Silver Tickets.

Since service tickets are identical in format to TGTs albeit with a different service name, all you need to do is specify a different service name and use the RC4 (NTLM hash) of the account password (either the computer account for default services or the actual account) and you can now issue service tickets for the requested service.  Note:  You can also use the AES keys if you happen to have them instead of the NTLM key and it will still work ;-)

It is worth noting, that services like MSSQL, Sharepoint, etc will only allow you to play with those services.  The computer account will allow access to CIFS, service creation, and a whole host of other activities on the targeted computer.  You can leverage the computer account into a shell with PSEXEC and you will be running as system on that particular computer.  Lateral movement is then a matter of doing whatever you need to do from there :-)

Continue reading

PowerShell: Discover Active Directory Forest Domain Controllers

Recently I needed to find all Domain Controllers in a large Active Directory forest (and see the AD Domain Functional Level for each domain).

Here’s the PowerShell code which leverages the Active Directory PowerShell module cmdlets.

 

import-module ActiveDirectory
$ADForestInfo = Get-ADForest
$ADForestInfoName = $ADForestInfo.Name
$ADForestInfoDomains = $ADForestInfo.Domains
$ADForestInfoForestMode = $ADForestInfo.ForestMode
$AllDCs = $Null
ForEach ($DomainDNS in $ADForestInfoDomains)
{
[string]$DomainDC = (Get-ADDomainController -Domain $DomainDNS -discover -service “ADWS”).HostName
$DomainInfo = Get-ADDomain -server $DomainDC
$DomainInfoDomainMode = $DomainInfo.DomainMode
[array]$AllDomainDCs = Get-ADDomainController -server $DomainDC -filter *
$AllDomainDCsCount = $AllDomainDCs.Count
Write-Output “Discovered $AllDomainDCsCount Domain Controllers in the $DomainDNS Domain (DFL: $DomainInfoDomainMode) ”
[array]$AllDCs += $AllDomainDCs
}
$AllDCsCount = $AllDCs.Count
Write-Output “Discovered $AllDCsCount Domain Controllers in the AD Forest $ADForestInfoName (FFL: $ADForestInfoForestMode) ”
$AllDCs | select domain,name,operatingsystem,OperatingSystemServicePack | sort domain | ft -auto

PowerShell Encoding & Decoding (Base64)

PowerShell provides an easy method for Base64 encoding and decoding.

Encoding:

$Text = ‘This is a secret and should be hidden’
$Bytes = [System.Text.Encoding]::Unicode.GetBytes($Text)
$EncodedText =[Convert]::ToBase64String($Bytes)
$EncodedText

The result is this base64 encoded text:
VABoAGkAcwAgAGkAcwAgAGEAIABzAGUAYwByAGUAdAAgAGEAbgBkACAAcwBoAG8AdQBsAGQAIABiAGUAIABoAGkAZABlAG4A

Decoding:
Decoding the base64 encoded blob using PowerShell is simple.

$EncodedText = “VABoAGkAcwAgAGkAcwAgAGEAIABzAGUAYwByAGUAdAAgAGEAbgBkACAAcwBoAG8AdQBsAGQAIABiAGUAIABoAGkAZABlAG4A”
$DecodedText = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($EncodedText))
$DecodedText

 

 

PowerShell: Find All Users in Active Directory the Optimal Way

Today I Learned (TIL) that the best way to find all users in Active Directory via LDAP query is to search for: (samAccountType=805306368)
and NOT: (&(objectClass=user)(objectCategory=person))

Reference: http://www.selfadsi.org/extended-ad/search-user-accounts.htm

PowerShell 101: Easy Script Timing

There are times when you want to know how long it takes for a script to run. One of the Measure-* cmdlets can be useful, but there is a simpler way to time how long it takes to run a script (or piece of code).
The StopWatch .NET method is an ideal method for script timing.

More info on using the StopWatch .Net method:
http://technet.microsoft.com/en-us/magazine/2009.03.heyscriptingguy.aspx

# START OF SCRIPT
$CurrentUserName = $env:UserName
$ScriptProcessStartTime = Get-Date
write-output “” `r
write-output “Script initialized by $CurrentUserName and started processing at $ScriptProcessStartTime `r ”
$ScriptTimer = [System.Diagnostics.Stopwatch]::StartNew()
write-output “” `r

## SCRIPT BODY

## END OF SCRIPT
$ScriptProcessEndTime = Get-Date
write-output “Script started processing at $ScriptProcessStartTime and completed at $ScriptProcessEndTime.” `r
write-host “Total Processing Time: $($ScriptTimer.Elapsed.ToString())”

 

Owning Networks and Evading Incident Response with PowerShell

 

PowerShell provides an easy method to bypass antivirus and other protection methods:

Up until several months ago, I was a member of a penetration test team tasked with compromising data centers and evading detection. Industry standard tools such as Metasploit (an attack toolkit that includes a backdoor named Meterpreter) and Mimikatz (a password dumper) worked well, but I was a paranoid attacker and was worried that running these tools (compiled as unsigned EXE files) would get me detected.

I started to take a look at PowerShell after reading a blog post by Matt Graeber on launching Meterpreter using PowerShell. Since antivirus pays no attention to PowerShell scripts, I was able to use Meterpreter without launching a suspicious EXE and without having to worry about disabling antivirus.

I wanted to go a little further though. Instead of just loading Meterpreter, I wanted to be able to load unmanaged DLLs and EXEs (both are actually Windows PE files) without calling LoadLibrary or CreateProcess (because these APIs can be monitored by AppLocker and other similar tools).

The solution to this problem was to write my own PE loader. Instead of relying on Windows APIs (LoadLibrary, CreateProcess) to load PE files in memory, I wrote a PowerShell script Invoke-ReflectivePEInjection that roughly recreates the functionality provided by the Windows API. The benefits of Invoke-ReflectivePEInjection are over the Windows APIs are:

 

Read the rest at PowerShell Magazine

Read more about Mimikatz and Active Directory Kerberos hacking here.

 

Active Directory Replication Overview & USN Rollback: What It Is & How It Happens

If you have experienced event id #2095, then you understand how a USN Rollback can negatively affect AD consistency.

What is a USN?

The USN (Update Sequence Number) is an Active Directory database instance counter that increments every time a single change is committed to the AD database on a Domain Controller. The USN is unique to each DC and has no correlation to a USN on another DC (and that doesn’t matter, as you will see why later on in this article).  Active Directory replication keeps track of every Domain Controller’s USN and uses this information to determine when replication is required. Active Directory has two basic types of writes to the AD database, a replicated write (where the change is performed on another DC) and an originating write (where the change is performed on the local DC). AD Replicates and leverages the information about what changes were performed on which DCs and then replicated out.

Every Domain Controller has a server object in the site container stored within the Configuration partition. This object has a child object called “NTDS Settings” which has a GUID (Globally Unique IDentifier) attribute which is replicated as part of replication metadata and used by the KCC to build the replication topology. Each DC has its own copy of the Active Directory database stored in the ntds.dit file and this unique database instance on a DC is identified with its own GUID-type identifier called the “Invocation ID”. The Invocation ID is created when the DC is promoted and only changes when the AD database is restored using a supported method or an application partition is added or removed.  The reason for this is so that when an AD database is restored to an earlier point in time, the USN is also restored to that point in time. This means that any change from the restored USN value until the original, pre-restored USN value would be ignored by other DCs pulling replication from the restored DC (since they track other DCs USNs that they replicate with and only pull updates when the destination DC’s USN increments above the last stored update value USN the DC has for it – more on this later). In order to avoid this situation, the DC’s AD database generates a new Invocation ID and stores the old Invocation ID is stored in an attribute on the server’s NTDS Settings object called retiredReplDSASignatures. In this manner, the DCs will treat a new Invocation ID as a new database and ensure it gets updates from it moving forward. You can see a DC’s Invocation ID and Server GUID by running repadmin /showrepl.
Continue reading

Group Policy Settings Reference Guide for Windows 8.1 | 7 | Server

 

The Group Policy is an integral part of the Windows operating system, on which many a IT Pro, Beginners and Tweak enthusiasts count on to customize and enforce settings on their computers. The Group Policy Editor (Gpedit.msc) is one of the most useful tools for administering policy on Windows.

The Group Policy Editor, however is not included in every edition of Windows. For instance, in Windows 8, the Group Policy is included only with Windows 8 Pro and Enterprise Editions. While Windows 7 Ultimate, Professional and Enterprise editions have it, Windows 7 Home Premium, Home Basic and Starter Editions do not include the Group Policy Editor.

Group Policy Settings Reference Guide

Microsoft has updated and made available as a download, the complete Group Policy Settings Reference Guide for Windows 8.1, Windows 8, Windows 7, Windows Vista, Windows Server 2003 SP2, Windows Server 2008 R2 and Windows Server 2012 R2. The download is available in the form of spreadsheets for different operating systems. So you can download the spreadsheet only for those operating system/s which you may be interested in.

Read the rest here