Dec 18, 2021
90 Views
0 0

Log4Shell vulnerability: What we know so far

Written by

The critical flaw in the ubiquitous Log4j utility has sent shockwaves far beyond the security industry – here’s what we know so far
Just as the holiday season is approaching our doorstep, a critical vulnerability in an Apache code library called Log4j 2 has come knocking at the door. Log4j is an open-source Java-based logging library that is widely used by many products, services and Java components. It’s little surprise that the flaw, which scored a perfect 10 on the CVSS scale and is putting countless servers at risk of complete takeover, has sent shockwaves far beyond the security industry.
Indeed, with proof of concept exploit code already available online, we’re now witnessing a mass race between hackers, who are conducting internet-wide scans and exploiting vulnerable systems, security defenders, who are updating systems and putting mitigations in place, and developers, who are auditing applications and code libraries for any dependencies that might include vulnerable versions of the Log4j library.
Indexed as CVE-2021-44228, the flaw is a remote code execution (RCE) vulnerability that allows an attacker to run code of their choice on an affected server. Should the adversary somehow get into the local network, even internal systems that are not exposed to the internet can be exploited. Ultimately, an RCE vulnerability means that an attacker doesn’t require physical access in order to run arbitrary code that could lead to complete control over affected systems and the theft of sensitive data.
To help make sense of the events around this critical vulnerability, here is a basic timeline:
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:
#BREAKING #ESETresearch heatmap shows hundreds of thousands of blocked #log4j exploitation attempts most of which were in the 🇺🇸US, 🇬🇧the UK, 🇹🇷Turkey, 🇩🇪Germany and 🇳🇱the Netherlands. Find out more about the vulnerability in our blogpost: https://t.co/J7tfY8NXFh pic.twitter.com/F4RGwO2sIG
— ESET research (@ESETresearch) December 14, 2021

In order to protect yourself from 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):
This script, available on GitHub, searches for the flawed JndiLookup.class file in any .jar archive on your system.
Linux
 
Windows
 
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
 
Zgrep
 
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.
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, December 15: 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. 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.
Finally, IP addresses that are known to be shady can be blocked with your firewall and/or intrusion prevention system.

The ESET customer advisory is available here. In addition, this article looks at what business leaders should know about the vulnerability. 
UPDATE 1 (December 14, 11.00 am CET): Added the tweet from ESET research.
UPDATE 2 (December 15, 2.00 pm CET): Updated the timeline and information on a new version of Log4j (2.16.0).

source

Article Categories:
Vulnerabilities

Comments are closed.