Log4j is a library used by many systems around the world. The Log4j vulnerability, named Log4Shell, is hard to detect because it can be used directly or indirectly in systems you’re not even aware you have. According to Jen Easterly, the U.S Cybersecurity and Infrastructure Security director, Log4Shell is one of the most dangerous vulnerabilities recently discovered.
TL;DR; You need to update Log4j to a version >= 2.17.0. If you think you’ve been hacked, you can follow this playbook: https://www.trustedsec.com/blog/log4j-playbook/
The Role of Log4J
Log4j is an open-source application created by the Apache Software Foundation that can records any event, error, or routine system operations. In addition, it provides system administrators and users with diagnostic information describing the system. For example, whenever you type an inaccurate web link and receive the 404 error response, the system will often record this event in a log file using the Log4j software, that server administrators can then review. Additionally, online games like Minecraft utilize Log4j to log different activities like the user’s command entered in the console and the user’s memory.
How the Log4Shell Exploit Operates
The Log4Shell vulnerability affects a Log4j feature that allows system administrators to specify a custom format for the log message. Also, Log4j allows the use of a third-party library (JNDI) that can query an external server for information to include in the logs. When an actor with malicious intent can inject a custom format they controls, then can then force the JNDI library to query a server they control to return a specially crafted payload that gives them control of the server. Unfortunately, Log4Shell vulnerability exposes the system to destructive activities like theft of sensitive data, a complete control of the affected server and more.
Each Faulty Version’s CVE
The patches for Log4j got many false starts. At the moment I am writing these lines, It took 3 patches before we could consider the patch secure.
The first vulnerability is the CVE-2021-44228, a remote code execution vulnerability. The second is the CVE-2021-45046, also a remote code execution vulnerability, a bit more complex. These two vulnerabilities affects Log4j versions 2.0-beta9 to 2.16. Moreover, the CVE-2021-45105 is a specific vulnerability that causes a Denial of Service (DOS) attack on the affected system.
CVE Details
CVE-2021-44228
Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. 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. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0, this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.
Severity: Critical
Base CVSS Score: 10.0
CVSS: 3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVE-2021-45046
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in an information leak and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default.
Severity: Critical
Base CVSS Score: 9.0
CVSS: 3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
CVE-2021-45105
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0 and 2.12.3.
Severity: High
Base CVSS Score: 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
It is important to note that after everybody thought they were in control of the situation and on the path to having everything updated to the version 2.16.0 that fixed the two earlier vulnerabilities, another vulnerability was identified. This vulnerability causes a DoS attack due to a Stack-Overflow in the Context Lookups. These Context Lookups are present in the configuration file’s layout patterns. With a specially crafted payload, there is a infinite recursion that causes the application to crash.
It Really Affected Everyone
Since Minecraft administrators identified the first case of the Log4Shell vulnerability in Minecraft, several organizations, including Microsoft, have swiftly fixed this problem. In addition, TechCrunch identified other companies like Apple, Twitter, and Cloudflare as being vulnerable to the Log4Shell attack. The web monitoring service Greynoise identified that several hosts have started scrutinizing the Internet to identify vulnerable servers to the Log4J vulnerability.
One of the easiest ways you, as the system administrator, can mitigate this vulnerability is by updating your Log4j version to 2.17.0 or later. These versions have ensured the vulnerability behavior is disabled by default. For those using earlier versions, you can mitigate the issue by setting your system property log4j2.formatMsgNoLookups to true. This change is possible through adding the Java parameter: –Dlog4j2.formatMsgNoLookups=true. However, it is important to note that it is simply a mitigation and that bypass exists. The only way to be certain there are no problem is to update to the latest version (>= 2.17.0). Of course, update your Java distribution to the newest release. This updating process will ensure your system obtains the newly added security updates.
If you are developing software, you should use a tool to scan your code and it’s dependencies. Many tools exists to scan your software, like Synk Open Source, which allows you to identify the vulnerabilities present in your open source libraries, plus any case of a Log4j exposure.
Impact of the Log4j Vulnerability
Nowadays, hackers are constantly scanning the Internet, hoping to identify any server that is vulnerable to attacks. Once they identify a vulnerable server, they produce dangerous payloads to take control of them. For instance, a hacker can attack a web server and force it to log a carefully crafted payload. This attack will come with a dangerous text that the Log4j will identify as an instruction. Once it is recognized as an instruction, the hacker has managed to manipulate your system’s Log4j library and exploit the vulnerability.
The malicious instruction can then be used to control the targeted server remotely. They may also turn the target server into a bot in a botnet. The botnet utilizes several hijacked computers to perform coordinated actions. Or hackers could use this vulnerability to deploy ransomware.
The Belgian defense ministry had their systems affected by a Log4Shell attack.
Log4j Vulnerability Mitigation Steps
Different enterprises have started releasing patched software. It means we need to update all applications that use Log4j directly or indirectly.
Closing websites is another option many organizations rely on because it reduces the attack surface and the risk. This restriction ensures mitigations and patches can be deployed before hackers can remotely exploit the Log4j vulnerability.
As such, tackling this vulnerability will require coordination between several parties, including system operators, software developers/distributors and the Log4j developers, as they come up with the Log4j vulnerability fixes.
Feel free to leave your comment down here for any questions or comments.
