Several days have passed since the dramatic reveal of CVE-2021-44228 (aka Log4Shell), an easily exploitable (without authentication) RCE flaw in Apache Log4j, a popular open-source Java-based logging utility that’s seemingly used by most enterprise applications out there.
The existence of the vulnerability and the public release of PoCs exploiting it have made this weekend a nightmare for those that are tasked with mitigating its fallout and keeping company systems and networks secure.
Log4Shell update: What have we learned since the big reveal?
First and foremost, it affects only versions 2.x of Apache Log4j (i.e., Apache Log4j 2). To be more precise, it affects versions from (and including) 2.0-beta9 to 2.14.1.
“The vulnerability is in the JNDI lookup feature of the log4j library. While the background around this is very complex, exploitation actually is not,” says SANS handler Bojan Zdrnja.
“The JNDI lookup feature of log4j allows variables to be retrieved via JNDI – Java Naming and Directory Interface. This is an API that that provides naming and directory functionality to Java applications. While there are many possibilities, the log4j one supports (AFAIK) LDAP and RMI (Remote Method Invocation). In other words, when a new log entry is being created, and log4j encounters a JNDI reference, it will actually literally go to the supplied resource and fetch whatever it needs to fetch in order to resolve the required variable. And in this process, it might even download remote classes and execute them!”
The exposed attack surface
“Not all software using Java is vulnerable. Only software that includes the log4j2 library is vulnerable,” noted Dr. Johannes Ullrich, Dean of Research at the SANS Technology Institute.
“Exploitability depends on the Java version and how log4j2 is used. Not all software using log4j2 is vulnerable.”
Successful exploitation will depend “on several pre- and postconditions such as the JVM being used, the actual configuration, etc.,” the Swiss Government CERT explained, and advised defenders on what to do.
Many companies have started investigating whether their software is vulnerable, and some have already shared their findings (and are either working on patches or have released them already): Oracle, VMware, IBM (WebSphere Application Server is affected), Jamf, Cisco…
The logging library is used in Apache Druid, Apache Flink, Apache Solr, Apache Spark, Apache Struts2, Apache Tomcat and possibly other open-source applications / frameworks developed by teams under the Apache Software Foundation.
Don’t underestimate the attack surface of the Remote code injection in Log4j .
Just checking @github dependencies it’s already 1844 repositories.https://t.co/1FcX1LA9pc pic.twitter.com/LBLYgy5Zpj
— CIRCL (@circl_lu) December 10, 2021
There’s a community-curated list of vulnerable software and it will surely keep expanding in the coming days.
Dr. Richard Ford, CTO at Praetorian, told Help Net Security that the company’s engineers and researchers have been scanning its customers and are finding vulnerabilities in the field – and inadvertently discovering the vulnerability in third parties who are on adjacent or integrated systems.
“Naturally, we are following responsible disclosure policies so cannot call out these systems by name, but it is one of the largest exposures we have seen at Internet scale. All vulnerabilities are typically scored by how dangerous they are: this vulnerability has practically the highest score possible, and it seems likely that even some professionals are unaware of its potential impact. The situation is rapidly evolving, and we are learning a great deal about the scope and impact of this vulnerability as we quickly work with customers to help mitigate the risk in the short term while they work on a long term solution, which will require patching all instances of the vulnerable code – a process which could take months,” he added.
Tenable CTO Renaud Deraison says they are discovering new apps every minute which use Log4j in one way or another.
“It affects not only the code you build, but also the third-party systems you have in place. Everything from the new printer you’ve bought for the office to the ticketing system you’ve just deployed is potentially affected by this flaw. Some affected systems may be on premises, others may be hosted in the cloud but no matter where they are, the flaw is likely to have an impact,” he noted.
“To give you a sense of the sheer scope: already, we at Tenable are seeing customers auditing 1,000 systems per second and identifying one affected system per second.”
Attacks in the wild
Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC. That suggests it was in the wild at least 9 days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure.
— Matthew Prince 🌥 (@eastdakota) December 11, 2021
Microsoft’s unified threat intelligence team said on Saturday that they mostly observed attackers scanning for the flaw, but that exploitation and post-exploitation activities have also been observed.
“Based on the nature of the vulnerability, once the attacker has full access and control of an application, they can perform a myriad of objectives. Microsoft has observed activities including installing coin miners, Cobalt Strike to enable credential theft and lateral movement, and exfiltrating data from compromised systems.”
Others have confirmed attackers exploiting CVE-2021-44228 to deliver coin miners.
#log4shell log4j attempts have largely been spray-and-pray. Recently @GreyNoiseIO observed payloads tailored for specific applications.
Get some rest tonight, it’s only the beginning.— remy🐀 (@_mattata) December 12, 2021
But the situation might deteriorate soon, as apparently a worm exploiting the flaw is in the works and might be soon used by cyber criminals:
#Log4J based on what I’ve seen, there is evidence that a worm will be developed for this in the next 24 to 48 hours.
Self propagating with the ability to stand up a self hosted server on compromised endpoints.
In addition to spraying traffic, dropping files, it will have c2c
— Greg Linares (@Laughing_Mantis) December 12, 2021
Honestly I’m kinda surprised it isn’t finished yet, but I have seen at least 3 groups (Eastern euro, .ru and .cn) that are investigating options to do this.
Goals appear varied: financial gain via extortion as well as selling access to compromised hosts to RaaS groups
— Greg Linares (@Laughing_Mantis) December 12, 2021
What can defenders do?
Discovering vulnerable applications comes first.
Huntress security researchers have created a tool to help you test whether your applications are vulnerable. Other methods are also available.
The best way to mitigate the risk of exploitation is to implement patches, but since many vendors are still working on them – and the Log4j patches are still just release candidates – a good first step is to implement the advised mitigations.
Cybereason researchers have also developed and released a “vaccine” for the vulnerability that can help with temporary mitigation (though there are limitations, and this option should not be a final solution).
“In short, the fix uses the vulnerability itself to set the flag that turns it off. Because the vulnerability is so easy to exploit and so ubiquitous—it’s one of the very few ways to close it in certain scenarios,” Cybereason CTO Yonatan Striem-Amit explained.
This is a “vaccination” for the log4j vulnerability
Given a vulnerable piece of software, it exploits the log4j vulnerability, just to install a new piece of code that prevents exploiting it in the future
Ethical?https://t.co/vf9fewU7QK
— Daniel Feldman (@d_feldman) December 11, 2021
Sonatype has additional advice for mitigation for developers, users, and operators of software using Log4j.
Recommendations provided by the Swiss Government CERT, Fox-IT, and Cisco Talos are also helpful, as they cover both mitigation, remediation, and exploitation detection.
Credit: Source link
