The Bug Report – April 2022 Edition

By Trellix · May 4, 2022
This blog was written by Mark Bereza

Your Cybersecurity Comic Relief

Why Am I here?

For those in my hemisphere, springtime is finally here and, like always, it promises change: the flowers are blooming, the birds are chirping, and seasonal allergies are in full swing – it is truly the greatest time of year. Some things, however, remain constant: death, taxes, The Bug Report, and Java ruining your life. We at Trellix are proud to continue bringing you the one thing on that list worth looking forward to, month after month.

This month featured some truly standout vulns, meaning our resident Shadow Council spent little time deliberating which ones would make the cut, giving us ample time to really dig into the ones that did:

• CVE-2022-21449 aka “Psychic Signatures”: Java
• CVE-2022-26809: MSRPC
• CVE-2022-22965 aka “Spring4Shell”: Spring Framework

The more pedantic among you might be thinking, “Well, actually, Spring4Shell was reported in late March, so why is it in April’s Bug Report?” The short answer is that time is a social construct. The long answer is the vulnerability was reported right at the end of March (03/29), meaning by the time it became apparent just how critical it was, it was too late to include it in March’s report. Better late than never!

CVE-2022-21449: Failing, even with a curve

What is it?

It is often said that cryptography is one of the few good things we have in cybersecurity, and for good reason. Unfortunately, cryptography is like a joke in that it’s all about delivery, and even the best cryptographic algorithms can’t prevent errors in implementation. Even more unfortunately, “cryptography is like a joke” is actually a perfect description of Java’s ECDSA implementation. With the release of Java 15, the original native code implementation was rewritten in Java, introducing a major bug that made it trivial to bypass its ECDSA signature validation, according to Neil Madden of ForgeRock. Madden first disclosed the vulnerability to Oracle in November of 2021, but chose not to go public with it until six months later, after Oracle finally addressed the issue in their April 2022 Critical Patch Update (CPU). In his article, Madden dubs the vuln “Psychic Signatures,” after the blank psychic paper used by Doctor Who as an all-purpose ID card – quite fitting.

To fully understand the mechanics of CVE-2022-21449 would require a crash course in elliptic curve cryptography – well beyond the scope of our humble report – so the short version is that an ECDSA signature consists of two values: r and s. Validating an ECDSA signature involves checking that the left and right sides of a particular elliptic curve equation are indeed equal, with the left side being r, and the right side being proportional (kind of) to s. This equation becomes trivially true (0 = 0) if both r and s are zero, so such a signature would always be considered “valid” regardless of the message contents or the key used. To address this, one of the steps in the ECDSA algorithm involves rejecting a signature as invalid if either r or s are zero – a step that Java’s new implementation skipped. 00ps.

Who cares?

ECDSA is like plumbing; we use it all the time, but most people don’t think about it until something goes wrong. The various fixtures powered by Java’s ECDSA plumbing include many popular web authentication/authorization standards such as JWTs, SAML, and WebAuthn, responsible for gating access to sensitive resources on servers and even managing Single Sign-On (SSO) for users across security domains. Perhaps even more troubling, some SSL certificates utilize signatures generated using Java’s ECDSA, in which case an attacker could leverage this vuln to man-in-the-middle encrypted traffic. This is all to say that you shouldn’t let Oracle’s incredibly conservative CVSS rating of 7.5 fool you into thinking this vuln isn’t a big deal. As for which versions are impacted, Oracle has indicated that Java 15, 16, 17, and 18 prior to their April CPU are all vulnerable.

Although the scope of CVE-2022-21449 is certainly smaller than the infamous Log4Shell, it’s worth nothing that Log4Shell was a bug in a third-party Java library, whereas this is a bug in the Java runtime itself. Furthermore, Psychic Signatures is just as easy to exploit and PoC code already exists, meaning that although there is currently no evidence of in-the-wild exploitation, it is far from unlikely. In short, if you cared about Log4Shell, then you should probably care about this, too.

What can I do?

As is often the case, the best thing you can do is patch ASAP, as Oracle’s April CPU fully mitigates this vulnerability. If this isn’t immediately possible, consider switching all your Java Cryptography Architecture (JCA) providers to BouncyCastle, an open-source implementation devoid of this bug. If you’re wondering if your organization is impacted, we suggest dusting off that list you made in the aftermath of Log4Shell for all the software in your environment that so much as looks at Java – there’s bound to be a lot of overlap. Barring that, JFrog has released a tool on GitHub that can scan arbitrary JAR/WAR files for presence of the vulnerability, which may prove useful.

CVE-2022-26809: RPC, it’s easy as 1 2 3

What is it?

CVE-2022-26809 lacks the catchy monikers of our other two entries this month, but don’t take that as a reflection of its import. Publicly disclosed on April 12 as part of Microsoft’s Patch Tuesday, it is a fully remote, pre-authentication, zero-click vulnerability in Microsoft Remote Procedure Call (MSRPC), a core component of the Windows operating system that is enabled by default, network-accessible, and cannot be disabled without breaking things in the OS. I’ll give everyone a second to pick their jaws up off the floor before continuing.

The vulnerability was submitted to Microsoft by Cyber Kunlun, a cybersecurity firm based out of Beijing, who provided Microsoft with an exploit that utilized the Server Message Block (SMB) protocol as the attack vector. As a result, Microsoft initially recommended blocking TCP ports 139 and 445, ports utilized by SMB, in their Microsoft’s Security Update Guide. Although these ports are not specific to MSRPC, leaving them open can still result in exploitation of the vulnerability, as MSRPC can utilize SMB for transport. In theory, the same may hold true for MSRPC over TCP and MSRPC over HTTP.

That being said, there is currently very little credible information to be found regarding the specific details of what is needed to exploit the vulnerability besides some high-level analysis done by Akamai and MalwareTech based on patch diffing. According to both sources, the patch added some integer overflow checks that protect against a potential heap overflow condition in functions responsible for processing RPC packets, presumably the means by which remote code execution would be possible.

Who cares?

Ultimately any org with any Windows footprint in their environment should be taking this very seriously, as exploits leveraging this vulnerability will be easily wormable, making it a prime vehicle for malware campaigns. Microsoft has also indicated that just about every version of Windows since Windows 7/Server 2008 is vulnerable, so don’t expect being a decade behind on your Windows updates to save you – I’m looking at you, healthcare industry.

Thankfully for all the sysadmins and analysts experiencing Vietnam flashbacks right now, there does not (as of this writing) appear to be any legitimate PoC code for CVE-2022-26809, much less any detected exploitation out in the wild, meaning there is still time to lock things down before the bad guys start sending payloads to every one of the 700,000 Windows machines with port 445 exposed to the internet:

I’m sure all 700,000 are fully patched… right?

What can I do?

Like a broken record with a steadfast conscience, I will continue to tell you to patch your systems now. Like, right now. Since disabling RPC outright isn’t feasible, patching and Viking funeral are your only two surefire means of keeping your Windows machines safe. But like a Sex Ed teacher preaching abstinence, I realize that providing alternate means of mitigating risk is equally important. If you can’t patch right this second, a good starting point would be to block TCP ports 135 (MSRPC via TCP), 139 and 445 (MSRPC via SMB), and 593 (MSRPC via HTTP) on your perimeter firewall. Ultimately, however, good firewall rules are founded in whitelisting ports for necessary services, not blacklisting dangerous ones reactively like an unwinnable game of whack-a-mole.

CVE-2022-22965: Mirai botnet springs back to life

What is it?

In order to adequately describe what Spring4Shell is, it’s important to first describe what it is not – it is not CVE-2022-22963, a superficially similar vuln disclosed around the same time that allows for server-side code injection in Spring Cloud Function. In late March, during the first 72 hours of these two vulns going public, there was a lot of misinformation being spread on Twitter due to the conflation of these two vulnerabilities, with many referring to both as “Spring4Shell.” Canonically, however, Spring4Shell refers exclusively to CVE-2022-22965, and though both were granted a CVSS score of 9.8, Spring4Shell proper is far more impactful, hence its inclusion on our list and the omission of its ugly cousin.

With that out of the way, let’s briefly describe what the Spring Framework is, as it’s the target of this particular vulnerability. Put simply, it’s a very popular open-source framework developed by VMware that aids with the development of enterprise-level Java applications by providing support for features such as dependency injection, data binding, and web frameworks for both model-view-controller (Spring MVC) and reactive (Spring WebFlux) designs. One of the features the Spring Framework provides to developers is the ability to map HTTP requests to specific handler methods. These request handler methods, in turn, can instantiate objects and automatically populate their members based on parameters provided via these same HTTP requests, a feature known as parameter binding.

A much older bug, CVE-2010-1622, abused this feature combined with Java’s built-in getClassLoader() method to manipulate Tomcat’s ClassLoader object into loading a JAR file from an attacker-controller server, thereby achieving RCE. Spring quickly patched this attack vector by adding a check that excludes getClassLoader() from the parameter binding mechanism. The introduction of Modules in Java 9, however, added another means of accessing a ClassLoader, thus creating a bypass for Spring’s previous patch and giving birth to CVE-2022-22965. Unlike its ancestor, exploitation of Spring4Shell has largely involved creating a webshell (hence the name) on a target server running Tomcat by writing a custom .jsp file to the web root via Tomcat’s AccessLogValve class, but the underlying vulnerability of abusing request parameter binding is largely identical.

Who cares?

As far as impact goes, there’s good news and there’s bad news. The good news is that not every Java app utilizing Spring Framework is vulnerable by default; for an app to be vulnerable, it must be meet all these criteria:

• Uses JDK >= 9.0
• Packaged as a Web Application Archive (WAR)
• Deployed on a standalone Servlet container
  • The Servlet must have either the spring-webmvc or spring-webflux packages as a dependency
• Uses a version of Spring Framework older than 5.2.20/5.3.18 (where the patch was introduced)

The bad news is that the bad guys have a sizable head start in this race. This is in part due to the details of the vulnerability and even a PoC exploit being leaked in advance of the CVE’s planned publication, which was meant to coincide with Spring’s patch. In fact, honeypots detected exploitation of Spring4Shell as early as March 31, just two days after disclosure, and exploitation attempts have continued ever since. The initial PoC code made public was specific to Spring applications that used Tomcat Servlet containers, but Spring has since confirmed that both Payara and Glassfish Servlets are also vulnerable.

I lied earlier, there’s even worse news. Trend Micro has reported that Spring4Shell is already being utilized in an extensive campaign that, in the spirit of Easter, has resurrected the Mirai botnet malware. Doesn’t it just fill you with nostalgia?

What can I do?

While updating Spring Framework to 5.2.20/5.3.18 or above is obviously the best solution, Spring has also outlined several mitigation strategies in their security guidance:

• Upgrade Tomcat to at least 8.5.78/9.0.62/10.0.20. While this does not mitigate the vulnerability as a whole, it does mitigate the Tomcat attack vector, which is by far the most prevalent way this vuln is being exploited.
• Downgrading Java to a version below 9 removes the Module bypass that makes CVE-2022-22965 possible; however, utilizing a prehistoric version of Java likely carries its own security risks.
• Whitelisting only the parameters you want to allow your users to bind via the setAllowedFields() method is a valid mitigation, as is blacklisting the fields used by exploits via setDisallowedFields(). Unfortunately, setting these fields globally runs the risk of them being overridden locally. To make matters even more complicated, it was discovered that these properties are unintuitively case-sensitive, a quirk that was not clearly documented, leaving holes in many mitigation attempts. The issue is being tracked as CVE-2022-22968 and is fixed in Spring Framework versions 5.2.21 and 5.3.19. But hey, at least they didn’t tell us it was “working as intended.”