Following the news that a new zero-day vulnerability in the Spring Core Java framework called ‘Spring4Shell’ has been publicly disclosed, please see below comments from security experts.

Experts Comments

April 01, 2022
Gary Robinson
CSO
Uleska

The good news (so far) is that this bug does not seem to be anywhere near as prevalent as Log4Shell.  While SpringCore is a very popular library among the Java community, a vulnerable system would need to be using some non-default usage or configuration of SpringCore.  There is also (so far) no evidence of widespread attempted exploit of the vulnerability.

Having said that, if a system is vulnerable, this exploit allows remote code execution, which is as bad as it gets in the vulnerability

.....Read More

The good news (so far) is that this bug does not seem to be anywhere near as prevalent as Log4Shell.  While SpringCore is a very popular library among the Java community, a vulnerable system would need to be using some non-default usage or configuration of SpringCore.  There is also (so far) no evidence of widespread attempted exploit of the vulnerability.

Having said that, if a system is vulnerable, this exploit allows remote code execution, which is as bad as it gets in the vulnerability world.

The bad news is, however, that security teams across the world are going to be doing a lot of work intricate technical work to check their systems are not vulnerable.  Those simple questions of ‘Are we using the non-default configuration that’s vulnerable?’ and ‘If we are, can we check if the exploit works?’ means the loss of weekends for security teams, and pushes other vital security tasks aside.  

Our industry has a problem here, due to the increasing frequency of these potentially sever 0-days, where security teams are going to be constantly playing defence and reacting to potential exploits, instead of proactively securing their businesses.  We need to find a better way.

  Read Less
April 01, 2022
Sam Curry
Chief Security Officer
Cybereason

With some early reports surfacing that Spring4Shell is significantly different from Log4j, we’ll know more as an industry soon enough on its severity and risk level. Regardless of what level of severity Spring4Shell poses, the recent Log4j vulnerability was the tip of the iceberg as we're now seeing the looming shape and outline of what is below the waterline. More embedded system weaknesses are lurking out there. Sadly, we live in an age where adversaries have the skills to quickly exploit

.....Read More

With some early reports surfacing that Spring4Shell is significantly different from Log4j, we’ll know more as an industry soon enough on its severity and risk level. Regardless of what level of severity Spring4Shell poses, the recent Log4j vulnerability was the tip of the iceberg as we're now seeing the looming shape and outline of what is below the waterline. More embedded system weaknesses are lurking out there. Sadly, we live in an age where adversaries have the skills to quickly exploit these vulnerabilities. Now the call is out for Defenders to adapt, innovate faster and thrive. Spring4 Shell is another wake-up call, but there will be more vulnerabilities coming next month and beyond. As security practitioners, we need to collectively work on new ways of managing supply chain risk.

  Read Less
April 01, 2022
Jonathan Knudsen
Senior Security Strategist
Synopsys

The Internet is buzzing with talk about two separate vulnerabilities related to different Spring projects. The two are not related, but have been confused because both vulnerabilities were disclosed at nearly the same time.  

The first is CVE-2022-22963, tracked in the Black Duck Knowledgebase as BDSA-2022-0850. This is a remote code execution vulnerability in Spring Cloud Function. Issued with a medium severity by vendor VMWare (https://tanzu.vmware.com/security/cve-2022-22963) researchers have

.....Read More

The Internet is buzzing with talk about two separate vulnerabilities related to different Spring projects. The two are not related, but have been confused because both vulnerabilities were disclosed at nearly the same time.  

The first is CVE-2022-22963, tracked in the Black Duck Knowledgebase as BDSA-2022-0850. This is a remote code execution vulnerability in Spring Cloud Function. Issued with a medium severity by vendor VMWare (https://tanzu.vmware.com/security/cve-2022-22963) researchers have since found that achieving remote code execution is possible. An upgrade patch already exists, so affected users are urged to upgrade as soon as possible.  

For the second vulnerability, a CVE identifier has not been assigned yet. This is the vulnerability many security researchers have been calling Spring4Shell. Under certain circumstances, it allows an attacker to run arbitrary code, but the ease of exploitation varies with how the code running on Spring Boot is written, and how Spring Boot is run.  

Regardless of how Spring4Shell evolves, these two vulnerabilities highlight the importance of knowing what open source components you are using and keeping on top of vulnerabilities as they are disclosed. Software Composition Analysis (SCA) solutions do exactly this. They can produce a software bill of materials (SBOM) for an application and proactively notify you when new vulnerabilities are disclosed in components you have used.

  Read Less
April 01, 2022
Travis Biehn
Technical Strategist
Synopsys

Vulnerabilities impacting two separate spring projects have made the rounds on twitter and vendor blogs today - both of them are high impact remote execution vulnerabilities with many public examples of exploit code.

CVE-2022-22963, which was disclosed by VMWare (https://tanzu.vmware.com/security/cve-2022-22963), impacts Spring Cloud Function and was given a severity rating of 'medium.' The disclosure vaguely mentions that attackers can gain access to local resources. While that may technically

.....Read More

Vulnerabilities impacting two separate spring projects have made the rounds on twitter and vendor blogs today - both of them are high impact remote execution vulnerabilities with many public examples of exploit code.

CVE-2022-22963, which was disclosed by VMWare (https://tanzu.vmware.com/security/cve-2022-22963), impacts Spring Cloud Function and was given a severity rating of 'medium.' The disclosure vaguely mentions that attackers can gain access to local resources. While that may technically be accurate, many are arguing that the severity is understated as it could allow remote code execution. This is a must-update-to-patch-and-fix vulnerability. Fortunately, there's a fix available today.

Much more nebulous is a second vulnerability in the more popular Spring Core which, among many other factors, has been recently confirmed as a remote code execution vulnerability without any available patch. Spring4Shell was initially derided by many in the security industry as 'fake news' or 'a misunderstanding' of commits. These earlier dismissals have been proven wrong, as multiple independent security researchers have stepped up to say that the bug is real and it is exploitable. Combined with early confident dis-information, there is no patch for this vulnerability. When fixes are made available, will decision makers remember Spring4Shell as fake news or a real problem?

CVE-2022-22963 is what happens when responsible disclosure is followed, a vendor can minimize the importance of a vulnerability, making it harder to act on. Spring4Shell is what happens when responsible disclosure processes aren't followed - the lack of immediate and fully vetted credible information in a sea of strong personalities makes an already hard job seem impossible.

Jonathan Knudsen, Head of Global Research at the Synopsys Cybersecurity Research Center (CyRC), added “The Internet is buzzing with talk about two separate vulnerabilities related to different Spring projects. The two are not related, but have been confused because both vulnerabilities were disclosed at nearly the same time.  

The first is CVE-2022-22963, tracked in the Black Duck Knowledgebase as BDSA-2022-0850. This is a remote code execution vulnerability in Spring Cloud Function. Issued with a medium severity by vendor VMWare (https://tanzu.vmware.com/security/cve-2022-22963) researchers have since found that achieving remote code execution is possible. An upgrade patch already exists, so affected users are urged to upgrade as soon as possible.  

For the second vulnerability, a CVE identifier has not been assigned yet. This is the vulnerability many security researchers have been calling Spring4Shell. Under certain circumstances, it allows an attacker to run arbitrary code, but the ease of exploitation varies with how the code running on Spring Boot is written, and how Spring Boot is run.  

Regardless of how Spring4Shell evolves, these two vulnerabilities highlight the importance of knowing what open source components you are using and keeping on top of vulnerabilities as they are disclosed. Software Composition Analysis (SCA) solutions do exactly this. They can produce a software bill of materials (SBOM) for an application and proactively notify you when new vulnerabilities are disclosed in components you have used.

  Read Less
April 01, 2022
Brian Fox
CTO and co-founder
Sonatype

There are two vulnerabilities that are being mixed up here — one in Spring Cloud released as CVE-2022-22963 that was high risk, but not severe. The other is a new vulnerability that the community is dubbing ‘Springshell,’ which is open to wider impact. It appears there are some mix-ups between these two.

The new vulnerability does seem to allow unauthenticated RCE but at the same time, has mitigations and is not currently at the level of impact of Log4j. We’re continuing to look into this to

.....Read More

There are two vulnerabilities that are being mixed up here — one in Spring Cloud released as CVE-2022-22963 that was high risk, but not severe. The other is a new vulnerability that the community is dubbing ‘Springshell,’ which is open to wider impact. It appears there are some mix-ups between these two.

The new vulnerability does seem to allow unauthenticated RCE but at the same time, has mitigations and is not currently at the level of impact of Log4j. We’re continuing to look into this to determine how it will shake out, however. We can appreciate the recent Log4shell memory is rightfully causing anxiety in the industry, as Spring is one of the most popular software frameworks out there. Regardless, this should act as another reason for every organization to take stock of how they are managing their third-party components.

  Read Less
April 01, 2022
Jeff Costlow
CISO
ExtraHop

When zero day exploits like Spring4Shell come to light, organizations immediately are thrust into panic mode, scrambling to determine the potential blast radius of vulnerability. Given the broad use of Apache Tomcat by developers, this remote code execution vulnerability has huge potential impact. Security teams need to immediately understand what software and devices might be affected and identify whether there are any vulnerable devices in their environment. This can be remarkably challenging

.....Read More

When zero day exploits like Spring4Shell come to light, organizations immediately are thrust into panic mode, scrambling to determine the potential blast radius of vulnerability. Given the broad use of Apache Tomcat by developers, this remote code execution vulnerability has huge potential impact. Security teams need to immediately understand what software and devices might be affected and identify whether there are any vulnerable devices in their environment. This can be remarkably challenging because many organizations struggle to maintain an up-to-date inventory of devices in their environment, let alone have the ability to detect software types and versions running on their business devices.

We know at this point that the remote code execution vulnerability is present in the Java Spring framework, but it may also be present in other Java applications. It affects Tomcat, a very common connector that joins together a webserver and the Java application. We suspect there may be other vulnerable applications, but are focusing on the attacks that are in the wild. We have reports of scanning already for this vulnerability so it is only a matter of time before a fully weaponized POC is leveraged. This is a severe remote code execution zero day that can be accessed over HTTP or HTTPS.  The use of encrypted protocols to exploit this vulnerability, as well as others like Log4Shell, underscores the degree to which encryption is being weaponized by cyberattackers.  While open source code is truly the building block of our internet and software universe, this vulnerability yet again shines a light on the issue of such an ubiquitous framework in the context of cybersecurity.

  Read Less
April 01, 2022
Etay Maor
Director of Security Strategy
Cato Networks

Two Remote Code Execution (RCE) vulnerabilities have been discovered in the Java Spring framework used in AWS serverless and many other Java applications. At least one of the vulnerabilities has been currently assigned a critical severity level and is already being targeted by threat actors. Within 20 hours of the disclosure, Cato Networks customers were already protected from attacks on both vulnerabilities as Cato Networks security researchers researched, signed and enforced virtual patching

.....Read More

Two Remote Code Execution (RCE) vulnerabilities have been discovered in the Java Spring framework used in AWS serverless and many other Java applications. At least one of the vulnerabilities has been currently assigned a critical severity level and is already being targeted by threat actors. Within 20 hours of the disclosure, Cato Networks customers were already protected from attacks on both vulnerabilities as Cato Networks security researchers researched, signed and enforced virtual patching across Cato SASE Cloud. No Cato Networks systems are affected by this vulnerability. 

The two vulnerabilities come following a recent release of a Spring Cloud Function. One vulnerability, Spring4Shell, is very severe and exploited in the wild. No patch has been issued. The second vulnerability, CVE-2022-22963, in the Spring Cloud Function has now been patched by the Spring team who issued Spring Cloud Function 3.1.7 and 3.2.3. 

Within 20 hours of the discovery, Cato customers were already protected against attacks against the vulnerabilities through virtual patches deployed across Cato. Cato researchers had already identified multiple exploitation attacks by threat actors. While no further action is needed, Cato customers are advised to patch any affected systems.  

Similar to the Log4j vulnerability, CVE-2022-22963 already has multiple POCs and explanations on GitHub – making it easy to utilize by attackers. As part of the mitigation efforts by Cato’s security and engineering team we verified that no Cato Networks system has been affected by this vulnerability.  

As we have witnessed with Log4j, vulnerabilities such as these can take organizations a very long time to patch. Log4j exploitations are still observed to this day, four months after its initial disclosure. Subsequent vulnerabilities may also be discovered and Cato’s security researchers will continue to monitor and research for these and other CVEs – ensuring customers are protected.  

 

  Read Less
What do you think of the topic? Do you agree with expert(s) or share your expert opinion below.
Be part of our growing Information Security Expert Community (1000+), please register here.