As you’re probably knee-deep in reacting to the Spring Framework RCE we wanted to provide some helpful information on how to tackle this issue.
For all the details from Spring on this RCE here is a link to the granular details of the issue:
Just like the Log4Shell vulnerability, there are a lot of different variables, such as version numbers, specific app servers, and packaging types for this RCE to exist that need to be investigated. We get it – it is going to be a long rest of the week for everyone
Why should I care about this vulnerability?
RCE is probably one of the worst types of vulnerabilities as it could lead to loss of control of how your applications or systems work. The official definition of Remote code execution (RCE) vulnerabilities is
“RCE is the term to describe the execution of arbitrary code on a computer system, where the threat actor does not have direct access to the console. It is as if the attacker is physically sitting in front of the system as they take full control of it.”
This specifically impacts customers’ running:
- JDK 9 or higher
- Apache Tomcat as the Servlet container
- spring-webmvc or spring-webflux dependency
- Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions
I am affected what should I do next?
Ok, you have all the requirements based on all the variables associated with the RCE. What is the next step? Once every instance of the vulnerable Spring Frameworks (Versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions) are identified you need to prioritize which instances are the most dangerous to my organization.
How should I prioritize?
The best way to prioritize is to understand how the vulnerable framework version is being used in your application architecture, specifically identify:
- Internet-facing services
- Services that access sensitive data (PII, PCI, PHI)
- Services that access 3rd party services, APIs, or applications
Prioritize the services that can be exploited today, and then work backward across your application and service portfolio.
Look for updates from Spring
One of the interesting things in the link from Spring at the beginning of this article is this statement “However, the nature of the vulnerability is more general, and there may be other ways to exploit it.” What this says to me is the details are still coming out on this RCE. There may be more ways to execute this RCE or different technologies associated with it, so check back for the latest information as the experts do additional research.
Leverage Application Security Posture Management (ASPM) for Spring RCE
Bionic has already started working with its customers to help them mitigate this new risk. This is what we recommend.
You are currently in the “Do I have this issue?” stage. Identifying the issue is very important but super complicated. However, don’t waste valuable time and resources on an investigation into this RCE vulnerability if your applications don’t have it in the first place. This is where Application Security Posture Management comes into play. It allows you to quickly query your application architecture for all the specific RCE requirements for this vulnerability. If the requirements are not met, you know you don’t have to waste time investigating any further.
Example: Bionic ASPM Query
in:services and technology:”*tomcat*” and not(engineVersion:”*1.8*”) and libraries:((name:”*spring-webmvc*” or name:”*spring-webflux*”) and not((version:”*5.3.18*” or version:”*5.2.20*”)))
Where the vulnerable Spring RCE framework exits
With the Tomcat and JDK Requirements
Prioritization with ASPM
Application Security Posture Management also allows you the ability, using the same query interface that created the query above, to see how the affected service in question is part of the greater application architecture which allows organizations to fix the most serious instance first. It can, for example, provide information on what type of sensitive data is involved, if the application is internet facing, or if it interacts with 3rd party applications. A very quick and easy way to prioritize what to fix first
Ongoing Monitoring and Protection
If new information or criteria are released on this RCE issue, it is very simple to update the queries above to include it. This way you don’t have to start your investigation over from the beginning.
This issue is going to affect a lot of people and organizations, but having a plan to address it is very important. If you have this RCE issue in your organization, focus on fixing the most dangerous issues first. Make sure you thoroughly test your applications if you update any of the frameworks in question, and watch for more information or requirements as they come out.