Log4j update: risk assessed, denial-of-service bug fixed, and advice for boards.

Ransomware exploits Log4shell.

The first major ransomware strain to take advantage of Log4shell was newcomer Konsari, but a familiar player has now also been observed exploiting the vulnerability. Advanced Intelligence (AdvIntel) tells BleepingComputer that it's observed Conti seeking to use Log4shell to move laterally into VMware vCenter networks. “The current exploitation led to multiple use cases through which the Conti group tested the possibilities of utilizing the Log4J exploit,” BleepingComputer quotes AdvIntel as saying. Those servers aren't normally exposed to the Internet, and Conti's activity shows that networks are susceptible to attack via RDP, VPN, or email phishing vectors. Thus security teams should expand their focus to include these alternative avenues of approach.

"The call is coming from inside the house."

Says Bitdefender. The Log4j exploitation the company's honeypots have drawn show that most attacks are originating in Germany and the US. But that doesn't mean the threat actors are predominantly German or American. "[T]hreat actors exploiting Log4j are routing their attacks through machines that are closer to their intended targets and just because we don’t see countries commonly associated with cybersecurity threats at the top of the list does not mean that attacks did not originate there." Thus the honeypots reveal staging, not origin (and Bitdefender in this case has used its familiarity with slasher flicks to go effect: the call is coming from inside the house, but that doesn't mean the menace lives at that address). The geolocation of the targets is unsurprising, with the US, the UK, and Canada leading the pack. Rounding out the top ten are, in this order, Romania, Germany, Australia, France, the Netherlands, Brazil, and Italy.

Addressing the other, denial-of-service, vulnerability in Log4j.

Apache on Saturday introduced Log4j 2.17.0, a new version that addresses the denial-of-service risk posed by vulnerability CVE-2021-45105. The problem, now fixed in the latest release is that, as Apache put it, "Apache Log4j2 does not always protect from infinite recursion in lookup evaluation." The foundation goes on to explain:

"Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack."

And these are the available mitigations:

"Implement one of the following mitigation techniques:

• "Java 8 (or later) users should upgrade to release 2.17.0.

"Alternatively, this can be mitigated in configuration:

• "In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
• "Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input."

Jake Williams, CTO and co-founder of BreachQuest, commented on LOG4J2-3230, the second, lesser vulnerability that came to light last week. It's worth noting, he thinks, that the attention drawn by Log4shell led to the discovery of the denial-of-service vulnerability:

“This vulnerability was discovered because of additional attention paid to log4j by researchers after the original remote code execution bug was disclosed. We shouldn’t be surprised that additional vulnerabilities were discovered in log4j given the additional specific focus on the library. However, organizations should understand that this is only a denial of service (DoS) vulnerability and as such does not offer the threat actor any ability to steal data or implant a backdoor.

"Similar to log4j, this summer the original PrintNightmare vulnerability disclosure led to the discovery of multiple additional distinct vulnerabilities. The discovery of additional vulnerabilities in log4j shouldn’t cause concern about the security of log4j itself. If anything, log4j is more secure because of the additional attention paid by researchers. At this point the log4j code has been reviewed by orders of magnitude more researchers than any custom application deployed by an organization. In the coming weeks, the updated version of the log4j library will almost certainly be more secure than the code that uses it.”

His take on the bypass to the original 2.15.0 patches is that it won't prove to be much of a problem:

“While researchers have discovered a bypass to some fixes employed in log4j the 2.15.0 patches, unlike the original disclosures, this vulnerability is not exploitable in most configurations. This bypass should not concern teams that have already updated to 2.16.0. Even for those organizations that already patched to 2.15.0, this bypass is probably not exploitable in their applications. We continue to recommend limiting outbound communication on potentially vulnerable servers to only known-good destinations as that prevents code execution in both the originally disclosed vulnerability and this bypass.”

"Ridiculously widespread and incredibly dangerous."

That's Morphisec's summary risk assessment of Log4shell: "Many widely used frameworks such as enterprise search platform Apache Solr and database platform Apache Druid use Log4j. This makes the likelihood that any organization hosts a compromised application or server incredibly high. Even for C-based servers that are theoretically safe, a connected online form written in Java could lead to a compromise."

Google's Security Blog is equally grim, and applies some quantification to its assessment:

"More than 35,000 Java packages, amounting to over 8% of the Maven Central repository (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities (1, 2), with widespread fallout across the software industry. The vulnerabilities allow an attacker to perform remote code execution by exploiting the insecure JNDI lookups feature exposed by the logging library log4j. This exploitable feature was enabled by default in many versions of the library....

"As of December 16, 2021, we found that 35,863 of the available Java artifacts from Maven Central depend on the affected log4j code. This means that more than 8% of all packages on Maven Central have at least one version that is impacted by this vulnerability. (These numbers do not encompass all Java packages, such as directly distributed binaries, but Maven Central is a strong proxy for the state of the ecosystem.)

"As far as ecosystem impact goes, 8% is enormous. The average ecosystem impact of advisories affecting Maven Central is 2%, with the median less than 0.1%."

Contrast Security also offers some quantification of the risk. "64% of applications monitored by Contrast Security package log4j2 for logging," they write. "Furthermore, 30% of applications are packaging more than 1 logging library, often a combination of log4j2, log4j1, logback, and or a built-in JVM logger." And the vulnerability is widespread in the applications they keep track of: "58% of applications monitored by Contrast Security package a vulnerable version of log4j2. Some portion of the 26% of applications that package Log4j1 are also vulnerable if they’re using JMSAppender. The good news: Even though 58% of applications are packaging a vulnerable version, only 37% are actually using log4j2."

Felipe Tarijon, of Appgate Threat Research, wrote about the simplicity of exploitation Log4shell offers both criminals and intelligence services. Criminal activity so far has focused on botnets and ransomware:

"Since Log4Shell is a critical flaw with a huge attack surface and is very simple to exploit, threat actors are actively using it to launch their attacks even with a patch already released. Several state-sponsored groups are exploiting the flaw in the wild and making modifications to the Log4j exploit.

"We have seen several threat actors, not state-sponsored, exploiting the Log4J vulnerability. Botnets like Muhstik and a Mirai-variant, for example, were exploiting the flaw on Linux devices before it was publicly disclosed. Exploitation and post-exploitation activities were also observed, including the deployment of cryptocurrency miners like XMRIG and Cobalt Strike beacons used to exfiltrate data from compromised systems.

"More recently, a new Ransomware family targeting Windows OS emerged by exploiting the Log4J vulnerability in the wild. Named Khonsari, it's a lightweight .NET payload that contains only the basic functionality required to encrypt files. The Orcus Remote Access Trojan, active since 2016 and commercialized among threat actors, was also delivered during a Log4J exploitation attack.

"Besides all those threats, simple reverse shell command lines have been executed by exploiting the vulnerability as well, so basically, any threat actor can leverage this new vector in the wild. Including using exploit variants to bypass basic security protections on yet unpatched systems. Our team expects notorious Ransomware groups like Lockbit, Hive, Groove, and others to exploit it and breach new victims soon." -

BreachQuest's Williams thinks it's too early to assess the long-term effects of the Log4j vulnerabilities:

“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. Think of the log4j vulnerability like you would a stolen key to a deadbolt. If a threat actor gets the key, they can come back any time and wreak havoc inside the network until you change the lock. In this case though it’s a master key the fire department has for every municipal building in the city. In this analogy, the deadbolts that use the master key are the vulnerable log4j instances and changing the lock is applying the patch. Where this analogy breaks down is that the threat actor can use the key before the lock is changed and maintain access to the building after the lock is changed by dropping a backdoor. The eventual use of these backdoors is what is being alluded to. Organizations will need threat hunting and visibility tools to detect these potential intrusions. But once the backdoor is deployed, the only limits on impact are threat actor creativity and intent.”

What boards need to know, and consider.

Britain's National Cyber Security Centre (NCSC) has offered corporate boards advice on dealing with Log4j vulnerabilities. "The Log4j issue has the potential to cause severe impact to many organisations," NCSC writes. "As cyber security experts attempt to detect which software and organisations are vulnerable, attackers start to exploit the vulnerability. Initial reports indicate this is likely to include remote control malware and ransomware. However the situation is fluid and changing regularly."

The NCSC usefully frames its advice in the form of questions boards should ask corporate executives. They're worth quoting in full:

1. "Who is leading on our response? Log4shell is a critical incident that justifies a ‘tiger team’ of staff to address it. There should be a designated person leading the organisation’s response.
2. "What is our plan? Currently, most organisations will be responding to software found to be vulnerable, or to cyber attacks. There will likely be a migration to a more methodical approach which first identifies how the organisation is affected and then rectifies any problems found. Large organisations and enterprises will need a phased approach to manage this issue over many weeks or months, with teams able to sustain a response over the medium term.
3. "How will we know if we're being attacked and can we respond? Whilst lots of researchers are trying to detect issues on the internet, attackers are also working to exploit the vulnerability. Would your teams know if your organisation was being targeted, and be ready for an at-scale response?
4. "What percentage visibility of our software/servers do we have? Teams are hopefully trying to find instances of software, and of Log4j itself. This task will be easier on corporately-managed assets, but less so on unmanaged assets.
5. "How are we addressing shadow IT/appliances? As well as fixing corporately-managed assets, teams need to be thinking about how they will discover things that may have slipped through the net and are not centrally managed (often called ‘shadow IT’).
6. "Do we know if key providers are covering themselves? If your organisation is dependent on any particularly key suppliers (such as crucial software that runs your business, or a 3rd party with remote admin access to your organisation), you should have an open and honest conversation with them, acknowledging that they will also be trying to understand the severity of the issue.
7. "Does anyone in our organisation develop Java code? What is their plan for finding out if we are affected? Larger organisations may be producing Java code for internal use or as products (Log4j is frequently used in enterprise Java software). Java developers may have legitimately used Log4j, so it’s important to ensure that any software written is not vulnerable.
8. "How will people report issues they find to us? Many cyber security researchers are trying to detect vulnerable software. If they find something on your estate, can they contact you easily (for example, via a vulnerability disclosure process)?
9. "When did we last check our business continuity plans (BCP) and crisis response? Verify your organisation’s end-to-end BCP and crisis response processes to minimise real world impact to the organisation should an attack be successful.
10. "How are we preventing teams from burning out? Remediating this issue is likely to take weeks, or months for larger organisations. The combination of an ever evolving situation (and the potential for severe impacts) can lead to burnout in defenders, if they’re not supported by leadership."