CredSSP: Attacks outlined at SSTIC 2020

[obilodeau]

Outstanding work presented by Thomas Bourguenolle and Geoffrey Bertoli.

Research

• Presentation: https://www.sstic.org/2020/presentation/analyse_de_la_scurit_rdp__nla_quel_apport_pour_votre_scurit_/
• Paper: https://www.sstic.org/media/SSTIC2020/SSTIC-actes/analyse_de_la_scurit_rdp__nla_quel_apport_pour_vot/SSTIC2020-Article-analyse_de_la_scurit_rdp__nla_quel_apport_pour_votre_scurit_-bertoli_bourguenolle.pdf
• PoC: https://github.com/croustibaie/CredSSPY
• Previous work: https://www.sstic.org/media/SSTIC2012/SSTIC-actes/securite_rdp/SSTIC2012-Article-securite_rdp-ebalard_bordes_rigo_2.pdf

Notes

CredSSP protocol selection:

• NTLMSSP is chosen if the client is not joined to a domain or if the client uses a hardcoded IP address to connect
• Kerberos is chosen if the client and the server are joined to the same domain and if the client uses an FQDN to reach the server

Important: under NTLMSSP, the NTLM-Key (a key used for the challenge-response protocol) is located on the server itself for local accounts or on a DC for a domain accounts. Any machine account can obtain this NTLM-Key by forwarding the client information. Ref: video at 7m37s.

The attacks

• NTLMSSP: relay the NTLM to a DC with machine account creds preconfigured then MITM the rest of the connection
• Kerberos: downgrade attack to NTLMSSP (using SPNEGO_RENEGOCIATE) causes a crash and you can obtain a challenge/response NTLMv2. This bypasses "Protected Users" hardening measure (see 13m19s). Only mstsc.exe is vulnerable to this downgrade. This issue will be fixed by Microsoft but not in a hotfix.

Related protocol-level attack

With #229 we implemented a different attack: in this attack we know the server's private key, so we simply pass NTLMSSP messages through the MITM without touching them. This is possible because the rest of the exchange doesn't rely on a secret built as part of the CredSSP exchange but instead once that exchange is done (mutually authenticated), it simply continues with TLS.

The timing of this independent discovery needs to be highlighted here. As @alxbl was implementing this PR, @Romounet told us about the SSTIC presentation.

Further work

• As said at around 9m20s: potential certificate issues are never presented to the end-user before a first NTLMSSP attempt is done meaning that a crackable Net-NTLMv2 can be obtained silently. CredSSPy implements that already. Only mstsc.exe is vulnerable.
• Play more with Kerberos, could we fail other preconditions for a downgrade to NTLMSSP
• Redirection attack to a machine we control (same private key). Explore areas similar to what we were doing before adding NLA support (downgrade + redirection attack). Could we NOP the authentication process easily? Or join it to the domain if we already have a domain user? Potentially very noisy but would it be useful? What about credential stuffing with a machine account? Usefulness in pentests?