Due to the extraordinary widespread use of the open-source Apache Log4j library, the saga of the Log4Shell (CVE-2021-44228) vulnerability is nowhere near finished.
As Dr. Johannes Ullrich, Dean of Research at the SANS Technology Institute, recently noted, “Log4Shell will continue to haunt us for years to come.”
His advice? “Dealing with Log4Shell will be a marathon. Treat it as such.” So let’s see what’s the latest news that can impact your mitigation and remediation efforts.
New versions of Log4j
The recent discovery of a second Log4j vulnerability (CVE-2021-45046) has shown that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.
This vulnerability could allow attackers to craft malicious input data using a JNDI Lookup pattern, resulting in a denial of service (DoS) attack.
“Note that previous mitigations involving configuration such as to set the system property ‘log4j2.noFormatMsgLookup’ to ‘true’ do NOT mitigate this specific vulnerability,” the Apache Log4j security team noted.
“Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (Active exploitation
PoCs are constantly popping up on GitHub and getting forked. GitHub is steadily working on removing them, but the proverbial cat is now out of the bag, and there is no going back.
Exploitation attempts detected so far in the wild can be tied to ransomware groups and access brokers, botnet herders (delivering coin miners), and nation-backed APTs.
As we continue to monitor threats taking advantage of the CVE-2021-44228 Log4j 2 vulnerability, we’re seeing activity ranging from experimentation to exploitation from multiple groups, including nation-state actors and access brokers linked to ransomware: https://t.co/WWSxGvaiDy
— Microsoft Security Intelligence (@MsftSecIntel) December 15, 2021
Most common attempted env stolen have been:
AWS credentials
Docker creds
Hadoob installsRansomware payloads: 4%
Cryptominer payloads: 22%
Info stealer payloads: 61%
Unknown payloads: 13%JDNI gadget payloads: 23%
Spray N Pray Headers: 70%
Single Attempt: 21%
Other: 9%— Greg Linares (@Laughing_Mantis) December 15, 2021
Bitdefender and F-Secure researchers have detailed the various malicious payloads delivered after the successful exploitation of Log4Shell: coin miners, RATs, ransomware, etc.
As noted by Sean Gallagher, Senior Threat Researcher at Sophos, “adversaries are likely grabbing as much access to whatever they can get right now with the view to monetize and/or capitalize on it later on.”
Log4Shell mitigation
The attack surface is extremely wide, and Check Point researchers have spotted at least 60 variations of the original exploit code used against vulnerable machines.
Through its agentless device security platform, Armis has detected Log4Shell attack attempts in over a third of their clients, and are continuing to see new attacks every day. Most of these are against physical and virtual servers and IP cameras, but they have also spotted attack attempts to manufacturing devices (HMI Panels & Controllers) and attendance systems (Kronos).
Source: Armis
“The way modern products are built is using a big hierarchy of dependencies, where developers use libraries written by third-party companies and engineers to speed up the software release process. Log4J is an extremely basic library that allows log writing in Java applications. The way CVE-2021-44228 affects comes in 3 layers – cloud products that directly use the Log4J, web applications that use libraries that use Log4J, and off-the-shelf software which is internally deployed on customer servers and endpoints,” says Michael Assraf, CEO at Vicarius.
“As fixing and deploying cloud applications can be fast, updating libraries that use Log4J can break functionality unless done with caution. The most problematic fixes are internally deployed software, which will have to wait for a vendor update or a security patch, in that scenario customers are advised to wait on further vendor guidance and as of right now are helpless in reacting. Examples include: Elasticsearch, Intellij IDE, Jira Confluence, Apache Tomcat, Minecraft, Apache Hadoop, Eclipse IDE, and many more.”
Gallagher says that the most immediate priority for defenders is to reduce exposure by patching and mitigating all corners of their infrastructure and investigate exposed and potentially compromised systems.
“Where systems have been identified as vulnerable, defenders should run an incident response process and monitor for signs of remote access trojans such as C2 call-backs. Secrets stored on exposed systems should also be rotated, particularly if they are exposed in environment variables. Lastly, consider critical third party vendors who may also be at risk,” he advised.
Mathew Eble, VP of Services at Praetorian, also warned the issue will be prone to false negatives.
“Externally there is no way to cover all the possible paths that exploitation can take. Even when external scanning tools get more sophisticated in how they identify the issue, we strongly advocate not relying on scan results as strong indicator of your risk,” he noted.
This recommendation is based on four issues the company has confirmed when working with customers. Based on this, they have expanded their initial recommendations for defenders.
Security professionals dealing with the situation in their organizations are also advised to check out CISA’s expanding list of affected and non affected solutions. Other similar lists are available here and here.
Credit: Source link
