A maximum-severity vulnerability has been identified in Apache Log4j, an open-source Java-based logging library used by many thousands of organizations in their enterprise applications and by many cloud services.
The vulnerability, dubbed Log4Shell and tracked as CVE-2021-44228, is serious as they come, with some security researchers claiming the flaw is the most serious to be discovered in the past decade due to its ease of exploitation and the sheer number of enterprise applications and cloud services that are affected.
The vulnerability can be exploited without authentication to achieve remote code execution and take full control of vulnerable systems. The vulnerability affects Apache Log4j between versions 2.0 to 2.14.1, and has been fixed in version 2.15.0.
The advice is to ensure the upgrade is performed immediately as a proof-of-concept exploit for the flaw is in the public domain, extensive scans are being performed for vulnerable systems, and there have been many cases of the flaw being exploited in the wild. Some reports suggest the improper input validation bug has been exploited in the wild for some time before it was discovered by researchers at Alibaba Cloud on November 24.
The vulnerability was first detected being exploited against Minecraft, which still uses Java, although many web apps and business applications use Java and are vulnerable to attack and the vulnerability affects multiple Apache frameworks such as Apache Struts2, Apache Solr, Apache Druid, and Apache Flink, and others.
The vulnerability can be exploited by manipulating log messages to execute arbitrary code from LDAP servers when message lookup substitution is enabled. This is a Java deserialization issue due to the library making network requests through the Java Naming and Directory Interface (JNDI) to an LDAP server and executing code that’s returned. By manipulating the log messages to trigger a look-up to an attacker-controlled server, an attacker can execute code on the victim’s system. Exploiting the bug requires the attacker to get a vulnerable application to log a special string, which is trivial for threat actors and requires a single line of code.
According to UK security researcher Marcus Hutchins, threat actors attacked Minecraft servers by simply pasting a short message into the chatbox. The bug is known to have been exploited to deploy cryptocurrency miners, to install botnet code on IoT devices, and initial access brokers have been scrambling to exploit the code, so it is inevitable that it will provide the initial access to allow ransomware attacks.
“I cannot overstate the seriousness of this threat. On the face of it, this is aimed at cryptominers but we believe this creates just the sort of background noise that serious threat actors will try to exploit in order to attack a whole range of high-value targets such as banks, state security, and critical infrastructure,” explained Lotem Finkelstein, director of threat intelligence and research at Check Point.
If it is not possible to immediately update to version 2.15.0, there are mitigations that can prevent exploitation in version 2.10.0 and later. A vulnerability “vaccine” has been released by Cybereason that can be used to protect against exploitation by using the vulnerability to run code that changes the settings to prevent further exploitation. The vaccine could be used to gain some time, although the best option is to update to the latest Apache Log4j version.
The vulnerable code could be anywhere, so fixing the issue is not likely to be straightforward, although Huntress has released a tool that can be used to check if applications are affected – available here.
Mitigations that can be applied if the update cannot be easily performed have been released by Apache. “In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.”
Since there have been many cases of the flaw being exploited, it is important to not only fix the vulnerability but to also assume the flaw has already been exploited and to check logs for any unusual activity after systems and applications have been secured.
The post Max-Severity Apache Log4j Zero-day Vulnerability Extensively Exploited in the Wild appeared first on HIPAA Journal.