Google Project Zero (GPZ) refuses to give Microsoft further extensions when it launches a Windows 10 authentication startup, because it says that a patch provided by Microsoft in the August 2020 Patch Tuesday update is incomplete.
One of the 120 security bugs that Microsoft released patches 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 already has credentials for a Windows account on a network to increase privileges after sending a specially crafted authentication request to the Windows Local Security Authority Subsystem Service (LSASS).
SEE: IoT: Major Threats and Tips for Device Security (Free PDF) (TechRepublic)
While the bug is only reported as Medium Severity by Google and ‘Important’ by Microsoft, LSASS is an important process for users to authenticate when logging in to a Windows PC managed via Active Directory.
LSASS is aimed at advanced hackers who use it to dump references from memory to move laterally on a network. The bug affects all supported versions of Windows 10 up to and including the last release, version 2004.
Google’s refusal to extend the deadline for disclosure in this case appears to be more of a formality, given that it had already published details and a proof of concept under the belief that the Microsoft patch was complete.
Forshaw described the breach as “fixed” on Tuesday, but added a few hours later to the report to say “after assessment it appears that this is not completely fixed”.
GPZ’s disclosure policy for 2020 states: “Details of incomplete fixes will be reported to the supplier and added to the existing report (which may already be public) and will not receive a new deadline.”
According to Forshaw, LSASS does not provide the ‘Enterprise Authentication capability’ properly. This allows any UWP app – whether it’s from the Microsoft Store or a custom enterprise app – packaged 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 that there is an exception to the rule to support organizations that need to install LOB applications when verifying to a network proxy. But there is a problem with this exception, according to Forshaw.
“If the target is a proxy, then the verification process is allowed, even if the [Enterprise Authentication capability] is not specified. The problem is, even if LsapIsTargetProxy returns false, authentication is still allowed to continue, but an additional flag is set to indicate this state. I could not find any code that checked this flag, although it is a bit unclear because it comes from a TLS block, so using tracking is difficult, “Forshaw explained.
“What this means is that an AppContainer can perform network authentication, as long as a valid target name is specified in InitializeSecurityContext, it does not matter if the network address is a registered proxy or not. only a few deliveries without an in-depth detail on how it should behave, maybe it’s by design. “
TO LOOK: Ransomware: These warning signs may indicate that you are already under attack
Since an attacker can specify any target name, they could “authenticate in a network-oriented resource, as long as the application has network access capabilities that are not really restricted”.
“Also because you can provide any target name, and you do the actual verification, server protection such as SPN control and SMB signing is required,” Forshaw added.
Google extended the disclosure deadline for this bug at the end of July, likely to allow Microsoft to release a full patch in its August update.
