Why am I here?
Why do all the most critical vulnerabilities always have to come out on holidays? Just like clockwork, CVE-2022-26134 came out over the U.S.’ Memorial Day weekend as most of us were trying to get away from technology for a change. Bugs like this always bring us back early. But enough complaining about ruined vacations—let’s get into the worst coolest bugs of this month! The winners are:
- CVE-2022-26134 – OGNL injection vulnerability in Atlassian Confluence
- CVE-2022-30190 – Zero Click Microsoft Support Diagnostic Tool Vulnerability: “Follina”
- CVE-2022-22980 – SpEL injection via parameter placeholder expressions
CVE-2022-26134: ${ return this.JavaVuln++; }
What is it?
At its core, CVE-2022-26134 is an unauthenticated command injection directly into a Java interpreter. More specifically this vulnerability is through Java’s Object-Graph Navigation Language (OGNL) Expression Language. While most bugs require lengthy explanations and technical walk-throughs, this vulnerability is easier to understand by looking at the exploitation payload first.
For those that cannot read ASCII hex fluently:
See!? The exploit request is easier than knowing what OGNL is.
But we must give the nerds like myself some technical satisfaction on how this bug works and why it is so simple. In short, the user supplied URI eventually trickles down to an OGNL expression evaluator which attempts to resolve any variables in the URI, which in turn can be used to execute Java code.
It is important to also point out that this vulnerability is unauthenticated and will execute with the privileges of the Confluence server… which is definitely not root, right?
Who cares?
Because this is such a simple vulnerability to exploit, there are already a huge number of POCs available on the web. Heck, there is even one in this report. This vulnerability has and will be actively used in the wild and Confluence still uses the arcane method of manual updates (yuck)! So, with many unpatched systems still out in the wild, I expect to see exploit attempts targeting CVE-2022-26134 long into the future.
From a quick Shodan search there are about 13k publicly available Confluence servers and with many Confluence users being businesses the impact of this vulnerability is nothing to shake a stick at.
What can I do?
Patching is your best defense and details are available here. If a full Confluence server update is out of the question, you can manually patch the vulnerable “.jar” files by downloading them here and overwriting them in the Confluence install directory. But please if you are going to be overwriting install files have a backup. If you don’t even know where your confluence server is, flagging/blocking any URI that contains the characters “${“ may also prove useful. As a Trellix customer you’re already protected as we already have multiple network signatures baked into our Network Security platform.
CVE-2022-30190: Shoot! There is trouble in Microsoft Office’s troubleshooter
What is it?
CVE-2022-30190, nicknamed “Follina,” was first discovered out in the wild from an upload to VirusTotal. Through this VirusTotal upload, combined with the Twitter post shown below, the world was made aware of this true zero-day.
By using Microsoft Word’s remote template functionality, a maliciously crafted document can be used to resolve the “ms-mdt:/” portion of the remote URL via Windows custom protocol handler. After it is resolved, the URL is passed directly to Microsoft Support Diagnostic Tool (msdt.exe). The vulnerability lies within the MSDT tool’s “IT-BrowseForFile” argument as is parsed by PowerShell. This means that anything you could normally do via PowerShell could also take place via this bug through the “IT-BrowseForFile” parameter.
Who cares?
In short, this vulnerability affects all versions of the Office 365 and has been shown to also work in the standalone Office suites from 2013 all the way through Office 2021, even with macros disabled! It has been determined that Office “protected view” will prevent the Follina vulnerability unless the document has been converted to a Rich Text Format (RTF) document. So, still be weary of unknown files until you are fully patched.
It is worth mentioning that this was a true zero-day and active exploitation has been observed in the wild, with many ransomware gangs trying to use this vulnerability for a quick win. Obviously Trellix is actively watching this bug and more information can be found here.
What can I do?
The best plan of action to protect against this attack in your environment is to apply the official patch released by Microsoft here. Can’t patch? Trellix has your back with protection build into our products! Check out this knowledge base article for more details. Lastly if all else fails following this official workaround will protect against the Follina bug:
- Run Command Prompt as Administrator.
- To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOT\ms-msdt filename“
- Execute the command “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”.
The workaround above will prevent the resolution of any “ms-msdt:/” URLs.
CVE-2022-22980: Spring4shell resurrected?
What is it?
CVE-2022-22980 is the latest vulnerability in the Spring framework eerily similar to the Spring4Shell vulnerabilities publicly released early this year. This vulnerability, just like Spring4Shell, takes advantage of Spring Expression Language (SpEL) injection to execute code on the remote host. The abused SpEL functions for this vulnerability are through the “@Query” and “@Aggregation-annotated” query methods. These methods are only vulnerable when user supplied data is not sanitized before being bound via query parameter placeholders. For the SpEL lay-persons out there (myself included) the query parameter placeholders are presented this way “o.owner.id = ?#{ some-expression }” instead of a static parameter accessed in this manner “o.owener.id = [1]”. More details on parameter placeholder expressions can be seen in more detail here. So, how is it exploited? you may be wondering? Well, if a placeholder consumes user input directly without sanitization, this bug could be exploited by passing in Java code directly as shown in a POC below.
Who cares?
If you were affected by the Spring4Shell vulnerabilities earlier this year, then you probably should care about this CVE as well. It seems like finding all the Java machines to patch is starting to become a monthly ritual.
More specifically if you are running an application that utilizes Spring Data MongoDB V3.4.0 or V3.3.0-V3.3.4, you are likely vulnerable.
What can I do?
Not to beat a dead horse, but the first step would be to patch to the latest version of Spring Data MongoDB to either 3.4.1+ or 3.3.5+. If patching is not a viable solution in your environment, one could secure themselves by using static parameter references “[1]” instead of the “?1” and sanitizing user-supplied input before the query method. The last mitigation would be to “Reconfigure the repository factory bean through a BeanPostProcessor with a limited QueryMethodEvaluationContextProvider“. While the last mitigation was pulled directly from VMWares security disclosure page and I am sure it will mean something to someone, I do not know what a “factory bean” is. Sounds tasty though.
