Skip to Content.
Sympa Menu

ad-assurance - RE: [AD-Assurance] RE: 4.2.5.1 update

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

RE: [AD-Assurance] RE: 4.2.5.1 update


Chronological Thread 
  • From: Brian Arkills <>
  • To: "" <>
  • Subject: RE: [AD-Assurance] RE: 4.2.5.1 update
  • Date: Mon, 29 Apr 2013 15:24:10 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport07.merit.edu; dkim=neutral (message not signed) header.i=none

I think Jeff is asking about the reverse. Someone has an AD password hash and wants to replay it to get a Shib IdP token.

 

I don't think there's generally an easy way to do that.

 

We've been talking about the possibility of adding a custom extension on our Shib IdP where a Windows logon token could get you a Shib IdP token, but that's mostly a gleam in our eye (although I know our very capable Shib developer is experimenting). If we did do that, it'd likely have implications on our stance on some of these IAP sections.

 

From: [mailto:] On Behalf Of Rank, Mark
Sent: Monday, April 29, 2013 8:02 AM
To:
Subject: RE: [AD-Assurance] RE: 4.2.5.1 update

 

Jeff:

 

I guess I don't understand your question? Are you asking if a compromised Shibboleth based IdP could replay against an AD Verifier, or someone trying a replay of creds against a Shibboleth based IdP on sign on?

 

Please advise,

Mark

 

 

--------------------------------------------------

Mark Rank
Project Manager - Identity & Access Mgt

UCSF Information Technology Services (ITS)
email:

phn:414-331-1476

--------------------------------------------------


From: [] on behalf of Capehart,Jeffrey D []
Sent: Monday, April 29, 2013 7:52 AM
To:
Subject: RE: [AD-Assurance] RE: 4.2.5.1 update

Very good stuff here.  These types of inferences, notes, interpretations, and references help justify and demonstrate compliance with the intent to resist replay attack.

 

At one point, we had considered that if AD wasn’t directly being used as the verifier, then the replay probably wouldn’t help an attacker either figure out the password or be able to establish their own session by replaying a previous authentication.

 

I’m not really sure how Shibboleth works when it talks to AD to authenticate the user.  I may be off base here, but somewhere there is a prompt for USERID and PASSWORD.  If LDAPS is being used to connect to AD for authentication, then is there some way the attacker could get authenticated with Shibboleth by replaying the hash (i.e. the Pass-the-Hash)?  Seems like it would involve writing custom client routines in the browser to be able to use a passed hash if it were even possible.  That is, it doesn’t seem likely to happen “practically”.  However, is Shibboleth sending the password in plaintext, but over the encrypted channel, to the IdP and then used to authenticate to the Verifier?  (That would be different than the typical Kerberos auth which the client would never send the password, but would do a set of cryptographic operations to ensure keys matched.)

 

So, if you are prompted in the browser for Userid/Password, (Shibboleth), is there some method that being already logged in to Windows over the network to AD could cause a browser-based login to automatically happen, or the hash to be replayed to LDAPS so that an attacker would not need to know the plaintext password?  You have to establish your Shibboleth session cookie first and then the “single sign-on” stuff starts working.

 

Ultimately I think we didn’t care so much about taking over the Windows sessions as far as replay goes, so long as the password wasn’t exposed.  This being a way to apply Silver/800-63 only to the InCommon/Shibboleth side and the components of eAuth used with Shibboleth and InCommon, as applied to Active Directory related to protecting the password (encrypting in storage and transmission).

 

Jeff

 

From: [] On Behalf Of Eric Goodman
Sent: Friday, April 26, 2013 7:55 PM
To:
Subject: RE: [AD-Assurance] RE: 4.2.5.1 update

 

Agreed, and thanks for putting that replay issue into clear (well, as clear as this stuff gets) language.

 

--- Eric

 

From: [] On Behalf Of David Walker
Sent: Friday, April 26, 2013 4:28 PM
To:
Subject: Re: [AD-Assurance] RE: 4.2.5.1 update

 

+1

On Fri, 2013-04-26 at 22:41 +0000, Rank, Mark wrote:

 

Brian:

 

I endorse the footnote and your proposal to apply to 4.2.5.1 and 4.2.5.2. Thanks for the heavy lifting...

 

Have a good weekend,

Mark

 

 

--------------------------------------------------

Mark Rank
Project Manager - Identity & Access Mgt

UCSF Information Technology Services (ITS)
email:

phn:414-331-1476

--------------------------------------------------


From: [] on behalf of Brian Arkills []
Sent: Friday, April 26, 2013 3:11 PM
To: ''
Subject: RE: [AD-Assurance] RE: 4.2.5.1 update

 

One other thought I've just had:

 

We probably want to reference this footnote on the related items in 4.2.5.2. It'd require a minor change to the wording, but it'd then be reusable across both. Because this is a combination attack involving both replay and eavesdropper attacks, it applies equally to both sections.

 

Unless someone objects, I'll make that change and apply the footnote to 4.2.5.2 too.

 

From: Brian Arkills
Sent: Friday, April 26, 2013 3:07 PM
To:
Subject: RE: [AD-Assurance] RE: 4.2.5.1 update

 

What I've done in the matrix is put in a determination for NTLMv2 & Kerberos as "Resists replay attacks" with a footnote. The footnote says:

 

For the purposes of analyzing replay attacks, we decided that vulnerability to a combination of multiple attack styles {eavesdropper(passive), replay, man-in-the-middle} did not constitute an IAP gap of this section. However, for both Kerberos and NTLMv2 there are known vulnerabilities that include replay which can be leveraged to establish a session to a network resource. There are mitigations involving good security practice for these combination attacks, with the most relevant to the IAP revolving around security practices involving the domain controllers and domain admins. Practitioners should review the following material to make sure they are familiar with these combination attacks and have taken reasonable steps to mitigate:

<list of all the URLs noted in this thread>

 

If folks disagree with this, we can amend.

 

From: [] On Behalf Of David Walker
Sent: Friday, April 26, 2013 2:02 PM
To:
Subject: Re: [AD-Assurance] RE: 4.2.5.1 update

 

Thanks, Brian.  Here are some thoughts...

First, we need to remember that "resistant" is not the same as "invulnerable."  NTLMv2 clearly resists replay attacks, just not completely.  The standard for resistance in 4.2.5.1 is that, "The authentication process must ensure that it is impractical to achieve successful authentication by recording and replaying a previous authentication message." 

So, how impractical are the potential attacks?  From your references, it looks like Microsoft has issued three patches in the 2008/2009 time  frame that mitigate much of the vulnerability.   I would say that a patched environment passes the "impractical" test.  Fixing the remaining vulnerabilities certainly doesn't seem to have bubbled very high on Microsoft's list (although that might not be the best standard of excellence :-)).

How do others feel about this?  I'm certainly willing to be convinced by others more AD-knowledgeable that it's easy to attack NTLMv2's replay vulnerability.

David

On Fri, 2013-04-26 at 19:22 +0000, Brian Arkills wrote:

Here's some follow-up material on the outstanding action item I had to double-check and provide some research behind the assertion that NTLMv2 doesn't have replay attack vulnerabilities. I find that the assertion is partially true and partially false. Which means we need to determine whether there is additional follow-up in terms of mitigating configuration suggestions or alternative means.

 

http://media.blackhat.com/bh-us-10/presentations/Ochoa_Azubel/BlackHat-USA-2010-Ochoa-Azubel-NTLM-Weak-Nonce-slides.pdf (and http://www.hexale.org/advisories/OCHOA-2010-0209.txt) describes vulnerabilities in the challenge/response process for NTLMv1 and NTLMv2 when used with the SMB protocol. NTLM when used w/o NTLMSSP/extended security has a replay vulnerability because the randomly generated challenge seed is not truly random.

 

http://blogs.technet.com/b/srd/archive/2009/04/14/ntlm-credential-reflection-updates-for-http-clients.aspx?Redirected=true talks a bit about a patch that address the same kind of attack using NTLMv1/v2 via the HTTP protocol, and how Microsoft is generally aware of this style of attack and is actively working to address it.

 

At the abstract level, these describe this vulnerability as a passive/eavesdropper collection of prior challenges (involving the specific client involved) that can lead to the ability to perform a successful replay attack and establishment of a session on that client. This is pretty similar to the Kerberos stuff below in that it is a combination of attack profiles (passive + active) and only results in a compromised session (in this case on the client computer).

 

However ... it appears that the discussion in the above sources is arbitrarily limited, and you can in fact leverage this vulnerability in combination with a "pass the hash" style attack to "relay" credentials to any other network resource that user is permitted to. Sources that discuss this are:

 

http://www.h-online.com/security/news/item/Authentication-under-Windows-A-smouldering-security-problem-1059422.html which talks about the same NTLMv1/v2 vulnerability across many protocols and scenarios.

 

http://www.tarasco.org/security/smbrelay/index.html which implements a relay exploit tool to demonstrate protocol transition. As noted in the "Update" section, this tool was partially limited by MS08-068 (which they likely pre-empted by releasing their tool), but you can still use the session establishment in combination with pass the hash.

 

So ... is NTLMv2 resistant to replay attacks? Kind of hard to say yes or no without a really qualified answer. Yes, it has some replay attack resistance, but that resistance falls over when combined with other attacks.

 

 

From: [] On Behalf Of Brian Arkills
Sent: Friday, April 12, 2013 3:19 PM
To: ''
Subject: [AD-Assurance] RE: 4.2.5.1 update

 

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

 

 


 

 




Archive powered by MHonArc 2.6.16.

Top of Page