THREATPOST

Detecting Spring4Shell (CVE-2022-22965) Exploitation Using DNIF

Discovered recently, Spring4Shell (CVE-2022-22965) is a critical remote code execution vulnerability. Learn how to detect this exploitation using DNIF.

What is Spring4Shell?

Spring4Shell is the name given to a critical remote code execution vulnerability that was disclosed on March 30, 2022. It is particularly a part of the spring-beans package, a dependency in both spring-webmvc and spring-webflux. To know more check out our blog, Understanding the Spring4Shell Vulnerability.

Detection of the exploitation

The exploitation for this vulnerability happens in two stages:

  1. Creation of a jsp file through logging properties of the class to execute commands remotely.
  2. Using the jsp file created in the above step to run commands remotely.

The first step where creation of the jsp file happens can be detected as there exists  a fixed syntax/signature of the exploit which can be found in the logs of the web server.

The web server request of the step 1 is as follows:

creating rce.jsp

The class.module.classLoader.resources.context.parent.pipeline.first.pattern  keyword can be detected and matched using the access logs of the web server. By default Spring Boot uses Apache Tomcat web server. Tomcat saves access logs in the /app/tomcat/logs/directory which can be forwarded to the DNIF setup where you want to detect Spring4Shell exploitation.

Do you need to create a new extractor?

Absolutely not. You don’t need to create or configure a new extractor for parsing apache tomcat webserver logs for your DNIF setup. DNIF ships tomcat extractor out of the box with all the installations. It is already configured and enabled for you to just forward your logs and get started.

Detecting Spring4Shell using DNIF

You need to create a streaming workbook to actively monitor the exploitation of Spring4Shell (CVE-2022-22965). The workbook has to have two blocks as follows:

  1. SQL Block: To detect the exploitation from the web server logs and aggregate the results.
  2. Signal Block: To raise signals for every row of the result that you get from the detection for further investigation.

SQL Block

Add an SQL block to a new workbook and paste the following SQL query:

SELECT $SrcIP, $System, count(*) FROM WEBSERVER WHERE $Action='REQUEST_ALLOWED' AND $URL LIKE '%class.module.classLoader.resources.context.parent.pipeline.first.pattern%' GROUP BY $SrcIP, $System LIMIT 100

This query is fetching logs from the WEBSERVER stream where the tomcat logs are stored and checking for the keyword which is used for the exploitation of this vulnerability. It will also aggregate the results on the basis of $SrcIP viz the IP of the attacker and $System viz the system on which the attack is happening.

Signal Block

Add a signal block with the following information:

Name: Spring4Shell Exploitation
Tactic: Execution
Technique: System Services
Confidence: Medium
Score: 5
TargetHost: $System
SuspectHost: $SrcIP

The signal block should look similar to the following screenshot:

Screenshot from 2022-04-13 18-57-21

This signal block will take the results from the above SQL block and raise signals on the aggregated results for further analysis.

The entire workbook should look as follows:

Screenshot from 2022-04-13 18-59-18

This file is now served and available at http://localhost:8080/rce.jsp.

Now save this workbook with a nice name as a streaming workbook and you are ready to go. Or you can download and import the yml file of the workbook to get started instantly. Any active exploitation of the vulnerability will be visible on the signals listing page of your DNIF console. You can further investigate the signal, create cases or get more intelligence around the vulnerability.

Happy hunting!

References

Similar posts