Microsoft failed to fix LSASS elevation of privilege flaw

Pierluigi Paganini August 13, 2020

Microsoft did not properly address an elevation of privilege flaw (CVE-2020-1509) in the Windows Local Security Authority Subsystem Service (LSASS).

Google Project Zero researcher who discovered the elevation of privilege flaw (CVE-2020-1509) in the Windows Local Security Authority Subsystem Service (LSASS) warn that Microsoft did not properly address it.

“An elevation of privilege vulnerability exists in the Local Security Authority Subsystem Service (LSASS) when an authenticated attacker sends a specially crafted authentication request. A remote attacker who successfully exploited this vulnerability could cause an elevation of privilege on the target system’s LSASS service.” reads the Microsoft’s advisory.

“The security update addresses the vulnerability by changing the way that LSASS handles specially crafted authentication requests.”

An attacker, who has obtained Windows credentials for the local network, could trigger the flaw by sending specially crafted authentication requests.

“LSASS doesn’t correctly enforce the Enterprise Authentication Capability which allows any AppContainer to perform network authentication with the user’s credentials,” Project Zero security researcher James Forshaw explained in a post published in May.

The Google researcher discovered that the issue is related to the original legacy AppContainer capabilities that grants access to Enterprise Authentication

At the time, the researcher explained that the issue is related to a legacy AppContainer capability providing access to the Security Support Provider, and consequently to the SSPI functions. The SSPI interface makes it simple to install line of business (LOB) applications within enterprise environments.

When the target specified in the call is a proxy the authentication should be allowed, anyway Forshaw discovered that the authentication would be allowed even if the network name doesn’t match a registered proxy.

“If the target is a proxy then the authentication process is allowed, even if the Enterprise Auth Cap is not specified. The issue is, even if LsapIsTargetProxy returns false the authentication is still allowed to proceed but an additional flag is set to indicate this state. I couldn’t find any code which checked this flag, although it’s a bit unclear as it comes from a TLS block so tracking down usage is awkward.” continues the expert.

“What this means is that an AppContainer can perform Network Authentication as long as it specifies a valid target name to InitializeSecurityContext, it doesn’t matter if the network address is a registered proxy or not.”

An attacker could exploit the issue to authenticate to resources exposed on the network without restrictions, bypassing SPN checking and SMB signing.

Upon exploiting the flaw, the attacker could also access to the localhost services, albeit with some limitations.

Forshaw also published proof-of-concept (POC) code to achieve elevated privileges through Enterprise Authentication bypass, it will connect to the local SMB server and list the network shares which shouldn’t be something the AC can do.

Microsoft addressed the vulnerability with the release of August 2020 Patch Tuesday, but a few hours late Forshaw discovered that the updates failed to fix the issue.

One day after the fix was released, however, Forshaw revealed that the patch failed to correctly address the vulnerability.

According to Forshaw, the POC he released is still working in case the attacker has added a proxy server in the settings, he also pointed out that the code should be executed with specific arguments.

“After review it seems that this hasn’t been completely fixed. In line with our policy outlined at https://googleprojectzero.blogspot.com/2020/01/policy-and-disclosure-2020-edition.html any incomplete fix is added to the issue tracker as additional information and is not granted an additional time to fix.” reads the update published by the researcher.

“To verify with the original PoC.

1) Run the CheckNetIsolation.exe command as admin to add Calculator to loopback exemption.
2) Add a proxy server manually in the settings. For example set a manual proxy to 192.168.0.10 port 1234.
3) Run the PoC specifying the arguments 127.0.0.1 CIFS/localhost/192.168.0.10.

This will connect to the local SMB server and print the shares. This will work even if SPN verification is enabled as the SMB server ignores the Service Name component of the SPN.”

[adrotate banner=”9″][adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – hacking, LSASS)

[adrotate banner=”5″]

[adrotate banner=”13″]



you might also like

leave a comment