Critical vulnerability in Spring

As indicated, there are multiple security issues within some Spring modules. The links below will take you to articles that properly describe these problems: https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vulnerability.html

How: https://www.cyberkendra.com/2022/03/spring4shell-details-and-exploit-code.html

As indicated there is a very serious vulnerability, in the below github environment an exploit has been implemented where you can recreate the problem: https://github.com/DissiNL/Spring4Shell

Thursday, March 31, several updates to Spring modules became available in which the vulnerabilities were resolved. Your best bet is to upgrade the Spring modules.

In the unlikely event that this is not possible, you can also close the vulnerability yourself. The Github environment below has all the information you need for that: https://github.com/DissiNL/Spring4Shell/blob/master/src/main/java/com/dissi/serializationdemo/BinderControllerAdvice.java#L10-L19

Below is all kinds of information we needed to arrive at the above problem description, exploit and solutions. If you want to know how it works in detail, you may be interested in this information as well.

We’ve added a simple workaround example in the readme. The exploit can be enabled on demand
https://github.com/DissiNL/Spring4Shell/blob/master/README.md

WAF protection

On network protection devices such as WAF, implement rule filtering for strings such as

according to the actual traffic situation of deployed services. After filtering the rules, test the business operation to avoid additional impact.

Detection of exploit through SNORT (IDS/IPS) Rules:

The Rules below can be loaded into any IDS that supports Snort Rules (for example, Snort and Suricata). These rules were tested and developed based on the network traffic generated by the POC exploit published by LunaSec. Possibly these rules do not detect all the exploits that are (going to be) used “in the wild.” Therefore, use them as part of a layered security and do not rely blindly on these rules. Note: These rules only work for HTTP traffic and thus cannot look into TLS (HTTPS) traffic (unless specific measures are taken for that purpose).

Detection of exploit through YARA Rules:

The YARA rules on the Git Repository published below can help detect (slightly modified) Proof-Of-Concept exploit code in logs. https://github.com/Neo23x0/signature-base/blob/master/yara/expl_spring4shell.yar

Guidance on how to handle Spring4Shell:

IDENTIFY:

• What (company) assets are using Spring Core?
• Which version are they on?
• Are they part of my “Crown Jewels”?
• Which parts of my process rely on these assets?
• What happens when these assets get compromised or need to be shut down?

PROTECT:

• Is it possible to separate these assets from the rest of my network and infrastructure until i can mitigate the issue or release a fix?
• If not, can I take any other measures to protect the rest of my infrastructure? (Additional firewalling, Limiting access from untrusted sources, etc.).

DETECT:

• Can I detect any malicious activity relating to Spring4Shell?
• Yara Rules
• Log Analysis / SIEM
• IDS Rules

RESPOND:

• Prepare:
• Create a response plan. Consider:
• Communications (who needs to know and when?)
• Analyze the possible impact
• Mitigation and Containment
• Consider incorporating forensics

ACTUAL RESPONSE:

• Activate your response plan, or if you don’t have one:
• Inform critical stakeholders
• Analyze the impact of the breach/incident
• Isolate affected systems and mitigate the incident on these systems
• Check the rest of your infrastructure for indicators of compromise if you are not sure if containment was sufficient

RECOVER:

• Activate Response or Business Continuity plans
• Communicate to critical stakeholders what happened and what the expected timeline for recovery is
• Restore affected systems and patch vulnerabilities before going live
• Evaluate what has happened