A sequence of Tweets (that are now deleted) from a Chinese Twitter account was posted on March 29th, 2022, displaying pictures of a new POC of a 0-day vulnerability in one of the most popular Java frameworks, known as Spring Core. Internet Users refer to it as the ‘Spring4Shell’ or ‘Spring Shell’ vulnerability.
Spring is a popular enterprise-grade application framework in Java. A remote code execution vulnerability known as Spring4Shell was discovered around the end of March.
It was named Spring4Shell because Spring Core is a popular library, comparable to Log4j which spawned the infamous log4shell vulnerability.
This vulnerability allows a remote unauthenticated attacker to access exposed Java class objects which in turn can lead to Remote Code Execution (RCE). There has been a lot of hype and confusion in the tech press around this vulnerability. The confusion is mainly to do with CVE for Spring Cloud Function which was released at the same time as Spring4Shell vulnerability, but the two are unrelated.
The Spring4Shell vulnerability (CVE-2022-22965) impacts SpringMVC (Spring Web model-view-controller) and Spring WebFlux applications when running on Java JDK9 and subsequently on a Tomcat application server. The vulnerability can be exploited to write to an arbitrary file on the server, which can then be leveraged to achieve remote code execution.
There appears to be a confusion about the potential severity of Spring4Shell. While it was initially claimed that all versions of Spring Core with a JDK version greater than or equal to 9.0 were vulnerable, researchers later discovered that Spring Core requires a specific configuration to be vulnerable.
In this particular blog, Spring themselves commented that for the “specific exploit” i.e., the publicly released one, to work, an application must meet the following prerequisites:
Further on, the advisory reads:
… If the application is deployed as a Spring Boot executable jar, i.e., the default, it is not vulnerable to the exploit …
However, it did also say that:
… the nature of the vulnerability is more general, and there may be other ways to exploit it …
The exploit code that has been made public specifically targets Apache Tomcat deployments. It only affects Spring Applications that are deployed as traditional WebArchive (WAR) files to the Apache Tomcat Servlet container.
The main issue occurs when we have a controller that has a request mapping loaded into memory. In the example below, the vulnerability lies in the function that uses the @PostMapping annotation. Here’s an example:
...
@Controller
public class HelloController {
...
@PostMapping("/greeting")
public String greetingSubmit(@ModelAttribute Greeting greeting, Model model) {
return "hello";
}
}
As can be seen above, we have a controller ‘HelloController’, that will handle HTTP requests from http://localhost:8080/helloWorld/greeting . The function that handles ‘postMapping’ is called ‘greetingSubmit’, and it takes a Plain Old Java Object (POJO) as input, which, in our case, is our ‘Greeting’ object. For more details on the ‘Greeting’ object, see the code block below:
public class Greeting
{
private long id;
private String content;
public long getId() {
return id;
}
public void setId(long id) {
this.id = id;
}
public String getContent() {
return content;
}
public void setContent(String content) {
this.content = content;
}
}
Next, we’ll compile the project and host it on a Tomcat server to exploit it. When we try calling our application, the input is transformed into a POJO i.e., the ‘Greeting’ object.
Behind the scenes, the framework uses serialization to transform this input, which makes it possible for external users (attackers) to set other values. For this, we can search for values that can be set using query parameters.
After a bit of research, it appears that we can set the properties of ‘class’. We can then find properties of ‘class’ that we can both write to and is also relevant to program’s execution.
The following Tomcat logging properties can be set from the exploit code above.
class.module.classLoader.resources.context.parent.pipeline.first.pattern
class.module.classLoader.resources.context.parent.pipeline.first.suffix
class.module.classLoader.resources.context.parent.pipeline.first.directory
class.module.classLoader.resources.context.parent.pipeline.first.prefix
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat
To show this in action, we’ll run the Python exploit.
When the final request is sent, the property values that have been set by the exploit code will be used to achieve a remote code execution (RCE). For this, visit the newly created web shell located at http://localhost:8080/shell.jsp and modify the GET parameter ‘cmd’.
Note: The payload from the ‘pattern’ property set above, will be written to the following file: ‘webapps/ROOT/shell.jsp’. The query parameter ‘cmd’ can be used to pass in an arbitrary command.
By partnering with Redfox Security, you’ll get the best security and technical skills required to execute an effective and thorough penetration test. Our offensive security experts have years of experience assisting organizations in protecting their digital assets through penetration testing services. To schedule a call with one of our technical specialists, call 1-800-917-0850 now.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. With a combination of data-driven, research-based, and manual testing methodologies, we proudly deliver robust security solutions.
“Join us on our journey of growth and development by signing up for our comprehensive courses, if you want to excel in the field of cybersecurity.”
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
info@redfoxsec.com
©️2024 Redfox Cyber Security Inc. All rights reserved.
