The Apache Log4j vulnerabilities: A timeline

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.

Wednesday, December 22: Data shows 10% of all assets vulnerable to Log4Shell

Data released by cybersecurity vendor Tenable revealed that that one in 10 of all assets were vulnerable to Log4Shell, while 30% of organizations had not begun scanning for the bug. “Of the assets that have been assessed, Log4Shell has been found in approximately 10% of them, including a wide range of servers, web applications, containers and IoT devices,” read a Tenable blog posting. “Log4Shell is pervasive across all industries and geographies. One in 10 corporate servers being exposed. One in 10 web applications and so on. One in 10 of nearly every aspect of our digital infrastructure has the potential for malicious exploitation via Log4Shell.”

The vendor warned that Log4Shell carries a greater potential threat than EternalBlue (exploited in the WannaCry attacks) because of the pervasiveness of Log4j across both infrastructure and applications. “No single vulnerability in history has so blatantly called out for remediation. Log4Shell will define computing as we know it, separating those that put in the effort to protect themselves and those comfortable being negligent,” it added.

Tuesday, January 4: FTC tells companies to patch Log4j vulnerability, threatens legal action

The Federal Trade Commission (FTC) urged U.S. organizations to patch the Log4Shell vulnerability immediately or risk facing punitive action from the agency. “When vulnerabilities are discovered and exploited, it risks a loss or breach of personal information, financial loss, and other irreversible harms. The duty to take reasonable steps to mitigate known software vulnerabilities implicates laws including, among others, the Federal Trade Commission Act and the Gramm Leach Bliley Act,” the FTC said. It added that it is critical that companies and their vendors relying on Log4j act now to reduce the likelihood of harm to consumers and to avoid FTC legal action. “The FTC intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future.”

Full article attribution is made to its original source and author.