Meeting the InCommon Assurance profile criteria using Active Directory

[Brian Arkills <>]

Here's some material for the Kerberos follow-up.

 

http://www.blackhat.com/presentations/bh-europe-09/Bouillon/BlackHat-Europe-09-Bouillon-Taming-the-Beast-Kerberous-whitepaper.pdf discusses the various security issues known for Kerberos as of 2009. The techniques discussed there include "KDC spoofing" which requires that the Kerberos enabled service doesn't do the full exchange it should do, a replay attack which uses a sniffed AP exchange in a later TGS attack against the Kerberos enabled service involved in that AP exchange, and a "pass the ticket" attack which combines the two in a Windows environment to get a TGS. There is also some discussion of user impersonation attacks to get a TGT, but it's pretty clear that the Windows implementation is safe from this, although given elevated access on a single domain-joined computer, it is possible to steal & re-use a "computer's" principal and use it to enumerate domain resources.

 

http://csis.bits-pilani.ac.in/faculty/sundarb/courses/old/spr06/netsec/evals/project/projrefs/kerb/AIWSC03_kerberos_replay_attacks.pdf was the other Kerberos attack paper I had previously dug up. It discusses the very same replay attack discussed in the blackhat paper above, except in a more understandable form, and in more detail.

 

So these attacks can result in a TGS, but not a TGT. Put together in the "pass the ticket" attack, they constitute a man-in-the-middle profile. There are replay elements, but the replay elements by themselves can't result in a TGT. Likewise, there are eavesdropper elements, but those can't result in a TGT either. I don't see any issue worth noting as a gap here for the context of 4.2.5.1 or 4.2.5.2, except for one very specific scenario: AD is the IdP, and the TGS which is attacked involves the IdP token issuing service.

 

I'm certain that RFC4120 (FAST or Kerberos armoring)--as implemented in WS2012 DCs--would mitigate that very specific scenario. There may be other mitigations or it's possible that with a closer analysis this scenario isn't actually vulnerable.

 

In the interest of sending this today before the weekend, I'm not evaluating whether that risk is negligible before sending this email. :)

 

In summary, I think we can claim Kerberos is resistant in both 4.2.5.1 & 4.2.5.2, but there is still that very specific scenario that needs a bit more thought/examination.

 

From: Brian Arkills
Sent: Friday, April 12, 2013 8:58 AM
To:
Subject: 4.2.5.1 update

 

I've updated the gaps cell for 4.2.5.1. NTLMv2 was changed to remove the word "well" and Kerberos was changed to "Resists replay attack".

 

http://www.sans.org/reading_room/whitepapers/testing/crack-pass-hash_33219 is a pretty well-researched reference for hash passing attacks and replay attacks against Windows. Some possible alternative means could be culled from it for the NTLMv2 gap. The most notable/effective mitigation would be the "Restrict NTLM" setting which allows turning off NTLMv2. http://technet.microsoft.com/en-us/library/dd560653(v=ws.10).aspx introduces this topic, with http://technet.microsoft.com/en-us/library/jj865668(v=ws.10).aspx discussing the options first supported by Windows 7 & Windows Server 2008R2. It seems reasonable that you could require that level for DCs, but I might be off base.

 

I'm still running down some details on the Kerberos front around whether my change should be more nuanced.

 

-B