Yesterday news broke of a Microsoft Windows zero-day vulnerability with no workaround. There seems to be no patch available and the vulnerability is found in nearly ubiquitous software. IT security experts commented below.
Allan Liska, Security Solutions Architect at Recorded Future:
“The 64-bit versions of Microsoft Windows 10 and Windows Server 2016 both suffer from a local privilege escalation vulnerability that will allow an attacker who already has access to the system to execute any code as an administrator, in effect giving the attacker full access to the compromised system. The vulnerability exists in an API call for Task Scheduler known as SchRpcSetSecurity. SchRpcSetSecurity does not check for permissions properly when called and will execute code at the administrative level. The Proof of Concept (PoC) code that has been released only works on 64-bit versions of Windows 10 and Windows Server 2016, however the SchRpcSetSecurity API call exists on earlier version of Windows, going back to Windows 2007 and Windows Server 2008, so it is likely the flaw exists on those systems as well.
Unfortunately, this is the not the first time that this type of flaw has been found in Microsoft Windows Task Scheduler service. Similar vulnerabilities have been reported in at least 2004, 2006, 2010, 2014, 2015, and 2016.
At this time there is no patch for the vulnerability, one possible mitigation is to prevent untrusted (usually guest) users from running code. However, if an attacker gains access with user level privilege (e.g. through a browser remote code execution exploit) this mitigation will not work. The best bet until Microsoft releases a patch is to monitor for suspicious activity from Task Scheduler (look for the connhost.exe process) and for this specific PoC monitor for spoolsv.exe (the Print Spooler service) spawning unusual processes, though bear in mind that while the PoC uses the Print Spooler service, this vulnerability is not limited to just the Print Spooler. With some minor tweaking the PoC code could be used to execute other services.”
Sammy Migues, Principal Consultant at Synopsys:
“While the disclosure of this vulnerability and the release of a proof-of-concept exploit add a layer of scandal to this news, it’s a fairly common discovery.
This appears to be a Windows local system privilege escalation bug. A Windows box has some built-in “user” accounts that the OS uses to get various things done. One of those is “LocalSystem” and there are many pieces of software in the Windows OS that run under that account. That account has elevated privileges compared to a “normal” user (e.g., you on your work laptop).
Even if you are a normal user on a Windows box that has this vulnerable software (handling of ALPC in task scheduler), you can exploit the vulnerability to get elevated privileges. So, local users can get extra privileges even when their IT Security folks made them normal users, and anyone else who can run software on that box (e.g., remote attackers tricking the local user) can do the same.
Having a working exploit out in the world makes this easier for everyone. A remote attacker would have to get someone to run their attack code (e.g., in a phishing email), and I’m sure anti-virus vendors are already working on updates to do whatever they can to spot this particular attack.
The CERT vulnerability note (https://www.kb.cert.org/vuls/id/906424) says this is a “local privilege escalation vulnerability” that can allow a “local user” to get elevated privileges. That’s technically accurate. However, some people might read that as “there’s no way a remote attacker can take advantage of this problem.” That’s not accurate. If the local user executes the attacker’s code (e.g., via phishing or downloading some Trojaned software) then, yes, the “local user” did it but the “remote attacker” probably now owns their system.
For me, this is just another of the dozens, if not hundreds, of privilege escalation bugs that have been found on Windows over the years. They get found, they get patched. Life goes on.”
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.