Takeaway: Organizations of all types and sizes should actively manage exposure to loss due to the Log4j vulnerability. Doing so will not be easy. The Log4j program is present in so many applications that the magnitude of the issue is unlike any other. Following CISA guidance and adherence to a control framework, such as NIST CSF, are best practice for dealing with the vulnerability and avoiding civil action and penalty.
The Log4j exploit, also known as the Log4Shell vulnerability, allows threat actors to take control of web-facing servers by feeding them a malicious text string. Today, we will discuss who is impacted by Log4Shell and a possible solution.
Because Log4j is a commonly used Java logging library, this vulnerability could potentially impact all applications and software that implement Java. It’s difficult to quantify the sheer number of potentially affected systems. Many experts estimate billions of affected instances.
Why? Because Java is embedded into many digital products and services including:
Software with Apache Log4j security vulnerabilities don’t even need to be directly exposed to the internet to be exploited. Malicious strings can even permeate to back-end software running vulnerable Apache Log4j versions, even if the internet-facing web application isn’t coded in Java.
This means that even if none of the web applications and back-end software that a user is using are running vulnerable Log4j versions, third-party vendors might be, which then exposes the entire ecosystem to the potential of third-party breaches.
The enormity of attack vector options and the simplicity of their compromise is fueling an exploitation frenzy amongst cybercriminals.
According to Security Firm Check Point, over 60 variations of the original exploit were detected in less than 24 hours, meaning that cybercriminals are broadening their exploitation frameworks in anticipation of upcoming patches.
If malware is injected into LDAP servers, the CVE-2021-44228 vulnerability could result in a tidal wave of colossal data breaches and ransomware attacks that would dwarf some of the largest breaches.
List of companies that have been affected by Log4j vulnerability: https://github.com/YfryTchsGD/Log4jAttackSurface
List of software that has been affected by Log4j vulnerability: https://www.zyxware.com/article/which-software-is-affected-by-log4j-shell-vulnerability
List of products that have been affected by Log4j vulnerability: https://www.rumble.run/blog/finding-log4j/#affected-products-and-services
Due to a newly available Log4j patch covering it, fixing Log4Shell is technically simple. However, finding and patching the vast numbers of servers and third-party applications which use Log4j will be an immense task for countless impacted organizations. With many legacy programs approaching end of life, finding and applying patches may be almost impossible.
Many widely used frameworks use Log4j, including enterprise search platform Apache Solr and database platform Apache Druid. This makes the likelihood that any organization hosts a compromised application or server incredibly high. Even for C-based servers that are theoretically safe, a connected online form written in Java could lead to a compromise.
Log4j is a critical threat, and no organization should assume it is safe. Therefore, determining exposure to it and fixing vulnerabilities should be a high priority for most security teams. This means searching the entire IT state regardless of whether servers are using Windows, Linux, or Mac for any Java code and determining if it uses the Log4j library. There is a myriad of tools on the market to help detect intrusion attempts and help guard against attacks.
Wherever you find Log4j, you need to update it to the latest 2.15.0 version patch.
Here is a list of software that has an identified Log4j Shell vulnerability and the corresponding remedial measure. This list is current as of 2021-12-14
|IBM Qradar SIEM||TRUE|
|Speed camera LOL||TRUE|