Google Project Zero (GPZ) is refusing to give Microsoft further extensions on disclosing a Windows 10 authentication bug because it says a patch Microsoft delivered in the August 2020 Patch Tuesday update is incomplete.
One of the 120 security bugs Microsoft released patches for on Tuesday was CVE-2020-1509, which was reported to Microsoft on May 5 by GPZ Windows researcher James Forshaw.
The bug allows a remote attacker who’s already gained credentials for a Windows account on a network to elevate privileges after sending a specially crafted authentication request to the Windows Local Security Authority Subsystem Service (LSASS).
SEE: IoT: Major threats and security tips for devices (free PDF) (TechRepublic)
While the bug is only rated as medium severity by Google and ‘important’ by Microsoft, LSASS is a key process for authenticating users when they log on to a Windows PC managed via Active Directory.
LSASS has been targeted by advanced hackers who use it to dump credentials from memory to move laterally on a network. The bug affects all supported versions of Windows 10 through to the latest release, version 2004.
Google’s refusal to extend the disclosure deadline in this case appears to be more a formality, given it had already published details and a proof of concept under the belief that Microsoft’s patch was complete.
Forshaw listed the bug as ‘fixed’ on Tuesday but then added to the report a few hours later to say “after review it seems that this hasn’t been completely fixed”.
GPZ’s 2020 disclosure policy states: “Details of incomplete fixes will be reported to the vendor and added to the existing report (which may already be public) and will not receive a new deadline.”
According to Forshaw, LSASS doesn’t properly enforce the ‘Enterprise Authentication capability’. This allows any UWP app – whether it’s from the Microsoft Store or a custom enterprise app – that’s wrapped in the Windows AppContainer sandbox to perform network authentication with the user’s credentials via single sign-on.
Microsoft’s documentation of the feature suggests there is an exception to the rule to support organizations that need to install line of business (LOB) applications if they authenticate to a network proxy. But there’s a problem with this exception, according to Forshaw.
“If the target is a proxy then the authentication process is allowed, even if the [Enterprise Authentication capability] 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,” explained Forshaw.
“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. This is probably not by design, but then this behavior only warrants a few throw-away comments with no in-depth detail on how it’s supposed to behave, maybe it is by design.”
SEE: Ransomware: These warning signs could mean you are already under attack
Since an attacker can specify any target name they could “authenticate to a network-facing resource as long as the application has network access capabilities which aren’t really restricted”.
“Also, as you can specify any target name, and you’re doing the actual authentication, then server protections such as SPN checking and SMB Signing are moot,” added Forshaw.
Google extended the disclosure deadline for this bug at the end of July, presumably to give Microsoft to release a complete patch in its August update.
