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

[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 
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