Since December 1, 2021 a vulnerability linked to the open-source logging library Apache Log4j 2, has been actively exploited, impacting countless digital products and services globally.
To help you become rapidly informed about this event, its implications, and how to respond, we've summarized the important details of Log4Shell in this post.
A Summary of the Log4Shell Vulnerability
A critical security flaw in the Log4j framework is allowing cybercriminals to compromise vulnerable systems with just a single malicious code injection.
The vulnerability is associated with the user activity logger known as Log4J - a logging library freely distributed by the Apache Software Foundation.
Java is implemented across a wide range of digital products including cloud solutions, web servers, and apps making each of these products vulnerable to exploitation through the Log4Shell vulnerability.
Because this security flaw is so widespread and most organizations are unaware that they're impacted, an exploitation frenzy is currently underway in the cybercriminal world. Security researchers have identified approximately 10 million Log4Shell exploitations attempts every hour.
The retail industry is suffering the highest number of attacks, followed by technology, financial services, and manufacturing services.
Healthcare providers are also on high alert given the industry's long-standing reputation for suffering cyberattacks.
The map below shows the regions Log4Shell exploitation attempts have been made and the density of these attacks. The highest targeted regions are the United States, the United Kingdom, Germany, Turkey, and the Netherlands.
How to Fix the Log4j Problem
The recency of this vulnerability, coupled with its maximum CVSS score of 10, means it will take some time before a reliable patch of this exposure is developed.
In the meantime, response teams should follow this protection and remediation protocol to help manage the vulnerability.
1. Update to the latest version of the Log4j Library
The quickest, and currently most effective, mitigation response is to upgrade all instances of Log4j to the latest version - Log4j 2.17.1 (download the latest Apache Log4j version here).
According to Apache, the vulnerability CVE-2021-45105 is fixed in its latest library version. This should prevent future attacks but it will not remediate any damage caused before the library upgrade.
Because this vulnerability is so widespread, it is safest to assume that your ecosystem was compromised prior to a library upgrade and to initiate data breach incident responses immediately.
Even entities that don’t utilize Apache log services should assume a data breach because the impact of this zero-day couple potentially impacts the entire attack surface.
Learn more about the assume breach mentality.
In addition to an assume breach mentality, all server logs should be reviewed for Indicators of Compromise (IOC) as detailed the following resources:
2. Use the UpGuard Log4j Vulnerability Scanner
UpGuard has developed a domain and IP scanner that rapidly discovers entities impacted by CVE-2021-44228.
The scanner works by sending a string within the URL of an HTTP GET request to every domain and IP address being scanned.
Vulnerable Log4j libraries are confirmed when a benign LDAP connection to a secure server is established.
If all outbound connections a blocked, the source of failed attempts to connect to UpGuard’s secure LDAP server in your outbound proxy/firewall is confirmed as vulnerable to the zero-day.
To see the UpGuard Log4j vulnerability scanner in action, click here.
3. Change Java System Properties
If upgrading to the latest Log4j version isn’t possible, security teams should implement the following response immediately for versions 2.10 to 2.14.1:
Either set the following system property to true:
log4j2.formatMsgNoLookups
Or set the following environment variable to true:
LOG4J_FORMAT_MSG_NO_LOOKUPS
4. Disable JNDI
A design flaw in the JNDI Lookup plugin is primarily to blame for this critical vulnerability. JNDI facilitates code execution based on data found in the log, data that can easily be manipulated since its accepted by the logger without sanitation.
It has recently been discovered that the JNDI Lookup plugin has always permitted unparsed information to be sent to the Log4j library, ever since its release in 2013.
This is why CVE-2021-44228 can be exploited by a single string injection.
Once injected, the logger will consider the operation embedded in the string as part of its original codebase and instantly execute it.
By disabling the JndiLookup class, the logger will be unable to take action based on data found in the log. JNDI is disabled by default in version 2.16.0 of Log4j
Vulnerable versions of Log4j can also be secured by removing JndiLookup class from the following classpath:
zip -q -d log4j-core- *.jar org /apache/logging /log4j /core/lookup /JndiLookup.class
5. Send Apache Log4j Questionnaire to Vendors
UpGuard’s Apache Log4j questionnaire helps security teams discover third-party vendors that are using software or cloud services impacted by the Log4j vulnerability, either directly or via supply chains.
To see this questionnaire in action, click here.
6. Update all Firewalls and Intrusion Prevention Systems
Update all Next-Generation firewalls, Web Application Firewalls, and Intrusion Prevention Systems with the latest rules and signatures. The patches could filter or block LDAP and RMI traffic attempting to reach malicious LDAP servers.
7. Implement Multi-Factor Authentication
General sanitation practices like multi-factor authentication and strict VPN policies could impede the success of data breaches if an attacker manages to achieve network access through the Apache Log4j vulnerability,
8. Use the Huntress Log4Shell Vulnerability Tester
Huntress has created a scanning tool to test if any commonly logged processes or data passed through APIs are impacted by the Log4Shell vulnerability. The source code can be downloaded from GitHub here.
By using both scanners, you will have a greater chance of discovering the border impacts of the Log4j vulnerability.
For additional recommendations for protection measures against this zero-day threat, refer to this post by the Cybersecurity and Infrastructure Security Agency (CISA).
What is CVE-2021-44228?
The original Apache Log4j vulnerability (CVE-2021-44228), also known as Log4Shell, is a cybersecurity vulnerability on the Apache Log4j 2 Java library.
This security flaw is a Remote Code Execution vulnerability (RCE) - one of the most critical security exposures.
Because the original Log 4j vulnerability has the most critical threat rating of CVSS 10 - a rating that is rarely assigned - a single patch attempt is unlikely to resolve all of the logger's security issues, especially when almost every cybercriminal in the world is trying to circumvent defenses to one of the largest exploits of the internet era.
Four patches have been attempted, and so far, two of them have been found to include security vulnerabilities. Each new vulnerability is assigned a separate CVE identity starting from the original zero-day exploit.
Below is an up-to-date chronological list of CVEs associated with the Log4j vulnerably:
- CVE-2021-44228 - this is the tracking identity for the original Log4j exploit
- CVE-2021-45046 - the tracking identity for the vulnerability associated with the first Log4j patch (version 2.15.0). According to Apache's security advisory, version 2.15.0 was found to facilitate Denial of Service attacks by allowing attackers to craft malicious input data using a JNDI lookup pattern.
- CVE-2021-45105 - the tracking identity for the vulnerability associated with the second Log4j patch (version 2.16.0) after it was found to allow attackers to control over Thread Context Map data to cause a denial of service when a crafted string is interpreted.
- CVE-2021-44832 - the tracking identity for the vulnerability impacting all versions of Apache Log4j 2 (excluding 2.32 and 2.12.4). This security flaw places all vulnerable versions at risk of Remote Code Injection (RCE)
All of the above security risks are addressed in the latest Log4J version - version 2.17.1 (download version 2.17.1 here).
For additional information, see Apache's full disclosure here.
How Does the Log4j Cyber Attack Work?
The Log4Shell vulnerability allows hackers to remotely inject arbitrary code into a target network and assume complete control of it.
To understand the cyberattack sequence, it’s important to first understand how loggers operate.
Without a logger library like Log4j, information from servers is instantly archived after collection.
But if logged data is actively analyzed, or if certain actions in response to specific log data are required, Java software developers may use a library like Log4j to parse logs before they’re archived.
Any business that uses a vulnerable Log4j library to parse log data in their backend systems is vulnerable to a Log4j cyberattack.
This logger is capable of executing code based on input, and because the vulnerability allows attackers to manipulate input data, the logger could be forced to execute malicious code.
In technical terms, the vulnerable Log4j library, when passed a specially crafted string, will call out to an LDAP server, download the code hosted in the LDAP directory, and then execute that code. This allows cybercriminals to create a malicious LDAP server that stores code designed to take-over any server where it is executed, and then send applications/databases/APIs the string that points to their code.
Why is Log4Shell so Critical?
CVE-2021-44228 is considered by many security experts to be one of the worst exposures in the history of digital technology.
This audacious sentiment is supported by two factors:
1. CVE-2021-44228 is extremely easy to exploit
To exploit the vulnerability, a threat actor only needs to insert a string into a common log event to then inject a malicious payload.
This process requires very little skill and many exploitation attempts have already occurred since the vulnerability's discovery on December 5, 2021.
To witness the speed of exploitation, take a look at the following proof-of-concept demonstrating an attack on a Minecraft server.
2. Any Java Software Could Be Impacted
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. An estimate of a few billion instances would be considered conservative.
This is because Java is embedded into many digital products and services including:
- Internet routers
- Enterprise software
- Microsoft, Amazon, AWS, and Twitter servers
Even phones are potentially vulnerable. Though they don’t directly run Java, their backend systems likely communicate with the Log4j library via APis. So a malicious string sent to an iPhone could get injected to its backend, leading to compromise.
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.
Even if none of your web applications and back-end software are running vulnerable Log4j versions, your third-party vendors might be, which then exposes your 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 we've seen to date.
There are two historical security breaches that could be compared to the potential impact of the Apache Log4j vulnerability.
- The Equifax data breach was facilitated by Apache Struts vulnerability CVE-2017-5638, where 147 million people were impacted.
- ShellShock (known as Bashdoor) is a family of security bugs impacting Unix Bash Shell. When exploited, ShellShock bugs could allow attacks to force Bash to execute malicious commands. The similar attributes between Bashdoor and Log4Shell suggest the two cyber risks might be part of the same family of vulnerabilities.
Which Versions of Log4j 2 are Impacted?
All versions of Log4j prior to version 2.17.0 are potentially impacted by the Log4j exploit. Every entity that uses Log 4j must immediately upgrade to the latest Apache library version - 2.17.1
Log4j version 2.17.1 can be downloaded here.
Log4j 1 is no longer supported, and as a result, its vulnerabilities will not be addressed with future patch releases. All endpoint instances of this version should immediately be updated to version 2.17.1
Which Products are Impacted?
The top 10 vendors that have been impacted by Log4Shell are listed below. Each listed entity links to documentation explaining the security responses of the impacted provider.
For the complete list of products and cloud services impacted by the Log4j vulnerability, refer to this post. If your company uses any of these products, be sure to update them with the latest patches immediately.
Even if none of these solutions are used internally, you could still be at risk. If any of your vendors are using a solution impacted by the Log4Shell vulnerability, your business could fall victim to a supply chain attack.
Vendor Risk Management strategies help evaluate the potential of such third-party breaches through attack surface monitoring solutions and security questionnaires specifically addressing cyber threats like the Log4Shell zero-day exploit.
