Fixing Spingboot RCE Via Data Binding

Fixing Spingboot RCE Via Data Binding

An article about fixing a vulnerability called CVE-2022-22965 on Springboot RCE via data binding

So today we are here to talk about a vulnerability that was first reported by VMWare on 31st of March, 2022. The key point that caused this vulnerability is a Spring MVC or Spring WebFlux application running on JDK 9+ which may be vulnerable to remote code execution (RCE) via data binding. Before we dig into this issue, let's first understand what is RCE and how are RCE attacks possible.

So what is RCE?

RCE stands for Remote Code Execution. So let's assume that there exists a WebApp hosted that is being targeted by the attacker and by using a certain vulnerability the attacker can gain access to the system of the WebApp and is now able to execute commands on that machine remotely. This kind of attack is defined as an RCE attack and with growing digitalization interests in many organisations, security awareness becomes a priority for the tech community. The lack of awareness and carelessness in coding is the primary reason for any application layer vulnerability and out of these vulnerabilities, RCE is one of the most critical ones.

What can an attacker do with RCE and what all may contribute to the initial starting point of the attack?

As we discussed above, RCE can provide command execution rights to the attacker, so the attacker can edit or even destroy important files on your server which might lead to downtime or worse lock you out of your own server. They can even steal confidential data stored on the server or the data that the server has access to. They can also perform DDoS attacks on the server and compromise service availability.

These attacks can occur due to:

  • Unchecked external user input
  • Poor practices followed while defining Identity and Access Management policies
  • Authentication strategies are not properly put in place
  • Buffer overflow

So now coming to the CVE-2022-22965 which is also an RCE vulnerability that was found on the Springboot framework. If you are using Springboot, then please look at the points listed down below and see if you are falling into the usage category.

Prerequisites:

  • Using JDK 9 or higher
  • Using WAR packaging and deploying the same on a standalone Apache Tomcat server.
  • Apache Tomcat is being used as a servlet container
  • Using spring-webmvc or spring-webflux dependencies
  • Using Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions

Note: If you are using the default way to deploy Springboot applications i.e. using JAR executable and using an embedded tomcat server or a reactive web server, then you are impacted by this vulnerability

What can you do to mitigate this?

The recommended way is to upgrade your spring version to 5.3.18 if you are using 5.3.x or if you are using the 5.2.x version, then upgrade to 5.2.20 or higher which will fix the vulnerability. For some reason, you are not able to upgrade, then you can do the following as well:

  • Upgrading Tomcat - For older, unsupported Spring Framework versions, upgrading to Apache Tomcat 10.0.20, 9.0.62, or 8.5.78 provides adequate protection
  • Downgrade to Java 8 - Downgrading to Java 8 is a viable workaround if you can neither upgrade the Spring Framework nor upgrade Apache Tomcat.
  • Disallowed Fields - Another viable workaround is to disable binding to particular fields by setting disallowedFields on WebDataBinder globally. You can use the following code to achieve this:
@ControllerAdvice
@Order(Ordered.LOWEST_PRECEDENCE)
public class BinderControllerAdvice {

    @InitBinder
    public void setAllowedFields(WebDataBinder dataBinder) {
         String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
         dataBinder.setDisallowedFields(denylist);
    }

}

Conclusion

This article was intended to provide an insight into certain vulnerabilities that might occur in Springboot RCE, its causes and how to get about fixing them. This is a global way of doing it but this might still leave some open loopholes. The in-detail workaround is provided here.

That is it for this time! I hope you got to learn something and if you are impacted by the vulnerability, I hope you were able to get some info about the issue and its cause.

References: