Why a Forest is the Security Boundary in AD (SID Filtering flaw)

Initially, the domain was seen as the security boundary in Active Directory.
However, following discovery of the SID filtering flaw, this has been changed so that the security boundary is now defined at the forest level.

The SID filtering flaw is this:
A trusting domain does not verify that the trusted domain is authoritative for all of the SIDs in the authorisation data. Therefore, if an attacker can populate SIDHistory with SIDs manually, they could elevate their permissions in any trusting domain, even to the point where they could add the SIDs for a domain admin in a trusting domain into their authorisation data.
Within a forest, the trust arrangements mean that SID filtering is not appropriate.
In order to do this an attacker would have to:

• possess administrative privileges in the trusted domain.
• have enough technical knowledge to modify low level OS functions and data structures: SIDHistory does not come with any programming interfaces that would allow an attacker to populate it manually, even if they have admin rights. Therefore the attacker needs to perform a binary edit of the SIDHistory data structures.

With SID filtering, the DCs in the trusting domain remove all SIDs that are not relative to the trusted domain from any authorisation data received from that domain.

So removing SID filtering is a risky step to take as it extends the security boundary outside of the forest.

Challenge - Response authentication in Windows

Specifically, we're talking about LanMan and NTLM responses.
LanMan is really for pre-NT4 clients but has been included for backwards compatibility since then.

Format for challenge-response authentication

1. Client sends a type 1 (NEGOTIATE_MESSAGE) to server, advertising its capabilities.
2. Server sends type 2 (CHALLENGE_MESSAGE) which includes supported features and the challenge itself.
3. Client replies with type 3 (AUTHENTICATION_MESSAGE) which contains information about the client including domain and user name plus 1 or more responses to the challenge.

LanMan responses

1. The ASCII password is converted to upper case.
2. It is then null padded to 14 bytes.
3. Split into 2 x 7 bytes.
4. These are used to create 2 DES keys.
5. Each of these keys is used to DES-encrypt the constant ASCII string, resulting in 2 x 8 byte ciphertext values. These 2 ciphertext values are concatenated to a 16 byte value. THIS IS THE LM HASH.
6. The 16 byte LM hash is null padded to 21 bytes.
7. This is split into 3 x 7 bytes.
8. These values are then used to create 3 DES keys.
9. Each of these keys is used to DES-encrypt the challenge in the type 2 challenge message. It results in 3 x 8 byte ciphertext values that can be concatenated to form a 24 byte value. THIS IS THE LM RESPONSE.

Weaknesses

• Converted to upper case so all of that complexity is lost.
• If password is 7 characters or fewer, the second value is null, so straight-away half of the LM hash is compromised.
• Not true one-way encryption as password can be obtained from the hash.
• Since LM hashonly changes when password changes, susceptible to pass the hash attacks, where an attacker uses the hash directly to authenticate to a server rather than having to brute force the hashes to obtain the clear text password. This is also true for NTLM authentication. Both NTLM and LM are password equivalent so if you can get the hash from the server you never need to know the actual password.

If the user's password is > 15 characters then the DC will not store the LM hash so the LM response cannot be used to authenticate the user. The LM response is still generated but a 16 byte null value is used as the LM hash in the calculation and then ignored by the server.

NTLM v1

1. Server sends 8 byte challenge.
2. Client uses a shared secret between the client and server, specifically one of the hashes (LM or NT) to return a 24 byte result of this computation.
3. NTLMv1 computations are usually made for both hashes with both 24 byte results sent to the server, unless you configure it not to.
4. Server verifies that the client has computed the correct result. This assumes that they then have possession of the secret and so are authenticated.
5. Both hashes produce 16 byte values.
6. 5 bytes of zeroes appended to them.
7. Separated into 3 x 7 bytes (56 bits). Each of these 56 bit values is used as a key to DES-encrypt teh 64 bit (8 byte) challenge. The 3 encryptions are reunited to form the 24 byte response.

NTLM v2

1. Server sends 8 byte challenge.
2. Client sends 2 x 16 byte response.
3. This response is the HMAC-MD5 hash of the server challenge, a randomly generated client challenge, and a HMAC-MD5 hash of the user's password and other identifying information.
4. The first response is shorter: it's an 8 byte random value for the client challenge. To verify this response the server must receive as part of the response the client challenge. The 8 byte client challenge is appended to the 16 byte response to make a 24 byte package.
5. The second response is a variable length client challenge which includes the current time, an 8 byte random value, domain name and some standard stuff. The response must include a  copy of this client challenge and is therefore of variable length.

NTLM Weaknesses

• As pointed out above, it's susceptible to pass the hash attacks.
• In Feb 2010 several flaws in the Windows implementation of NTLM were proved: one attack included the ability to predict the random numbers/challenges generated by the protocol. These flaws were fixed by MS010-012.

Why Not Just Use Kerberos?

Kerberos relies on a trusted third party. If one is not available (for example where a client is not a member of a domain, local accounts and authentication to an untrusted domain), then NTLM still rules!

Microsoft Secure Desktop

See here http://blogs.msdn.com/b/uac/archive/2006/05/03/589561.aspx for good explanation of how the secure desktop works.