Windows: Kerberos AppContainer Enterprise Authentication Capability Bypass
Platform: Windows 10 20H2
Class: Elevation of Privilege
Security Boundary: AppContainer
Summary:
Kerberos supports a security buffer to set the target SPN of a ticket bypassing the SPN check in LSASS in LSASS.
Description:
In theory the bugs in LSASS which allowed me to bypass the enterprise capability requirements have been fixed based on report 58548 although no CVE or bulletin was issued for the final fix. However, by default the ability to authenticate to a proxy is still permitted without the enterprise authentication capability.
The security of the capability bypass relies on the target SPN of the authentication passed to LSASS being the same as the one used by the security package that generates the authentication token. For Kerberos the SPN selects the key for the ticket issued by the TGS, it's likely any HTTP proxy will be on a different host to the real target service and so any ticket generated which will pass the proxy check is useless to authenticate to a service.
However, the Kerberos security package supports a couple of additional buffers which can be passed when calling InitializeSecurityContext which affects the SPN. There are SECBUFFER_NEGOTIATION_INFO and SECBUFFER_TARGET_HOST. The first one I can't find well documented, but in both cases the MSDN documentation for Kerberos does not indicate either of them are used.
The ordering of what SPN to use seems to be based on, NEGOTIATION_INFO -> TARGET -> TARGET_HOST. Therefore we can specify a target SPN to InitializeSecurityContext which passes the LSASS proxy check, but which is replaced with the NEGOTATION_INFO one when getting the AP-REQ and Ticket.
You still need to pass the proxy check, but as Kerberos is only used in an enterprise environment where proxies are more common it's possible to use an existing proxy for the SPN as it doesn't matter to the final token.
Fixing wise, perhaps you need to block additional security buffers when doing the initial Kerberos negotiation? I did check NTLM and there was nothing too obvious, at the least I couldn't find anything which would just replace the target name in the authentication packet. You might want to investigate if any other packages have interesting undocumented security buffers.
Proof of Concept:
I've provided a PoC as a C# project. It restarts itself as an AC without the enterprise authentication capability and gets a Kerberos token for an arbitrary SPN. If you don't specify one on the command line then it'll use KrbRestrictedHost/HOSTNAME.
1) Compile the C# project. It will need to grab the NtApiDotNet from NuGet to work.
2) Set a static global HTTP proxy on a domain joined system.
3) Run the PoC.
Expected Result:
The authentication process fails.
Observed Result:
The authentication process succeeds and provides a Kerberos ticket for an arbitrary SPN.
This bug is subject to a 90 day disclosure deadline. After 90 days elapse,
the bug report will become visible to the public. The scheduled disclosure
date is 2021-06-17. Disclosure at an earlier date is also possible if
agreed upon by all parties.
Related CVE Numbers: CVE-2021-31962,CVE-2021-26414.
Found by: forshaw@google.com
Platform: Windows 10 20H2
Class: Elevation of Privilege
Security Boundary: AppContainer
Summary:
Kerberos supports a security buffer to set the target SPN of a ticket bypassing the SPN check in LSASS in LSASS.
Description:
In theory the bugs in LSASS which allowed me to bypass the enterprise capability requirements have been fixed based on report 58548 although no CVE or bulletin was issued for the final fix. However, by default the ability to authenticate to a proxy is still permitted without the enterprise authentication capability.
The security of the capability bypass relies on the target SPN of the authentication passed to LSASS being the same as the one used by the security package that generates the authentication token. For Kerberos the SPN selects the key for the ticket issued by the TGS, it's likely any HTTP proxy will be on a different host to the real target service and so any ticket generated which will pass the proxy check is useless to authenticate to a service.
However, the Kerberos security package supports a couple of additional buffers which can be passed when calling InitializeSecurityContext which affects the SPN. There are SECBUFFER_NEGOTIATION_INFO and SECBUFFER_TARGET_HOST. The first one I can't find well documented, but in both cases the MSDN documentation for Kerberos does not indicate either of them are used.
The ordering of what SPN to use seems to be based on, NEGOTIATION_INFO -> TARGET -> TARGET_HOST. Therefore we can specify a target SPN to InitializeSecurityContext which passes the LSASS proxy check, but which is replaced with the NEGOTATION_INFO one when getting the AP-REQ and Ticket.
You still need to pass the proxy check, but as Kerberos is only used in an enterprise environment where proxies are more common it's possible to use an existing proxy for the SPN as it doesn't matter to the final token.
Fixing wise, perhaps you need to block additional security buffers when doing the initial Kerberos negotiation? I did check NTLM and there was nothing too obvious, at the least I couldn't find anything which would just replace the target name in the authentication packet. You might want to investigate if any other packages have interesting undocumented security buffers.
Proof of Concept:
I've provided a PoC as a C# project. It restarts itself as an AC without the enterprise authentication capability and gets a Kerberos token for an arbitrary SPN. If you don't specify one on the command line then it'll use KrbRestrictedHost/HOSTNAME.
1) Compile the C# project. It will need to grab the NtApiDotNet from NuGet to work.
2) Set a static global HTTP proxy on a domain joined system.
3) Run the PoC.
Expected Result:
The authentication process fails.
Observed Result:
The authentication process succeeds and provides a Kerberos ticket for an arbitrary SPN.
This bug is subject to a 90 day disclosure deadline. After 90 days elapse,
the bug report will become visible to the public. The scheduled disclosure
date is 2021-06-17. Disclosure at an earlier date is also possible if
agreed upon by all parties.
Related CVE Numbers: CVE-2021-31962,CVE-2021-26414.
Found by: forshaw@google.com