Why am I here?
Welcome back to the Bug Report: Spooky Edition, and we’ve got bugs crawling out of the walls! Of all the months we do this, we’ve found that critical CVEs feel most at home in October – the month heralding All Hallows’ Eve. They’re terrifying, bring promises of late nights, and they might even have your analysts looking like zombies by the end. Be sure to give those poor souls the full-sized candy bars – they’ve earned it.
For those in the audience unfamiliar with our shtick, every month we compile a shortlist of the top vulnerabilities of the month, so that they might whittle away at your last few hours of peaceful sleep.
Appropriately, this month is rich with Spooky Scary Shelletons:
- CVE-2022-41040: Microsoft Exchange SSRF (ProxyNotShell)
- CVE-2022-41082: Microsoft Exchange PowerShell RCE (ProxyNotShell)
- CVE-2022-42889: Apache Common Text RCE (Text4Shell)
BYOVD (Bring Your Own Vulnerable Driver) Mitigations Flaw
CVE-2022-41040, CVE-2022-41082: Exchanging tricks for treats
What is it?
Like candy corn nobody wants, Microsoft Exchange vulnerabilities continue to be tossed in our direction. This month we continue the year-long saga of ProxyLogon, ProxyOracle, and ProxyShell vulnerabilities that have plagued enterprise mail servers and add an additional two CVEs to the growing list. These bug variations are all based around an architectural flaw in Exchange which is basically built-in server-side request forgery (SSRF) by design. Not a good look but everyone is putting on a disguise this month, aren’t they?
CVE-2022-41040 and CVE-2022-41082 were detected in the wild as zero-day exploitation by GTSC Cyber Security on September 29 and are now referred to collectively as ProxyNotShell. This combination of vulnerabilities results in remote code execution (RCE) similar to ProxyShell; however, it requires authentication to the Exchange mail server, access to the Outlook Web Access server application, and for the server to have Exchange PowerShell available, which has reduced the overall impact of these vulnerabilities. Despite these bugs being privately reported to ZDI back in August, Microsoft has not patched them as of this writing.
One element of these attacks is that Exchange must impersonate authentication tokens to access resources on behalf of the connected user. The attacks seen up until this point focus on using user authentication, either by forcing the system account to impersonate the user or requiring an authenticated user in the case of ProxyNotShell.
Who cares?
Any enterprise network deploying Microsoft Exchange should be paying close attention to this series of vulnerabilities. There is active in-the-wild exploitation now just as we have seen in the past for the previous variants. For these unpatched vulnerabilities see the mitigation guidance below.
While talking about ProxyNotShell, I would also like to highlight a related collection of bugs now referred to as ProxyRelay (CVE-2021-33768, CVE-2022-21979, and CVE-2021-26414), which were patched slowly and incrementally over the past year and only discussed in detail this month. This was a collection of three CVEs so far, and according to a blog post by the researcher Orange Tsai who found all of these Exchange vulnerabilities the past year, there is an additional flaw that has yet to be publicly disclosed or fixed by Microsoft. Ongoing exploitation and additional zero-day vulnerabilities in the remediation pipeline mean someone is playing necromancer and controlling a zombie army of mail servers – that’s taking the theatrics a bit too far if you ask me!
The fixes for these “Exchange Proxy” class of bugs have been partially implemented and bypassed by security researchers or guarded by registry keys and disabled by default for extended periods of time. They have also shipped these fixes via Content Updates (CU) instead of patches with security bulletins which is unusual and more likely to be missed by system administrators. Environments deploying multiple Exchange servers should be on the lookout for fixes for the currently undisclosed CVE that has been submitted to Microsoft. I hate to say it, but you’re likely going to have to watch these like you’re looking out for Mike Meyers on Halloween night.
What can I do?
This section is usually the easiest to write – the hardest part is trying to come up with a new way of writing “please patch” for the thousandth time. Not so this time around, as there is (currently) no patch available for these vulnerabilities.
That being said, Microsoft has provided guidance for implementing several mitigations, including an IIS URL Rewrite rule as well as disabling remote PowerShell for non-admins. Details of what to do follow the lengthy list of updates in the guidance. Please implement these mitigations, or risk threat actors creepy crawling all over your network!
To add some treats to this list of tricks, we are happy to report that Trellix customers are already covered through both our Network Security Platform (NSP) and Network Security (NX). Trellix NSP provides coverage for both vulnerabilities as of release 10.9.37.6 via attack ID 0x45298B00, while those using NX are covered for CVE-2022-41082 via the rule “Microsoft Exchange Server CVE-2022-41082 Remote Code Execution.”
CVE-2022-42889: A patch for Apache’s latest Java “4Shell”
What is it?
Sticking with the theme of long series of vulnerabilities with similar branding, we have a new Apache Commons library vulnerability going by the name Text4Shell and being tracked as CVE-2022-42889. Text4Shell is another Java deserialization vulnerability that can lead to RCE, this time in the Apache Commons Text library’s string interpolation functions.
These functions provide an API for converting strings via “Lookup” objects that automatically perform some action on deserialization. Specifically, if the Apache Commons Text StringSubstitutor object is instantiated with default options and used to replace text on a user supplied string, an attacker can leverage the URL, DNS, or SCRIPT property interpolation functionality to execute arbitrary code or leak information about the network.
Who cares?
Java is one of the top 3 most used programming languages and Java deserialization has been one of the top bug classes exploited by attackers since it was discovered in the mid-2000s, so it should come as no surprise that this is an area that needs active and continuous monitoring for vulnerabilities. As if Freddy Kreuger is clicking his blades behind the scenes, Java deserialization vulnerabilities are a nightmare we can’t seem to wake up from.
What can I do?
This vulnerability has been patched in Apache Commons Text version 1.10 which can be retrieved from their website. Unlike razor blades in candy bars, this poses a real threat, so get to patching ASAP.
Fortunately, this API is not used on the scale of Log4j, with the official Maven Repository showing only 2591 projects import Apache Commons Text and the majority of those are not passing unsanitized user-controlled strings to the StringSubstitutor API. That said, businesses that develop Java code should be looking for any use for the Apache Commons Text library versions 1.5 – 1.9 which are known to be vulnerable. Despite our jokes about late nights, Trellix customers can rest a bit easier, as they are covered via NX rule “Apache Commons Text String CVE-2022-42889 RCE.” For those using our Network Security Platform, coverage is also available as a User-Defined Signature (UDS) via attack ID 0x452B8B00, included as part of the November 1st signature set. No need to go door-to-door knocking for these treats.
A ghost says BYOVD
What is it?
For our last subject this month, I want to highlight an ongoing discussion between Microsoft and the security research community regarding a broken mitigation that is now being leveraged by threat actors such as Lazarus in “bring your own vulnerable driver” attacks. Attackers use this method to pivot to kernel after already gaining local access as a way of avoiding detection and maintaining long term control of the system. This issue came to the forefront via Twitter discussions (if such a thing is even possible on Twitter) and a following Ars Technica article this month titled “How a Microsoft blunder opened millions of PCs to potent malware attacks,” which detailed a problem with Microsoft’s advertised security feature that prevents loading of known-vulnerable signed drivers. The problem is that the list of known vulnerable drivers has not been updated since release in 2019 and the existing block list contained as few as two drivers, making for a fairly lonely stage at the security theater.
Meanwhile, Microsoft has asserted this block list would be automatically updated via Windows Update. Without this protection, threat actors have been leveraging outdated vulnerable signed OEM drivers to pivot to the kernel to hide from system monitoring software. In addition to the block list, Windows Defender Attack Surface Reduction (ASR) rule “Block abuse of exploited vulnerable signed drivers” is also reported to be ineffective at preventing the installation of these drivers.
Who cares?
While this issue differs from our typical Bug Report entries in that it constitutes a post-exploitation attack, it is nonetheless important to be aware of in an enterprise context where post-exploitation persistence is a real concern and threat actors like Lazarus are known to target. The block list was not previously disclosed, and Attack Surface Reduction based blocking may not be functioning as advertised, so there was a false sense of security around the level of protection being offered. Turns out that coverage was as useful as a shower curtain against a kitchen knife.
What can I do?
Microsoft has updated their documentation regarding driver block rules. The updates clarify they only intend to ship new rules with major OS updates and not on a continuous basis. They have also said they will ship an updated list to Windows 10 systems soon™. In addition, they have added guidance for enabling driver blocking using Windows Defender Application Control (WDAC) policies which does not require HVCI and may be usable on a wider range of hardware. Administrators can manually download the latest driver block rules and follow Microsoft’s guidance to enable one of the three different methods for blocking drivers. Due to the uncertainty around the functioning of these security controls, I recommend testing your blocking configuration on your network to make sure it works if possible. Fool me once, as they say.
