TLDR: Originally this was written as a low priority issue, however after further discussions internally we are upping the risk due to the fact that IE 11 is installed on every Windows computer and cannot be removed (as it is an OS component), and the fact that there still remains the risk of attack via social engineering, which could get around many of the originally proposed mitigations.
Originally I wrote this as a low priority issue, however after looking into it more I’m upping the risk on this as IE 11 is installed by default on every Windows system and it cannot be removed, which means that with some social engineering, its possible to compromise any Windows user’s computer. Above all else this factor should be kept in mind as it means that even if an organization doesn’t have IE set as its default, all it takes is a user who is convinced that to download some info they require they need to use IE instead of Firefox, and a malicious website, and attackers will start to have a foothold within the network.
Now what are some of the limiting factors here? Well you can’t uninstall IE, as it is integrated into every Windows operating system and is considered an OS component. This explains the point above as to why this vulnerability really does affect pretty much every single Windows user. However if organizations implement policies or protections that block IE from being run, then users will not be able to open IE and therefore trigger the vulnerability.
The other point to note is that according to https://gs.statcounter.com/browser-market-share, only 1.28% of people use IE these days, compared to 65.89% of people that use Chrome. The closest competitor there is Safari at a little over 16%. This means that this vulnerability is likely to be more of a risk to enterprises where IE use is more likely due to the prevalence of legacy systems and software, and is unlikely to affect the average home user.
However, keep in mind that particularly in the government space, there are many organizations that still use IE by default or which require users to interact with their legacy applications using IE (due to compatibility issues or similar). These organizations need to patch this issue as soon as possible as all it takes to exploit this issue is one user browsing to a site with a malicious advertisement or one user clicking a link in a malicious email for that user to be compromised.
For those that are not using IE by default this issue will be slightly less of a risk due to the need for attackers to conduct social engineering attacks against end users to convince them to load a malicious site in IE, however remember that all it takes is one user clicking on a link for attackers to start gaining a deeper foothold into your network. Even if the social engineering attack only nets a 10% success rate, if your targeting an organization of 1000 users, that’s 100 users that are now compromised, all of which could provide an attacker with unique possibilities to escalate their privileges within your network.
The advisory suggests that an unauthenticated attacker, presumably already on a domain-joined host, can connect to a DC over NRPC and escalate to DA. That’s pretty significant, but we have no additional details to go by, short of looking at the patch.
Notably, the patch is partial, and the second phase won’t be rolled out until Q1 2021. If attackers can figure out how to weaponize this, it could be a valuable escalation path to DA.
A vulnerability exists within Windows that can allow file signature validation to be bypassed. This would allow an attacker to load and execute PE files without having signed them, possibly masquerading as a legitimate signature. This would be useful if the system the attacker is on requires signatures for all files or if the attacker wanted to load a library into a process where signatures are enforced.
This would not grant elevated privileges without being combined with an additional primitive.
While this is being actively exploited in the wild, at this time there are few public details on the vulnerability.
CVE-2020-1337 is a bypass of (PrintDemon) CVE-2020-1048’s patch via a Junction Directory, made to remediate an Elevation of Privileges (EoP)\Local Privilege Escalation (LPE) vulnerability affecting the Windows’ Print Spooler Service. The vulnerability does require low privilege access and for the spooler service to restart.
The patch appeared in Microsoft’s patch Tuesday (11th August 2020) – https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-1337#ID0EWIAC.
Vulnerability description, root cause analysis and PoC code on https://voidsec.com/cve-2020-1337-printdemon-is-dead-long-live-printdemon/
This is a print spooler vulnerability similar to CVE-2020-1048, but it uses a specially-crafted *.SHD to trigger a print to a trusted location. Introduced at Blackhat on August 6, 2020, a patch is expected to appear next week in Microsoft’s patch Tuesday.
The vulnerability does require low privilege access and for the spooler service to restart.
PoC will be uploaded to https://github.com/SafeBreach-Labs/spooler on August 12.
This is extremely valuable to attackers. The exploit is most likely present on all versions of Windows from Windows 7 to present and the race is now on to patch it while PoCs are already in the wild.
This is a dll hijack against Phillips SmartControl software that provides a privilege escalation. It requires an attacker to place a dll payload in a location writable to low-privilege user and having the user restart the application (or wait for a reboot). This would likely also be a good method for elevated persistence. As the software is likely not present in many enterprise settings and it requires user interaction or reboot, I think this has lower attacker value, but it would be very useful under those limited circumstances.
Mitigations might be as simple as creating dummy DLL files in the four locations created as SYSTEM or Administrator, preventing the attacker from a trivial low-privileges overwrite, adding the file locations to HIDS, or patching the software in question to something above 4.3.15
There is a vulnerability in Teamviewer that will attempt to access a remote SMB site when a user visits a malicious website. Part of a smb handshake involves the exchange of credentials. The SMB handshake would contain the username and hashed password of the user. Attackers could redirect the connection with something like responder and/or store the hash for later cracking.
Affected versions are 8 -15.8.2; 15.8.3 is the first patched version. Administrators should patch immediately of attempt to disable SMB connections from local networks if possible.