Spring4Shell: The Big “Ehh.. Whatever?”

Hi All,

Let’s chat about the vulnerabilities known as “Spring4Shell”, and why I don’t like that name.

“Run down of the risk & method of exploitation

 Just to be clear, we have two bugs here, CVE-2022-22963 & CVE-2022-22965. The later, having been (regretfully IMO) dubbed “Spring4Shell”. My guess is to hype the story/vuln by attempting to tie it to last year’s disaster in Log4j.

CVE-2022-22963: Check out the Spring team’s CVE Report and its own vulnerability assessment. Fortunately, patching against the CVE-2022-22963 bug is easy: if you use the Spring Cloud Function module anywhere in your Spring-based ecosystem, upgrade to version 3.1.7 or 3.2.3, depending on which of the two officially supported branches of Spring Cloud Function you have.

Colton’s non-technical TL;DR: This is a remote code execution (RCE) attack. In a nutshell, an RCE means what it says: someone from somewhere can “trick” your computer into running a script/code/program, without the usual popups/warnings you would expect before executing untrusted code. This bug is in Spring Cloud Function, a component of Spring. It is an optional module inside the Spring ecosystem. By adding a special HTTP header into the Spring Cloud Function, an attacker could have the server execute a program of their choice.

CVE-2022-22965: This vulnerability is found in the Spring Framework product, and the good news is that it, too, has been patched. (Basically, upgrade to Spring Framework 5.2.20 or 5.3.18. (There are two parallel tracks of the product, a 5.2 and a 5.3 flavor; update to the latest release of the variant you’re using.))

“..what messaging we should provide to the rest of the company and our clients?”

  • Patch. Otherwise, barely a noteworthy event.
  • When referencing either or both bugs, I’d include the CVE numbers. The whole idea of CVE bug identifiers is that they are unique, and being semi-randomly assigned strings of digits, doesn’t allow for any confusing linguistic baggage into the discussion. (Can you tell I don’t like the Log4j comparison?)
  • When referring to these bugs, also refer explicitly to Spring Cloud Function or Spring Framework as appropriate. Those are the names of the components you need to update, and the names you will find in VMWare Spring‘s own security advisories, so they add a touch of plain-English clarity rather than sowing extra confusion.

 

My big take away is that, in my professional opinion, we are not dealing with a situation akin to Log4j. Why? The PoC does not work on an out of the box install. It relies on essentially introducing a vulnerability. Some other reasons I have come to this conclusion:

– As of early morning 4/3/22, I haven’t been able to find a single off the shelf application that is exploitable to RCE (other than deliberately vulnerable PoC code).

– I haven’t found any open source webapp projects which are default exploitable.

– I talked to peers at IR firms, they haven’t had any Sping4shell incidents. Have y’all heard anything from anyone yet?

– Spring4shell is less widespread, and harder to exploit.

I’m taken back by the harrowing announcements of this flaw and comparing it to the Log4J debacle (without proof). I, for one, still have PTSD from sitting in a NOC during Christmas trying to patch Log4J.

Hope everyone is having a great weekend. See you all for the next biggie! 😉

more insights

SEC Releases the 2022 Examination Priorities

Cybersecurity remains one of the top compliance risks for financial firms. The SEC underlines the importance of maintaining operational resiliency by focusing on the areas highlighted below, as stated in their 2022 Examination Priorities Report.

Read more >

Pwn’t: Okta

I think it’s worth taking a step back and shining a light on how this occurred again: a third party contractor got popped which lead to access to Okta’s sensitive data. Crappy. Really, really crappy.

Read more >