[squid-dev] [PATCH] Reuse reserved Negotiate and NTLM helpers after an idle timeout.

[Christos Tsantilas]

Στις 05/08/2017 09:52 πμ, ο Amos Jeffries έγραψε:
> On 01/08/17 04:40, Alex Rousskov wrote:
>> On 07/31/2017 09:24 AM, Amos Jeffries wrote:
>>
>>>>> To do so otherwise would randomly
>>>>> allow replay attacks to succeed
>>
>> Please give a specific example where the proposed changes would allow a
>> new kind of replay attacks to succeed, given a correctly functioning
>> Squid and a correctly functioning helper. I cannot think of any
>> realistic examples, but this is not my area of expertise.
>>
> 
> 
> In NTLM the TT (type-2) tokens are generated by a particular helper and 
> only that helper can authenticate the corresponding KK (type-3) token.
> 
> Annoyingly NTLM does not authenticate the client, nor the HTTP message 
> it is attached to - it is specifically (and only) authenticating that 
> the TCP connection is being used by the specific end-client able to 
> generate the KK token proof-of-identity.
> 
> 
> With the current code reserved helpers are tied to a particular TCP 
> connection through Auth::UserRequest. As such an attacker would have to 
> inject replay attempts into the same TCP connection the client was 
> using. Which is protected by the TCP SEQNO mechanism - not impossible to 
> subvert, but a high difficulty level.
>   Any attempt to send the KK on another TCP connection would reach a 
> different helper and be rejected as a 'secret' value embedded in the TT 
> was reserved by the originating helper >
> 
> With the proposed changes all an attacker needs to do is peek at the KK 
> token from the client then race it to be the first one to deliver any 
> token to the originating helper (which can succeed at or after reuse 
> timeout) - using as many other TCP connections as it likes. Which is a 
> MUCH easier thing to do than SEQNO subverting. >
> As far as the TT generating helper is concerned there is no difference 
> between an attackers KK token after timeout, or Squid just waiting some 
> period timeout+N until the real clients KK token arrived.
> 
> And as I mentioned earlier there are other things the attacker can do to 
> slow traffic down and bias the race towards itself. Those things do not 
> have any effect on the client TCP connection use of SEQNO - so are 
> relatively benign with the current code.
> 
> 
> Note that under the attack conditions the TT generating helper *does 
> not* receive a fresh YR query which it might use to reset its 

If I am not wrong this is prevented by ntlm/UserRequest.cc code.

The ntlm/* code for each new connection:
    1) expects a type1 message in Authorization header (and send a YR 
request to helper)
    2) sends back to the client a type2 message in WWW-Authenticate header
    3) expects a type3 message in Authorization header (and send a KK 
request to helper)

If squid did not receive with that order the authentication info from 
the client will just reject/deny the connection.

The ntlm helpers designed to be idiots. They expect a YR and then a KK. 
Every new YR resets their state.
They are not responsible to check for more and must not do it.

Squid code is responsible for this, and I believe this patch does not 
break anything in this area: Any expired reservation results to close 
client connection.
A any new connection still have to repeat the 3  NTLM authentication 
steps to authenticate.

Am I missing something?

> reservation state. The victim client generates the YR, then after 
> timeout the attacker supplies the KK. The TT goes out on one TCP 
> connection, and the KK returns via a different one.
> 
> 
> PS. also note that this is only an issue for NTLM. However the existence 
> of Negotiate/NTLM flavour of Negotiate makes that interface hit the same 
> problem at times. This whole reservation thing is irrelevant with Kerberos.
> 
> 
> Amos
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev