Various groups of malicious actors continue to develop exploits targeting the Log4j vulnerability. However, there’s a reason it continues to garner hype regarding its impact for years to come. For one, with traditional XDR and SIEM, even with the minimal scanning capabilities mostly supported today, it is extremely difficult to detect. Second, these exploits are used in many software applications, including server applications, cloud services, and even services embedded directly into hardware devices. And these are all connected and accessible on the Internet.
To add salt to the wound, the FTC said it intends to use all of its legal authority to sue companies that fail to take “reasonable steps” to protect consumers from Log4j exploits. This is a backlash to the costly Equifax debacle several years ago.
What do we know about this?
A member of the Alibaba Cloud Security team reported CVE-2021-44228 (CVSS 10 out of 10) to Log4j Developers Nov 24and. Apache released a patch on December 6and; however, it appears that the earliest evidence of an exploit dates back to December 1. This is unfortunately common in several respects. A vendor or researcher discovers and discloses a vulnerability and attackers exploit the vulnerability long before a patch is developed. Or an attacker discovers a vulnerability, and it’s exploited in the wild long 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 which was previously presented at Black Hat USA 2016.
The vulnerability allows an attacker to remotely execute code based on a previously known flaw in a Java-based logging utility (JNDI). Unfortunately, the bottom line is that if exploited (which by its nature is a simple task), it allows any type of malicious activity to spread if undetected on the cloud infrastructure, on site or on remote networks.
Why is it hard to find and patch?
Since it is a widely used cross-platform software library, it is integrated at multiple runlevels into many different applications, many of which are Internet-based applications. Like other large-scale attacks, it requires a 100% complete understanding of all assets and applications.
Beyond that, due to the nature of Java, log4j can be embedded in applications in such a way that it’s impossible to tell if it’s included without it being actively called and used. Worse, the dependency between multiple projects means that a vendor may have used a version of log4j embedded in another software application that calls another version of log4j also embedded in another application, etc. This is a large dependency tree that can span multiple branches where each vendor must update their software to prevent the service from being exploited.
What can be done?
Threat actors actively scan for log4j vulnerabilities or even just try brute force methods to see if systems are susceptible. This has been happening constantly around the world in enterprises and cloud providers since the vulnerability was discovered. And new attacks and variants are constantly coming out. As described earlier, vulnerability scanners cannot easily discover Log4j. Besides manual or software vendor-dependent patches, organizations will discover its existence through active exploitation.
This only reinforces the need for more advanced security capabilities than exist in today’s popular traditional XDR and SIEM tools. Organizations should deploy solutions that use User and Entity Behavior Analysis (UEBA), and real machine learning models. These solutions will base activity, identify abnormal movements and connections, and determine if a new exploit or variant has been created. Additionally, adopting high-fidelity response actions by leveraging integrated security orchestration, automation, and response (SOAR) to automatically initiate an action can reduce impact and empower teams to security time to investigate the service. Such a typical action would be quarantining a specific Apache web server, for example.
Next steps – Attend 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 attend our webinar to learn more about how Gurucul’s next-gen SIEM can be used to determine the impact of Log4j and monitor active exploits.
Webinar: Determining the Impact of Log4j and Monitoring Active Exploits
When: Thursday, February 17, 2022
Time: 11:00 a.m. (Pacific Time)
*** This is a syndicated blog from the Security Bloggers Network of Gurucul Blog | Security Analysis | Big Data Machine Learning Models written by Sanjay Raja. Read the original post at: https://gurucul.com/blog/the-hunt-for-log4j