Business

‘Log4Shell’ vulnerability poses critical threat to applications using ‘ubiquitous’ Java logging package Apache Log4j

Published

on

UPDATED The maintainers of popular Java logging library Apache Log4j have rushed out a patch for a critical vulnerability that could lead to remote code execution (RCE) in numerous applications.

The relative ease of exploitation, attackers’ ability to seize control of targeted servers, and the ubiquity of Log4j make for a serious situation.

Dubbed ‘Log4Shell’ and credited to Chen Zhaojun of Alibaba, the vulnerability (CVE-2021-44228) has been assigned the maximum CVSS score of 10.

‘Comparable to Equifax’

“This new Log4j vulnerability is likely going to be another ‘flashbulb memory’ event in the timeline of significant vulnerabilities,” Brian Fox, CTO of DevSecOps specialist Sonatype, told The Daily Swig.

“It is the most widely used logging framework in the Java ecosystem. The scope of affected applications is comparable to the 2015 commons-collection vulnerability (CVE 2015-7501) because attackers can safely assume targets likely have this on the classpath.

“The impact is comparable to previous Struts vulnerabilities, like the one that impacted Equifax, because the attacks can be done remotely, anonymously without login credentials, and leads to a remote exploit. The combination of scope and potential impact here is unlike any previous component vulnerability I can readily recall.”

Sonatype has published a blog post examining the flaw and its implications.

Downstream impact

Versions 2.0-beta9 up to and including 2.14.1 are affected by the flaw.

The maintainers of Apache Log4j have today released a new version – 2.15.0 – within a day of the proof of concept (PoC) surfacing on Twitter and GitHub, along with mitigation steps for those unable to update immediately.

“Now it needs to flow downstream to Apache Struts2, Solr, Linux distributions, vendors, appliances etc,” tweeted British security specialist Kevin Beaumont.

Potentially vulnerable applications include any using Apache Struts, and iCloud, Steam, Twitter, Cloudflare, Amazon, and the Tesla website, according to a newly published GitHub repo.

“Although this emerged as a Minecraft issue (lol) there is going to be impacts across a wide range of enterprise software for some time,” added Beaumont.

Many open source projects have already addressed the issue in their own applications, according to Free Wortley and Chris Thompson, respectively CEO and developer at open source data security platform LunaSec.

Attack vectors

The pair have documented various exploits and other key information about the vulnerability in a blog post published yesterday (December 9) and are still posting updates as fresh details emerge.

Servers are vulnerable if they are running a vulnerable Log4j version and have an endpoint protocol that allows an attacker to send an exploit string and log statement that logs out the string from the request, they said.

Apache Log4j2 versions 2.14.1 and below fail to protect against attacker-controlled (Lightweight Directory Access Protocol) (LDAP) and other JNDI-related endpoints, according to the CVE description.

“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,” it says.

This behavior is no longer enabled by default in Log4j 2.15.0 and “users are strongly discouraged from enabling it”, the maintainers advise.

Java Development Kit (JDK) versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector, according to another blog post referenced by Wortley and Thompson.

However, other attack vectors exist that can result in RCE, included an attack targeting org.apache.naming.factory.BeanFactory, a class present on Apache Tomcat servers, as documented by Veracode in 2019.

Because such Java vulnerabilities are so common, security researchers have created tools, such as the marshalsec project, to exploit them, note Wortley and Thompson.

The pair recommend that security teams protect sensitive data by deploying tokenization.

Beaumont pointed out that the first fix, version 2.15.0-rc1, was bypassed, so users should apply log4j-2.15.0-rc2. He also observed: “Your JDK config may save you from exploitation, some distros ship secure configs by default.”

This article was updated on December 10 with additional comments from Brian Fox of Sonatype

Source: https://portswigger.net/daily-swig/log4shell-vulnerability-poses-critical-threat-to-applications-using-ubiquitous-java-logging-package-apache-log4j

Click to comment
Exit mobile version