Microsoft failed to properly address an elevation of privilege vulnerability in the Windows Local Security Authority Subsystem Service (LSASS), the Google Project Zero researcher who discovered the issue says.
Microsoft failed to properly address an elevation of privilege vulnerability in the Windows Local Security Authority Subsystem Service (LSASS), the Google Project Zero researcher who discovered the issue says.
Tracked as CVE-2020-1509, the vulnerability can be triggered through specially crafted authentication requests. For successful exploitation, an attacker needs previously obtained Windows credentials for the local network.
“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 noted in May.
At the time, the researcher explained that the issue is related to a legacy AppContainer capability providing access to the Security Support Provider Interface (SSPI), likely meant to facilitate the installation of line of business (LOB) applications within enterprise environments.
Authentication should be allowed only if the target specified in the call is a proxy, but Forshaw discovered that the authentication would be allowed even if the network name doesn’t match a registered proxy.
“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,” the researcher explains.
This means that an attacker could authenticate to network-facing resources without restrictions, rendering protections such as SPN checking and SMB signing useless. By exploiting the flaw, an attacker could access localhost services as well, albeit with some caveats.
Forshaw also published proof-of-concept (POC) code to demonstrate how an application can achieve elevated privileges through Enterprise Authentication bypass. The code seeks to list SMB shares, although it should not be allowed to.
Microsoft, which rates the vulnerability as important, released a fix for supported versions of Windows and Windows Server on August 2020 Patch Tuesday.
One day after the fix was released, however, Forshaw revealed that the patch failed to correctly address the vulnerability. An attack could still be mounted, as long as a configured proxy is present on the system.
“However in enterprise environments that's likely a given and there this issue is the most serious,” the security researcher notes.
Forshaw also explains that the POC for the original bug can still be used, but that a proxy server needs to be manually added in the settings and the code should be executed with specific arguments.
“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,” he concludes.
Related: Microsoft Patches Actively Exploited Windows, IE Vulnerabilities
Related: Windows and IE Zero-Day Vulnerabilities Chained in 'PowerFall' Attacks
Related: Citrix Expects Hackers to Exploit Newly Patched XenMobile Vulnerabilities
Tags: