Just when we thought we were through the significant bits of Log4j issues, a new problem appeared this past weekend. The good news is that with a lot of smart people looking at the issues, it means that researchers are doing their best to find any faults, and the Apache team is doing a great job at rolling out updates.
Since 10 December 2021, we’ve been staying on top of everything Log4j. We brought you a blog and podcast on the initial vulnerability, CVE-2021-44228, and an update on the second vulnerability, CVE-2021-45046. While we were all really hoping this was it, for now, there’s now a third vulnerability, CVE-2021-45105, that came to light on 17 December 2021.
The latest vulnerability, which can be fixed by updating to version 2.17.0, as detailed here, is the result of a flaw in how input could be used maliciously to create a stack overflow error that causes denial of service. There’s very specific criteria to this one, and we’ve published an intelligence update for our customers with the latest findings.
What’s up with the newest vulnerability?
Researchers discovered that flaws with how context lookups work within Log4j created the right conditions for denial of service. In the latest update from Apache, users of Apache Log4j on Java 8 or later should update their installations to version 2.17.0. As of the time of writing, there is no impact to 1.x versions of Log4j. According to Apache’s guidance, other versions of Log4 projects are not affected, and it can also be mitigated by updating the context lookup functionality. Research from Zero Day Initiative indicates that the best mitigation for those with affected versions should be to update to the latest version.
What’s happening with Log4Shell?
The initial vulnerability, CVE-2021-44228 (known as Log4Shell), is already under active exploitation, so if you’re running anything between versions 2.10 and 2.14, you should start looking into updating as soon as possible to the latest version. According to the latest from Bleeping Computer, the Conti ransomware group is already using it to attack VMware applications, focusing on internal networks, which often get overlooked or underprioritized compared to externally-facing devices. Conti has typically shown proficiency with getting into networks using a variety of attacks and is now using Log4Shell to move during the post-exploitation phases, namely lateral movement.
In addition to Conti, the previously little-known Khonsari ransomware group got their recent notoriety by being among the first to exploit Log4Shell. Here at Digital Shadows, we’ve seen plenty of cases where various actors share exploits and advice on forums and based on the chatter, there are plenty of others who are interested. Since it becomes somewhat complicated to discover vulnerable assets and roll out patches, criminal groups (and likely nation-states) are banking on this and subsequent vulnerabilities keeping networks open for a time.
The US CISA has also advised all US federal agencies to patch immediately and report anything and everything related to vulnerable infrastructure or applications, as detailed here.
One last callout here from Google should be noted. As part of their ongoing research into this vulnerability, finding the dependencies between various packages and applications will be difficult. Google’s research has shown that there are over 35,000 Java packages impacted in some way by Log4j.
Jake Williams, CTO at BreachQuest, highlighted a key thought in The Hacker News: “There will likely be some time before we understand the full fallout of the log4j vulnerability, but only because it’s embedded in so much software. This has nothing to do with threat actor malware. It has to do with the difficulty in finding the myriad places the library is embedded. The vulnerability itself will provide initial access for threat actors who will later perform privilege escalation and lateral movement – that’s where the real risk is.”
Hopefully, a light at the end of the tunnel
We definitely want to send good vibes to the researchers bringing us the good stuff, the IT teams out there working on patching and mitigations, and the security teams keeping the wolves at bay. We thought the year would end quietly, but fate had another idea. While this probably couldn’t have happened at a worse time, as we said before, there are a lot of great minds trying to solve the problem. We will continue to monitor both the dark web and open media reporting to hopefully bring more context and understanding to the Log4j problems as they arise.
If you are a Digital Shadows customer, we will continue to publish updates as needed and hopefully bring some clarity to all of this, as shown below. For those on the front lines, we hope you get time to rest, reset, and hopefully make it through the holidays in one piece.