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.
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.
Information Security Buzz (aka ISBuzz News) is an independent resource that provides the experts comments, analysis and opinion on the latest Information Security news and topics
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.
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.
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.
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.
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.