{"id":541,"date":"2014-11-19T19:24:58","date_gmt":"2014-11-20T00:24:58","guid":{"rendered":"http:\/\/adsecurity.org\/?p=541"},"modified":"2015-12-30T11:42:58","modified_gmt":"2015-12-30T16:42:58","slug":"kerberos-vulnerability-in-ms14-068-explained","status":"publish","type":"post","link":"https:\/\/adsecurity.org\/?p=541","title":{"rendered":"Kerberos Vulnerability in MS14-068 (KB3011780) Explained"},"content":{"rendered":"<p>Thanks to Gavin Millard (<a href=\"https:\/\/twitter.com\/gmillard\">@gmillard<\/a> on Twitter), we have a graphic that covers the issue quite nicely (wish I had of thought of it!)<br \/>\n<a href=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2014\/11\/Kerb-MS14-068-twitterpic-BoardingPass-Pilot.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-medium wp-image-542\" src=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2014\/11\/Kerb-MS14-068-twitterpic-BoardingPass-Pilot-300x182.png\" alt=\"Kerb-MS14-068-twitterpic-BoardingPass-Pilot\" width=\"300\" height=\"182\" srcset=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2014\/11\/Kerb-MS14-068-twitterpic-BoardingPass-Pilot-300x182.png 300w, https:\/\/adsecurity.org\/wp-content\/uploads\/2014\/11\/Kerb-MS14-068-twitterpic-BoardingPass-Pilot.png 721w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/a><\/p>\n<p><strong><a title=\"MS14-068 Kerberos Vulnerability Privilege Escalation POC Posted (PyKEK)\" href=\"https:\/\/adsecurity.org\/?p=660\">Exploit Code<\/a> is now on the net!<\/strong><br \/>\nAs of December 4th, 2014, there is <a title=\"MS14-068 Kerberos Vulnerability Privilege Escalation POC Posted (PyKEK)\" href=\"https:\/\/adsecurity.org\/?p=660\">Proof of Concept (POC) code posted that exploits MS14-068<\/a> by\u00a0Sylvain Monn\u00e9 by using Python to interact with an unpatched DC generating the invalid Kerberos ticket and then <a title=\"Mimikatz and Active Directory Kerberos Attacks\" href=\"https:\/\/adsecurity.org\/?p=556\">Mimikatz<\/a> to use the ticket.<br \/>\n<em><strong>UPDATE: I have successfully tested the MS14-068 exploit in my lab and <a title=\"Exploiting MS14-068 Vulnerable Domain Controllers Successfully with the Python Kerberos Exploitation Kit (PyKEK)\" href=\"https:\/\/adsecurity.org\/?p=676\">posted detailed information including WireShark pcaps and DC event logs<\/a>.<\/strong><\/em><\/p>\n<h4><span style=\"text-decoration: underline;\">MS14-068 References:<\/span><\/h4>\n<ul>\n<li><a title=\"MS14-068: Vulnerability in (Active Directory) Kerberos Could Allow Elevation of Privilege\" href=\"https:\/\/adsecurity.org\/?p=525\">AD Kerberos Privilege Elevation Vulnerability: The Issue<\/a><\/li>\n<li><a title=\"MS14-068 Kerberos Vulnerability Privilege Escalation POC Posted (PyKEK)\" href=\"https:\/\/adsecurity.org\/?p=660\">MS14-068 Exploit POC with the Python Kerberos Exploitation Kit (aka PyKEK)<\/a><\/li>\n<li><a title=\"Exploiting MS14-068 Vulnerable Domain Controllers Successfully with the Python Kerberos Exploitation Kit (PyKEK)\" href=\"https:\/\/adsecurity.org\/?p=676\">Exploiting MS14-068 Vulnerable Domain Controllers Successfully with the Python Kerberos Exploitation Kit (PyKEK)<\/a><\/li>\n<li><a title=\"PyKEK Kerberos Packets on the Wire aka How the MS14-068 Exploit Works\" href=\"https:\/\/adsecurity.org\/?p=763\">PyKEK Kerberos Packets on the Wire aka How the MS14-068 Exploit Works<\/a><\/li>\n<\/ul>\n<p>I wrote up a description of the issue that should help explain MS14-068 (KB3011780) without too much <a href=\"https:\/\/adsecurity.org\/?p=227\">Kerberos technical overhead<\/a>.<\/p>\n<p>For more detail, please read my earlier <a title=\"MS14-068: Vulnerability in (Active Directory) Kerberos Could Allow Elevation of Privilege\" href=\"https:\/\/adsecurity.org\/?p=525\">blog post on MS14-068 (KB3011780)<\/a>.<br \/>\nGet Domain Controller patch status with this sample PowerShell script:\u00a0<a href=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2014\/12\/Get-DCPatchStatus.txt\">Get-DCPatchStatus<\/a> (rename file extension to .ps1).<\/p>\n<p>Note that Windows Server 2012 impact is less vulnerable than previous Windows versions (i.e., it&#8217;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 &#8220;defense-in-depth.&#8221; Additionally, Azure Active Directory doesn&#8217;t expose Kerberos over any external interface and is not affected by this vulnerability.<\/p>\n<p><span style=\"text-decoration: underline;\"><strong>Introduction:<\/strong><\/span><\/p>\n<p>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).<\/p>\n<p>According to <a href=\"https:\/\/technet.microsoft.com\/en-us\/library\/security\/MS14-068\">Microsoft<\/a>: <strong><em>\u201cWhen this security bulletin was issued, Microsoft was aware of limited, targeted attacks that attempt to exploit this vulnerability.\u201d<\/em><\/strong><\/p>\n<p><strong>This is FAR worse than the Kerberos \u201cGolden Ticket\u201d issue since an attacker doesn\u2019t need the domain Kerberos service account\u00a0<a href=\"https:\/\/adsecurity.org\/?p=483\">(KRBTGT)<\/a> 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.<br \/>\n<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p><strong><span style=\"text-decoration: underline;\">MS14-068 Issue Overview:<\/span><br \/>\n<\/strong><\/p>\n<p>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.<br \/>\n<!--more--><\/p>\n<p>When a user logs on with domain credentials for the first time, the user name and password are validated by the Domain Controller and the DC enumerates the user\u2019s group membership and logon restrictions. A domain logon token (TGT) is created with this data and provided to the user.<\/p>\n<p>One of the benefits of Kerberos is that the user doesn\u2019t have to re-authenticate to the Domain Controller to access resources on the domain, the user simply presents the logon token (TGT) to the DC and receives a resource access token (Kerberos Ticket Granting Service, TGS, ticket). The user then provides the resource access token (generated by the DC and specific to the user) to the server hosting the service the user wishes to access. The resource access token includes the user\u2019s information including the user\u2019s group membership enabling the resource to determine if the user should be granted access and what level of rights the user has.<\/p>\n<p>The issue here is that core to this functionality is that the DC trusts all non-expired logon tickets (valid for 10 hours by default) since they are signed by the domain\u2019s Kerberos account <a href=\"https:\/\/adsecurity.org\/?p=483\">(KRBTGT)<\/a>. In other words, Kerberos tickets signed by a (writable) DC on the network are inherently trusted as correct since they are signed by the DC\u2019s Kerberos service account <a href=\"https:\/\/adsecurity.org\/?p=483\">(KRBTGT)<\/a>. When the DC receives an access request for a service on the network, the user\u2019s token (TGT) is supposed to be validated by checking the signature to ensure the user\u2019s claim is a valid one.<br \/>\nFor example<\/p>\n<p><em>Logon Token (TGT): \u201cI am Joe User and I am a member of the following groups: Domain Users, Limited Access Users.\u201d<\/em><\/p>\n<p>The Domain Controller should validate the claim that Joe is a member of these groups (also called PAC validation), not by enumerating group membership again (which was done before the ticket was generated), but by validating the cryptographic signature on the token which was signed by the domain\u2019s Kerberos account\u00a0<a href=\"https:\/\/adsecurity.org\/?p=483\">(KRBTGT)<\/a> and for which only a Domain Controller in that domain knows the credentials. This is done for improved efficiency \u2013 since the work was already done by a DC and signed by that DC that it was performed; another DC takes the claim at face value and doesn\u2019t attempt to enumerate the user\u2019s group membership again.<\/p>\n<p>The vulnerability introduces a scenario where an attacker can modify an existing Kerberos user logon token (TGT) changing the group membership claim to include a higher-privileged group.<\/p>\n<p><em>Logon Token (TGT): \u201cI am Joe User and I am a member of the following groups: Domain Users, <span style=\"text-decoration: line-through;\">Limited Access Users <\/span>Domain Admins, Special Project Users, Executive Access, Super Secret Share Access.\u201d<\/em><\/p>\n<p>Since the DC doesn\u2019t properly validate the signature associated with the claim (the attacker modified the Kerberos ticket and changed the checksum to be invalid), the DC accepts Joe\u2019s token and associated group membership and generates a resource access token (TGS) which includes the group membership included in the logon token (TGT).<\/p>\n<p>At this point, the attacker has a valid user token with a claim that the user is a member of groups that do not have the user listed as a member in AD. However, <em>since the user token states the user is a member of these groups and the Domain Controller generates this token based on the user\u2019s actual group membership at the time of token generation, the user is treated as if he is a member of these groups by all domain resources.<\/em><\/p>\n<p>An attacker can take the modified user logon token (TGT) and present it to gain access to any resource on the network by requesting resource access tokens (TGS). The resource accepts the resource access token since it is signed by the DC and even if the resource requests validation of the group membership (because it\u2019s cautious), a DC will validate it. The resource then allows the users access to the level of permissions configured on the resource appropriate to the user\u2019s group membership.<\/p>\n<p>This enables an attacker on a computer in the AD domain with a valid AD credential to effectively \u201cspoof\u201d any user in the domain (and likely the forest) since the PAC contains user or group Security Identifiers (SIDs). This means that an attacker can bypass all configured resource ACLs which limit access on the network by spoofing credentials for any user in Active Directory.<\/p>\n<p>Note: The caveat to this process is that the attacker requires the ability to run code on a domain-joined computer and have access to a user account. With that stated, this is a relatively low bar given how easily malicious code tends to enter and propagate in modern networks.<\/p>\n<p><strong><span style=\"text-decoration: underline;\">Detection:<\/span><\/strong><\/p>\n<p>Detecting Kerberos attacks is inherently difficult since there are tens of Kerberos tickets generated for each user in a single day (1 TGT and at least 1 TGS each for every file share, SharePoint server, Exchange server, etc. accessed by the user). Furthermore, 99% of Kerberos attacks look like valid Kerberos tickets and communication.<\/p>\n<p>While Microsoft notes that in the attack method they have determined, the event log id, Event 4624 (\u201cAn account was successfully logged on\u201d), shows a user mismatch between the security id and account name they also note that a determined attacker is likely to fix this so they match, limiting detection ability: <em>\u201cPlease note that this logging will only catch known exploits; there are known methods to write exploits that will bypass this logging.\u201d<\/em><\/p>\n<p>Note: <em>After installing the update, for Windows 2008R2 and above, the <\/em><a href=\"https:\/\/www.ultimatewindowssecurity.com\/securitylog\/encyclopedia\/event.aspx?eventID=4769\"><em>4769 Kerberos Service Ticket Operation event<\/em><\/a><em> log can be used to detect attackers attempting to exploit this vulnerability. This is a high volume event, so it is advisable to only log failures (this will significantly reduce the number of events generated).<\/em> [<a href=\"https:\/\/technet.microsoft.com\/en-us\/library\/security\/MS14-068\">From Microsoft Security Bulletin MS14-068 &#8211; Critical Vulnerability in Kerberos Could Allow Elevation of Privilege<\/a>]<\/p>\n<p>CERT describes the issue in <a href=\"http:\/\/www.kb.cert.org\/vuls\/id\/213119\">CWE-347: Improper Verification of Cryptographic Signature<\/a><\/p>\n<p><em>\u201cThe Microsoft Windows Kerberos KDC fails to properly check for valid signatures in the Privilege Attribute Certificate (PAC) included with the Kerberos ticket request. <strong>A domain user may forge the information contained in the PAC to request higher user privileges than should be allowed. Since the KDC does not verify the signature correctly, it will award the user the requested privileges, effectively making the user a domain administrator and allowing complete compromise of the entire domain.<\/strong>\u201d<\/em><\/p>\n<p><span style=\"text-decoration: underline;\"><strong>\u00a0Remediation of an Attack Leveraging this Vulnerability:<\/strong><\/span><\/p>\n<p><a href=\"http:\/\/blogs.technet.com\/b\/srd\/archive\/2014\/11\/18\/additional-information-about-cve-2014-6324.aspx\">According to Microsoft<\/a>, if an attacker gets Admin rights to your Active Directory environment, it&#8217;s game over.<\/p>\n<blockquote><p><strong>Remediation<\/strong><\/p>\n<p>The only way a domain compromise can be remediated with a high level of certainty is a complete rebuild of the domain. An attacker with administrative privilege on a domain controller can make a nearly unbounded number of changes to the system that can allow the attacker to persist their access long after the update has been installed. Therefore it is critical to install the update immediately.<\/p><\/blockquote>\n<p>For more detail on this issue, please read my earlier <a title=\"MS14-068: Vulnerability in (Active Directory) Kerberos Could Allow Elevation of Privilege\" href=\"https:\/\/adsecurity.org\/?p=525\">blog post on MS14-068<\/a>.<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Thanks to Gavin Millard (@gmillard on Twitter), we have a graphic that covers the issue quite nicely (wish I had of thought of it!) 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\u00a0Sylvain Monn\u00e9 by using Python to interact with &hellip; <\/p>\n<p><a class=\"more-link btn\" href=\"https:\/\/adsecurity.org\/?p=541\">Continue reading<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,2],"tags":[337,205,298,296,297,289,295],"class_list":["post-541","post","type-post","status-publish","format-standard","hentry","category-microsoft-security","category-technical-reference","tag-kb3011780","tag-kerberosgoldenticket","tag-kerberoshacking","tag-kerberosinvalidchecksum","tag-kerberosvulnerability","tag-ms14-068","tag-ms14068","item-wrap"],"_links":{"self":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts\/541","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=541"}],"version-history":[{"count":12,"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts\/541\/revisions"}],"predecessor-version":[{"id":1475,"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts\/541\/revisions\/1475"}],"wp:attachment":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=541"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=541"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=541"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}