Google's Project Zero team is quite well-known for discovering vulnerabilities in the software developed by the company itself as well as those built by other firms. Its methodology involves identifying security flaws in software and privately reporting them to vendors, giving them 90 days to fix them before public disclosure. Depending upon the complexity of the fix required, it sometimes also offers additional days in the form of a grace period.
Over the past couple of years, the team has revealed major vulnerabilities in Windows 10 S, macOS kernel, and iOS, among others. Now, it has disclosed a "medium" severity flaw in various versions of Windows following what it claims to be an incomplete fix offered by Microsoft in yesterday's Patch Tuesday update.
The flaw which was first reported to Microsoft on May 5, 2020 allows apps to bypass network authentication via a user's credentials even when they don't have that capability.
While Google's summary of the vulnerability is full of technical jargon (and you're free to read it in-depth here), the main issue is that the legacy Windows AppContainer grants access to Enterprise Authentication via single sign-on, which is a restricted capability providing access to sensitive functions. As such, this isn't automatically approved for Windows Store apps and is primarily used in side-loaded enterprise applications.
Although this isn't a flaw by itself, the problem occurs when UWP networking incorrectly makes an exception when an application is authenticating to a network proxy. Google Project Zero's security researcher James Forshaw states that:
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.
The result, as you can specify any Target Name you like you 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.
Forshaw explains that theoretically, a local attacker can utilize this by using Classic Edge to access localhost services due to the backdoor in Firewall APIs, and then finding a system service to escape.
Interestingly, this is only one portion of the flaw. Forshaw claims that even if Microsoft's code which handles the network address not being a proxy was correct, it could still be bypassed because it calls "DsCrackSpn2" to resolve network target names of the form Service Class/Instance:port/Service Name into individual components, but apparently even this isn't being done correctly.
A proof-of-concept (PoC) code has also been attached to show how an application could bypass Enterprise Authentication to achieve elevated privileges. The PoC attempts to list the shares of the Windows Server Message Block (SMB) and even though the OS shouldn't allow this access, the local shares are still listed.
Google Project Zero gave Microsoft the standard 90-days deadline to fix this vulnerability and also offered a grace period on July 31 so that the company could roll out the fix in August's Patch Tuesday. While Microsoft did indeed release the fix in its CVE-2020-1509 yesterday and credit James Forshaw for discovering it, the Project Zero team claims that it is an incomplete fix since it does not rectify the DsCrackSpn2 target name resolving technique. As such, Google has now publicly revealed the flaw in accordance with its policies.
While it appears that the security flaw is complex enough to not be exploited by your average script kiddie, elevation of privilege - even if local - can be dangerous. According to Microsoft's security advisory, this problem impacts numerous versions of Windows, including Windows Server 2012, 2016, 2019, Windows RT 8.1, 8.1, and Windows 10 all the way up to version 2004.
5 Comments - Add comment