What is Log4J and What's the Problem?
In this article
What is Log4J?
Apache Log4j 2 is an open-source logging utility. It is used by developers to return log messages pertaining to the code that they have written. It is one of the most widely utilised logging libraries in the Java ecosystem. By using libraries, such as Log4j, programmers can re-use common components within their programs saving them time in having to write their own component.
That's the beauty of open source software, right? It allows you to customize it to fit your specific need! That was until a zero-day vulnerability (CVE-2021-44228 rated 'critical') was recently detected that involves arbitrary code execution: this has been named "Log4Shell".
In simple terms that means a security flaw in a program can allow a malefactor to run any program remotely (over a network, like the Internet).
How serious is it?
Extremely serious as this vulnerability gives full access to a computer running an unpatched version of Log4j. This would allow data exfiltration and malware deployment and other nefarious acts.
The Apache Software foundation has rated it 10/10 for seriousness and it has been described as "the single biggest, most critical vulnerability of the last decade."
BishopFox have created the following list, below, (likely incomplete at this time) of open-source projects that use Log4j by default:
- Elasticsearch
- Grails
- Hadoop
- Kafka
- Kibana
- Solr
- Spark
- Struts
- Tapestry
- Wicket
The following projects don't appear to use Log4j by default, though they may optionally be configured to use it:
- ATG
- Dropwizard
- Hibernate
- Java Server Faces
- Spring Framework
- Tomcat
Industry guidance
There are a number of OEMs and industry bodies that have been quick to issue guidance and recommendations.
Some OEMs have created "vaccines" for the vulnerability that uses the vulnerability itself to set a flag that turns off the vulnerability. This approach may buy SOC teams time while they roll out the patched version of code. Customers should also check regular OEM updates.
Other OEM's, such as F5 whilst not directly vulnerable to the issue within their product set, have issued advice and ways to mitigate; and Crowdstrike were quick to issue a blog providing latest intel on the situation. Apache have made a fixed version (version 2.15.0) and users of this utility should update immediately.
Once you have identified vulnerable systems and hosts, you need the processes (expedited change control and test) and toolsets to deliver the updated software components.
Attackers use arbitrary ports so network firewalls may not be able to detect traffic associated with this vulnerability through port number however they may be able to detect via application fingerprinting out bound LDAP and JMRI requests. Firewall vendor IP reputation and anti-bot feeds should be kept up to date to reduce the chances of endpoints communicating with known bad IP addresses. Additionally changes can be made with to WAF rulesets to try and mitigate the impact of this vulnerability – both Akamai and CloudFlare are working on these rules.
As more is understood about the nature of the exploit in the wild, more advice will be forthcoming, however early indications are that threat hunters can look for IP addresses scanning and listening for compromised endpoints, monitoring for rogue JRMI (Java Railroad Model Interface) or LDAP (Lightweight Directory Access Protocol) requests to external servers and hunting for inbound Java classes to compromised endpoints.
SIEM vendors, like Splunk, will be developing IOC tracking rules for their datasets.
Moving forwards, dealing with zero-day vulnerabilities is dependent on having a good software inventory (CIS Critical Control Number 2) – if you don't know that you are using a programme, how can you patch it?
WWT is helping many customers in this respect with Observability, Data Discovery and Validation, and is able to blend our proprietary capabilities together with partners, such as vArmour. This means that when vulnerabilities such as this arise organisations are well-equipped to identify evaluate and react.
For our clients who we are working with in on active discovery we can assist in two ways:
- Since we have performed the Application Dependency Mapping and are protecting and monitoring the relationships, if an Apache machine had been exploited, we can tell the SOC exactly what was in the potential path of the breach. While this isn't earth shattering, the context of what application is in the path absolutely is. The quick identification of a potential danger to a critical system allows the enterprise to be proactive instead or reactive.
- We would leverage the labels to identify all the Apache in the enterprise. This is important because based on the relationships of the applications, the Patching order can be established. Based on the criticality of the applications in the potential path of an impacted Apache server, that can drive the decision of patching the machines that are most able to access the most critical Enterprise applications. By using our process, we are enabling an enterprise to work faster and smarter.