On November 24th a critical vulnerability (zero-day vulnerability) in Log4j was reported to Apache. It was later (10th December) made public under the name Log4Shell (CVE-2021-44228); it can be exploited effortlessly remotely and allows an attacker to execute his own code (RCE). Among others, Amazon, Apple, Tesla, Twitter, Steam, etc. were successfully attacked. Due to the ease of exploitation and severe consequences, the BSI (German Federal Office for Information Security) has already issued the highest warning level “red” on Saturday the 11th of December.
Contents
- Discovery of the vulnerability
- Who is affected?
- Exploiting Log4j
- Recommendations for protecting your systems
1. Discovery of the vulnerability
CVE-2021-44228, also called Log4Shell, is a remote code execution vulnerability. If attackers manage to exploit the vulnerability on a server, they are able to execute arbitrary code and can potentially take control of the complete system.
The CVE-2021-44228 vulnerability is particularly dangerous because the exploit is so simple that even inexperienced attackers can perform a successful attack exploiting this vulnerability. It is enough for the attacker to force the application to write a single line in the log. After that, the attacker can upload his own code. This is possible because of the lookup plugin function.
Feasibility studies, or proofs of concept (PoC) for the attacks exploiting the CVE-2021-44228 vulnerability are already publicly available. Therefore, it is not surprising that cybersecurity companies have already registered massive network scans for this vulnerability and there have been many reported attacks on production systems.
This vulnerability was discovered by Chen Zhaojun, a member of the Alibaba Cloud Security Team.
2. Who is affected?
All versions before 2.15.0 (December 6, 2021) are affected. A wide range of products that include these old versions of Log4j are also vulnerable. A constantly updated list of these can be found here. While version 1 is not vulnerable to the recently discovered Zero-Day Vulnerability, it is vulnerable to RCE and you should upgrade it to the latest version 2.16.0 immediately.
An attack is usually only detected when it is too late – for example, when there is an extortion demand. But before that, you usually don’t recognize it; the attack runs in the background. Unless you have prepared your infrastructure to specifically detect cyberattacks through monitoring.
To check if your servers are vulnerable, feel free to use our script.
3. Exploiting Log4j
The Log4j vulnerability can be exploited by sending specially crafted log messages to Log4j. An attacker uses the Java Naming and Directory Interface (JNDI) — 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 URLs to resolve a specific directory service — and the URI can be customized as needed to resolve the correct directory location. When using Log4j, it is possible for an attacker sending a message with a specially crafted URL to execute arbitrary code (e.g., by providing a Base64-encoded script in the path). Here, the attacker’s sent payload is stored in a log by Log4j and is considered code due to improper input validation.
This is due to a special behavior in Log4j that allows variable data injection into the log (called lookups). In a lookup, the reference is queried and evaluated for input to the log. When the attacker uses this feature during an attack, he uses the URI input to tell Log4j to resolve an object he entered (such as an encrypted script). The description of the new vulnerability, CVE 2021-45046, says that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 “was incomplete in certain non-default configurations.”. This problem was therefore completely fixed only in Log4j 2.16.0.
4. Recommendations for protecting your systems
This image shows the attack process.
There are several ways to secure your systems against the log4shell vulnerability. The easiest way would be to patch version 2.16.0 of log4j. This closes the attack vector and the system is no longer vulnerable via the zero-day vulnerability log4shell. However, if this is not possible immediately, the property “No Lookups (log4j2.formatMsgNoLookups)” should be set to true to prevent an attack. If you have a vulnerable version, or have had a vulnerable version, attackers may have implemented one or more backdoors into your system. For this reason, you should immediately run an analysis that checks your system for backdoors and whether attackers have already hacked into your system.
Read about other interesting topics on our blog.