Spring Java bug allows remote code execution and can be new Log4Shell

The new RCE bug in Spring Cloud allows the unauthenticated remote code executions on applications

Despite the limited requirements the flaw has already been exploited in the wild

Researchers warn about the new zero-day vulnerability in the Spring Core Java framework called Spring4Shell.^[1] The bug allows the remote code execution might become a new major issue as Log4Shell^[2] was. The revealing of this remote code execution flaw comes after the Chinese security researcher leaked a proof-of-concept exploit on GitHub before deactivating the account.^[3]

The reports and research show that unpatched flaw affects Spring Core on Java Development Kit versions 9 and later. This is a bypass for another flaw tracked CV-2010-1622 that enables the unauthenticated attacker to execute the arbitrary code on the targeted machine.^[4]

Spring is a popular application framework that software developers use for the quick and easy development of Java applications with enterprise-level features. These programs can be deployed on servers as stand-alone packages with various required dependencies.

The chain of discovered vulnerabilities

The Spring Cloud Function vulnerability tracked as CVE-2022-22963 came to light a few days ago.^[5] Then, proof-of-concept exploits were discovered. The information about more critical Spring Core remote code execution vulnerability started circulating in the QQ chat service and Chinese sites for cybersecurity. The leak was quickly removed, but researchers downloaded the code for the analysis.

Multiple firms managed to confirm the vulnerability and the level of concern the flaw can create. The flaw is dubbed Spring4Shell and is potentially caused by the unsafe deserialization of passed arguments. There are special requirements for the Spring app to be vulnerable, so the general statement that app apps running Java 9 or later are affected is not entirely true.

Some analysts state that the application must use the Spring Beans, Spring Parameter Binding, Spring Pramaneter Binding should be configured to use a non-basic parameter type like POJOs. The vulnerability relies on particular configurations, so exploits are not that easily achievable.

Exploitation requires an endpoint with DataBinder enabled (e.g. a POST request that decodes data from the request body automatically) and depends heavily on the servlet container for the application

The exploitation requires the attacker's research

The exploitation in certain configurations is as easy as it gets because the threat actor needs to send the crafted HTTP request to the vulnerable system, and the code can be executed. However, there are issues with other configurations where the attacker should do additional research to find the effective payloads for an attack like this.

Until the fix is publicly available additional details on the flaw named SpringShell and Spring4Shell cannot be revealed. Unfortunately, besides all the requirements and additional limits, the vulnerability has already been exploited in the recent attacks. There are no patches at the moment, so it is advised to deploy possible mitigations as soon as possible.

As for the question if this is the new possible Log4Shell vulnerability, researchers state that these findings raise major concerns that this may lead to widespread attacks since threat actors all the time search and scan for any vulnerable applications.

Attackers can use these exploits to execute commands on the server and gain full remote access to the device. These issues can lead to mass exploitations the Log4j servers^[6] had to encounter last year. Malware, ransomware attacks are possible from there. Let's hope it is not going to happen again.