Various threat actor groups continue to develop exploits that are targeting the Log4j vulnerability. However, there is a reason it continues to garner the hype regarding its impact for years to come. For one, with traditional XDR and SIEM, even with the minimal analytics capabilities predominantly supported today, it is extremely difficult to detect. Second, these exploits are being used in numerous software applications that includes server applications, cloud services and even services embedded directly into hardware devices. And these are all connected and accessible across the internet.
To add salt to the wound, the FTC says it intends to use its full legal authority to pursue companies that fail to take “reasonable steps” to protect consumers from Log4j exploits This is a subsequent reaction to the costly Equifax debacle from several years ago.
What Do We Know About It?
A member from the Alibaba Cloud Security Team reported CVE-2021-44228 (CVSS 10 out of 10) to the Log4j developers on November 24th. Apache released a patch on December 6th; however, it appears the first evidence of an exploit was December 1. This is unfortunately common in several ways. Either a vendor or researcher discovers and discloses a vulnerability and attackers exploit the vulnerability well before a patch is developed. Or an attacker discovers a vulnerability, and it gets exploited in the wild well before a vendor or researcher discovers it.
Log4j is a popular logging library in Java and is used in several applications, including:
- Apple iCloud, Tencent, Steam, Twitter, Baidu, DIDI,JD, NetEase, CloudFlare, Amazon, and Tesla.
- Apache Solr, Apache Druid, Apache Flink, Apache Struts2, Flume, Dubbo, Redis, Logstash, ElasticSearch, Kafka, Ghidra, and Minecraft.
Log4Shell uses the JNDI attack vector that was previously presented at BlackHat USA 2016.
The vulnerability enables an attacker to perform remote code execution based on a previously known flaw in a Java-based logging utility (JNDI). Unfortunately, the bottom line is if exploited (which, inherently is a simple task) it allows any type of malicious activity to run rampant if undetected across cloud infrastructure, on-premises, or remote networks.
Why is it hard to find and patch?
Since it is a cross-platform, widely used software library, it is embedded at multiple levels of executions across so many different applications many of which are internet-based applications. Just like other high-profile attacks, it requires a 100% complete understanding of all assets and applications.
Beyond that, due to nature of Java, log4j can be nested into applications in such a way that it is impossible to know if it is included without it being actively called and used. Worse is that the dependency across multiple projects means that a vendor may have used a version of log4j that is embedded in another software application that makes a call to another version of log4j that is also embedded in another application and so forth. It is a big dependency tree that can go several branches deep where every vendor must update their software to prevent exploitation of the service.
What Can Be Done?
Threat actors are actively scanning for log4j vulnerabilities or even simply trying brute force methods to see if systems are susceptible. This is going on consistently world-wide across enterprises and cloud providers constantly since the vulnerability was discovered. And new attacks and variants are constantly coming out. As described before, vulnerability scanners cannot easily discover Log4j. Other than manual or software vendor-dependent patching, organizations will discover its existence via active exploitation.
This only re-enforces the need for more advanced security capabilities than exist in today’s popular XDR and traditional SIEM tools. Organizations must deploy solutions that use User and Entity Behavior Analytics (UEBA), and true machine learning models. These solutions will baseline activity, identify abnormal movement and connections, and determine if a new exploit or variant has been created. In addition, adopting high-fidelity response actions by leveraging integrated security orchestration, automation, and response (SOAR) to automatically initiate an action can reduce the impact and give security teams time to investigate the service. A typical such action would be quarantining a specific Apache Web Server, for example.
Next Steps – Watch the Webinar
Gurucul has developed a quick guide on how we can leverage our UEBA capabilities and 2500+ machine learning models to detect Log4j out of the box. Please view our webinar to learn more about how Gurucul’s Next Generation SIEM can be used to determine Log4j’s impact and to monitor for active exploits.
On Demand Webinar: Determining Log4j’s Impact and Monitoring for Active Exploits