By now, it is quite clear how large the attack surface resulting from the Log4Shell vulnerability is, and how easy it is to exploit the vulnerability itself.
The biggest challenges facing organizations with this vulnerability are:
1. The large number of vendor products affected
The list of affected vendors is growing daily, and not all vendors may have patches or mitigation steps available. Continuously keeping track of affected vendors, whether affected software is in your environment, and scheduling workarounds or patching, is a daunting task. You can find the affected software list here.
2. The abundance of Java applications
If organizations are using custom applications written in Java, either developed internally or via external vendors, these applications need to be patched and re-deployed. But just because these create difficulty, that doesn’t mean you can’t maintain your security posture.
This blog breaks down how Fortra’s Alert Logic threat hunters and researchers stayed ahead of Log4Shell through forward-looking data analysis, a critical component of any effective MDR solution, how our customers are covered during challenging times like this, and what you should look for in an MDR provider.
The Rapid Evolution of the Log4Shell Vulnerability
Given the ease of exploitation, and the fact that the internet is bombarded with web attacks every day, it was just a matter of hours after the Proof-of-Concept exploit came out that the CERTs around the world started noticing this new attack pattern.
Initial exploit code is often followed by evasions where attackers add to the initial exploit code to bypass prevention and detection technologies. The development of evasions was the fastest seen in many years.
The evasions covered primarily three different areas:
1. String manipulation
The Log4j allows certain operators on strings that can be used to avoid simple patterns like “${jndi:ldap//..”. These operations can be broken into 2 basic formats that can be combined to create a combinatorial explosion of possibilities.
- ${lower:${lower:j}} is simply interpreted as “j”. The operator can be lower or upper.
- ::-j or ${env:FOOBAR:-j} are both interpreted as ‘j’.
By using the above 2 features in conjunctions, arbitrarily complex strings can be created instead of simple patterns.
2. Protocol Expansion within “jndi”
Initially it was thought that only ldap(s) or rmi are choices for exploitation. However, a range of others have been discovered including DNS, IIOPS, NIS, HTTP etc.
3. Transport Protocol
If an application provides services other than HTTP such as FTP or SMTP (email), and uses the vulnerable log4j library, it can be exploited over that protocol. Attackers are already seen sending the “jndi” attack pattern in email-headers in the hope of some email server software using vulnerable log4j for logging!
Staying Ahead of Log4Shell through Threat Research and Hunting
Across the security community, Threat Research and Threat Hunting teams have to be nimble to respond to the evolution of threat vectors. At Alert Logic, it was the same story.
First of all, I would like to highlight that this is not the first vulnerability we have seen related to JNDI. As a result, we had existing IDS telemetry deployed that was used for threat hunts on day 0, capturing traffic that was relevant to the Log4j exploit. Oracle WebLogic server vulnerabilities related to the JNDI component were disclosed in early 2021. Some Java de-serialization vulnerabilities were reported as early as 2018.
Alert Logic researchers perform deep analysis of these vulnerabilities and are always forward-looking in terms of potential new vectors of exploitation. It is the data collected from these forward-looking analytics that comes to the rescue during 0-days, speeding up our detection and hunting processes.
The same is true with our broad coverage of post-compromise MITRE techniques that help identify any successful attacks even if the very precise nature of the initial entry is not known.
We document these steps and other indicators as part of activity clusters and when a known technique is used, analysts can hunt up or down the attack chain to fill in the gaps and identify the unknowns.
Kudos to the Alert Logic Threat Research and Hunting teams that created a number of detections across all the security controls as the threats evolved in a span of few days.
Comprehensive Coverage Today: Kill Chain
A very similar exercise took place in the team that develops content for scanning. Within a few days, the team was ready with authenticated detections and network-based detections for vulnerable versions. This allowed our customers to identify vulnerable hosts that were bundled with the vulnerable Log4j version.
How does Alert Logic’s MDR Solution Cover Customers in this Challenging Time?
Alert Logic has number of well-integrated security controls as a part of the overall MDR solution portfolio. These include:
- Log-based Analytics: Learn more about the advanced abilities of Alert Logic’s Analytics Engine here.
- Network Telemetry Analysis: Alert Logic collects volumes of network traffic using wide-band telemetry signatures that is analyzed further through rules and ML analysis.
- Web Application Firewall: Fortra Managed Web Application Firewall (WAF) blocks incoming attacks over HTTP(s).
- Web Log Analytics: Given the volume of HTTP traffic, specialized modules have been created with Analytics Engine that are specifically geared for detecting HTTP attacks via web logs.
What Strengths Should You Look for When Selecting an MDR Provider?
- Multiple and Rich Security Controls across network, log and endpoints
- Agile Threat Research and Response Teams rapidly adapting to an evolving threat
- Comprehensive and forward-looking coverage for coverage of zero-days
- Visibility into environment and proactive Threat Hunting to identify risk and reduce impact
This vulnerability is going to have a long patching tail. Organizations must ensure that they have patch scheduling in place and are vigilant about the entire list of affected vendors in their environment. In addition, if they are using custom Java-based applications they need to be investigated for upgrades or workarounds. Restricting access to these custom applications is always a good safeguard until then.
