Spring4Shell: Responding to Zero-Day Threats with the Right Data

On March 30th, 2022, rumors began to swirl around a GitHub commit from a researcher containing proof of concept (POC) exploit code. The exploit targeted a zero-day in the Spring Core module of the Spring Framework, and was quickly confirmed against specific versions of Spring Core with JDK 9 and above. Anything running Tomcat is most at risk given the POC was based on Tomcat apps. This threat posture will evolve over time as new vectors and payloads are discovered and distributed. You have to admire the can do spirit of malware developers; no one innovates and evolves faster. In this blog post, let’s look at how to respond to Spring4Shell.

The question for security teams is: What do you do to mitigate this threat and prepare for what’s next? Too often, security teams are forced to execute one-off, ad hoc responses instead of having a refined practice for remediating these types of exploits. Building a practice needs data, and lots of it. Rather than hunting down web logs after a threat is discovered, the logs need to be available on-demand. This is where observability practices benefit security teams. Observability is key to driving successful security detection, so that nothing is missed and the response is triggered as fast as possible. According to a 2021 IBM study, the gap between breach and detection is around 287 days, so every possible thing needs to be done to speed up detection.

Addressing Spring4Shell

For the current Spring4shell issue, start validating the following data sources are in your SIEM:

• Web server logging
• WAF logging
• EDR/XDR logging
• Java application server logging

All of these data sources should be flowing into your observability pipeline and then into your SIEM, so you can write detections for this issue. If these data sources are not in your SIEM it is time to get this data ingested and structured properly. Unplanned work, but required to get detection coverage for Spring4shell. Consider using the free version of observability pipeline Cribl Stream to enhance your data and determine if the supported version is worthy of your investment.

You can use your observability pipeline to detect the commands and payload used to exploit Spring4Shell. A good example of this is Igor Gifrin’s Dec 13 blog post about Log4Shell. Focus on Stream’s access to the in-flight event stream as the main point of the post. Access to the in-flight events offers many opportunities for speeding up the detection and response cycle from alerting to triggering a SOAR playbook.

For many organizations, application and security logging coverage is not well understood. However, they can use their observability pipeline to validate coverage and identify gaps, ensuring all of their web server/WAF/EDR/tomcat logs feed into their SIEM. Gaps in observability data collection impact detection quality, so closing all gaps has to be a priority. Every in-scope server and application has to have coverage. Your attacker only has to get lucky once, so it’s important to understand your assets and instrument your logging accordingly. Be methodical and consistent and keep the effort going long term. Don’t make it a one-off response to an emergency.

Observability is a practice, not a task. You’ll never be done with it. It’s easy to say we are going to have an observability project and spend a finite amount of time gathering data and building tools and then be done with it. If that is your approach your data quality and coverage will quickly degrade and not provide good results. The best/most expensive observability tools are only as good as its data. Bad data will give you bad results so it is critical that your team has ongoing/almost daily processes to validate and audit your data for quality and coverage.

Finally, make data skills a priority as you hire, or try to borrow expertise from your data science team. Observability is a necessary skill set, and it requires a new approach to be successful.

What to Do When Consuming Existing Logging Is Not an Option

If you have edge case Java application servers and/or Java applications that cannot properly log telemetry data, consider using an open-source project called AppScope. AppScope is very interesting in that it is designed to give black box instrumentation to application code that has not been instrumented for observability. AppScope provides tcpdump-like visibility to transactions. AppScope can be used with an open-source EDR tool like Wazuh as an active response to get enhanced capabilities that you would not have otherwise. If you have a small web server deployment and limited access to tools, you could deploy AppScope to your web servers and point it at the free version of Cribl Stream, giving your teams detailed insight and improving security and operational support.

Bottom Line on Spring4Shell

Prepare for the next RCE vulnerability now by starting an observability practice that seeks to consume all available server and application telemetry into an observability pipeline. That will enable you to cost-effectively shape and manage data on its way to your SIEM, driving a faster, more effective detection and response cycle. Consider using open-source tools like AppScope to instrument applications that don’t already provide the data visibility you need to cover gaps and improve your enterprise security posture.

Try Cribl’s free, hosted Stream Sandbox. I’d love to hear your feedback; after you run through the sandbox, connect with me on LinkedIn, or join our community Slack and let’s talk about your experience!