Spring4Shell: Another Vulnerability Showcases Need for More Secure Software Development

This blog was originally published by BlueVoyant here.

In late March, a new remote code execution vulnerability known as Spring4Shell, or sometimes SpringShell, was announced. The vulnerability, tracked as CVE-2022-22965, is in the Spring Framework, a set of prewritten Java code to create software, such as web applications.

Immediately, comparisons were drawn between Spring4Shell and Log4j, a vulnerability in a different Java software library that was revealed last December and had far-reaching effects.

What We Know

On March 30, Spring4Shell was leaked online. The next day, Spring posted a blog confirming the vulnerability and announcing patches to correct the vulnerability.

Since Spring4Shell was announced, organizations have been targeted. In fact, roughly one out of six organizations worldwide that were vulnerable were targeted within the first few days of the vulnerability becoming public.

Microsoft said in early April that it was tracking a low volume of exploit attempts.

On April 4, the Cybersecurity & Infrastructure Security Agency (CISA) added Spring4Shell to its Known Exploited Vulnerabilities Catalog.

The exploitation of the vulnerability took on a few different forms as attackers evolved their techniques. At first, exploitation involved using web shells for initial access that Advanced Persistent Threat (APT) groups could exploit for espionage campaigns. Advanced cybercriminals could also use this as an initial vector for siphoning off data before encrypting system data as part of the double extortion seen in ransomware campaigns. In this type of campaign, besides demanding a ransom for decrypting files, the cybercriminals say they will release files if a ransom is not paid. This vulnerability exploit can also be sold by initial access brokers, who monetize their efforts by demanding compensation for access to organizations’ networks.

Later in April, researchers discovered that Spring4Shell could be used to deliver the Mirai Botnet’s malware on unpatched systems. Mirai is a type of malware that turns networking devices running the Linux operating system into part of a botnet network. It has been a persistent threat since at least 2016, despite arrests of the original architects. Botnets are often used like this for various nefarious reasons or to grow the criminals' reach.

Most recent, cybersecurity researchers have observed the Spring4Shell vulnerability being used to install cryptominers. This is a less malicious threat as the attacker’s goal is to steal resources to mine for cryptocurrency.

The Silver Lining

The silver lining is that Spring4Shell’s severity may have been originally overstated. According to BlueVoyant’s threat research, it will likely have a more limited impact than the forecast by some cybersecurity researchers.

Unlike Log4j, Spring4Shell only impacts systems with particular configurations.

Depending on how Spring is used, it may be possible to exploit the flaw without authentication; however, there are many prerequisites for the vulnerability to have an effect. In addition, if the application is using Spring’s default configuration, it is not exploitable, according to Spring and Carnegie Mellon University’s CERT Coordination Center.

How to Protect Yourself

The best advice is to look for any affected versions of Spring and patch them right away. There is a publicly-available scanning tool on Github that can be used to find vulnerable Spring instances. If patching is not possible, there are workarounds.

Be aware of any third parties your organization relies on. Even if you patch your own systems, if someone in your supply chain is not patched, you could be vulnerable.

You can also regularly check the Spring blog for updates.

Lessons for the Future

Both Spring4Shell and Log4j call into question how developers use software libraries and raise awareness of the need for stronger secure software development practices, especially in open source communities.

Going forward, the industry needs to better check open source software used in production environments to reduce the risk of such vulnerabilities. Awareness of potential vulnerabilities in these libraries continues to improve, but more work is needed.

Additionally, by focusing on your interconnected supply chain, your organization can identify third parties that may bring vulnerabilities such as Spring4Shell or Log4j into your ecosystem.