The Apache Log4j vulnerability has made global headlines since it was discovered in early December. The flaw has impacted vast numbers of organizations around the world as security teams have scrambled to mitigate the associated risks. Here is a timeline of the key events surrounding the Log4j vulnerability as they have unfolded.
Thursday, December 9: Apache Log4j zero-day exploit discovered
Apache released details on a critical vulnerability in Log4j, a logging library used in millions of Java-based applications. Attackers began exploiting the flaw (CVE-2021-44228) – dubbed “Log4Shell”, which was rated 10 out of 10 on the CVSS vulnerability rating scale. It could lead to remote code execution (RCE) on underlying servers that run vulnerable applications. “An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled,” Apache developers wrote in an advisory. A fix for the issue was made available with the release of Log4j 2.15.0 as security teams from around the globe worked to protect their organizations. Businesses were urged to install the latest version.
Friday, December 10: UK NCSC issues Log4j warning to UK organizations
As the fallout from the vulnerability continued, the UK’s National Cyber Security Centre (NCSC) issued a public warning to UK companies about the flaw and outlined strategies for mitigation. The NCSC advised all organizations to install the latest update immediately wherever Log4j was known to be used. “This should be the first priority for all UK organizations using software that is known to include Log4j. Organizations should update both internet-facing and non-internet facing software,” the statement read. Businesses were also urged to seek out unknown instances of Log4j and deploy protective network monitoring/blocking.
Saturday, December 11: CISA director comments on “urgent challenge to network defenders”
Much like the UK’s NCSC, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) publicly responded to the Log4j vulnerability with director Jen Easterly reflecting upon the urgent challenge it presented to network defenders. “CISA is working closely with our public and private sector partners to proactively address a critical vulnerability affecting products containing the Log4j software library,” she said in a statement. “We are taking urgent action to drive mitigation of this vulnerability and detect any associated threat activity. We have added this vulnerability to our catalog of known exploited vulnerabilities, which compels federal civilian agencies – and signals to non-federal partners – to urgently patch or remediate this vulnerability. We are proactively reaching out to entities whose networks may be vulnerable and are leveraging our scanning and intrusion detection tools to help government and industry partners identify exposure to or exploitation of the vulnerability.”
CISA recommended asset owners to take three additional, immediate steps to help mitigate the vulnerability:
- Enumerate any external facing devices that have Log4j installed
- Ensure security operations centers are actioning every single alert on the devices that fall into the category above
- Install a web application firewall with rules that automatically update so that security operations centers (SOCs) can concentrate on fewer alerts
Tuesday, December 14: Second Log4j vulnerability carrying denial-of-service threat detected, new patch released
A second vulnerability impacting Apache Log4j was discovered. The new exploit, CVE 2021-45046, allowed malicious actors to craft malicious input data using a JNDI lookup pattern to create denial-of-service (DoS) attacks, according to the CVE description. A new patch for the exploit was made available which removed support for message lookup patterns and disabled JNDI functionality by default, with the Log4j 2.15.0 fix for the original flaw incomplete in certain non-default configurations.
“While CVE-2021-45046 is less severe than the original vulnerability, it becomes another vector for threat actors to conduct malicious attacks against unpatched or improperly patched systems,” Amy Chang, head of risk and response at Resilience, told CSO shortly after the flaw was discovered. “The incomplete patch to CVE-2021-44228 could be abused to craft malicious input data, which could result in a DoS attack. A DoS attack can shut down a machine or network and render it inaccessible to its intended users,” she added. Organizations were advised to update to Log4j: 2.16.0 as soon as possible.
Friday, December 17: Third Log4j vulnerability revealed, new fix made available
Apache published details of a third major Log4j vulnerability and made yet another fix available. This was an infinite recursion flaw rated 7.5 out of 10. “The Log4j team has been made aware of a security vulnerability, CVE-2021-45105, that has been addressed in Log4j 2.17.0 for Java 8 and up,” it wrote. “Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DoS (denial-of-service) attack.”
Apache also outlined the following mitigations:
- In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId}or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC)
- Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input
Monday, December 20: Log4j exploited to install Dridex and Meterpreter
Cybersecurity research group Cryptolaemus warned that the Log4j vulnerability was being exploited to infect Windows devices with the Dridex banking Trojan and Linux devices with Meterpreter. Dridex is a form of malware that steals bank credentials via a system that uses macros from Microsoft Word, while Meterpreter is a Metasploit attack payload that provides an interactive shell from which an attacker can explore a target machine and execute code. Cryptolaemus member Joseph Roosen told BleepingComputer that threat actors use the Log4j RMI (Remote Method Invocation) exploit variant to force vulnerable devices to load and execute a Java class from an attacker-controlled remote server.
