Log4j vulnerabilities: new patches and nation-state exploitation.

More nation-state exploitation of Log4shell was detected as 2021 wound down to its close last week. The Apache Foundation addressed the fifth vulnerability in Log4j, and Microsoft issued a new service designed to protect customers from Log4j exploitation.

Aquatic Panda attempts Log4shell exploitation.

On December 29th CrowdStrike reported finding evidence that a nation-state intelligence service was exploiting Log4shell in what the firm characterized as "suspicious activity stemming from a Tomcat process running under a vulnerable VMware Horizon instance at a large academic institution, leading to the disruption of an active hands-on intrusion." The nation-state was China, and the specific threat group is the one tracked as Aquatic Panda.

The researchers explain, "AQUATIC PANDA is a China-based targeted intrusion adversary with a dual mission of intelligence collection and industrial espionage. It has likely operated since at least May 2020. AQUATIC PANDA operations have primarily focused on entities in the telecommunications, technology and government sectors. AQUATIC PANDA relies heavily on Cobalt Strike, and its toolset includes the unique Cobalt Strike downloader tracked as FishMaster. AQUATIC PANDA has also been observed delivering njRAT payloads to targets." CrowdStrike told us in an email that, while Aquatic Panda isn't new, CrowdStrike has been quietly tracking them up to this point, and last week's description of the threat actor's behavior is the first it's made public. The researchers have hitherto reserved their reporting on Aquatic Panda for CrowdStrike subscribers.

CrowdStrike says that their OverWatch continuous-monitoring solution enabled the affected institution to engage its response plans, patch the vulnerability, and prevent Aquatic Panda from accomplishing whatever it was seeking to do. The tell, the researchers say, was "suspicious activity stemming from a Tomcat process running under a vulnerable VMWare Horizon instance." Among the activities observed were credential-harvesting attempts.

It's not the first nation-state exploitation of a Log4j issue. North Korean, Turkish, Iranian, and Russian units have all been reported to be active against the vulnerability.

New Log4j vulnerabilities discovered and patched.

On December 28th Checkmarx reported, and Apache fixed, a new arbitrary code execution vulnerability in Log4j. Newly released Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6) all address CVE-2021-44832. The Apache Foundation described the vulnerability as follows:

"Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2."

It's not, as Naked Security notes, an unauthenticated remote-code execution issue, which is probably among the reasons it's rated at moderate severity: an attacker would need to be authenticated inside the target in order to be able to take advantage of the flaw. Nonetheless, users would do well to upgrade their systems promptly. And Naked Security also suggests that it might be worth seeing if your organization could do without Log4j entirely:

"But we’re going to suggest, once again, that if you have found Log4j in your ecosystem recently, especially on servers where you didn’t even know it was there, that you should ask yourself the question, 'Do I genuinely need a multi-megabyte logging toolkit consisting of close to half a million lines of source code, or would something much more modest and easier to review do at least as well?'

"That’s not a criticism of Apache; it’s merely a reminder that inherited security problems such as Log4Shell are often the unexpected side-effect of a cybersecurity decision made years ago by someone from outside your company whom you’ve never met, and never will."

BleepingComputer, keeping score, counts this as the fifth Log4j CVE that's been addressed in less than a month.

Responses to Log4j issues.

Microsoft last week issued new services designed to protect its users against exploitation of Log4j vulnerabilities. "New capabilities in threat and vulnerability management including a new advanced hunting schema and support for Linux, which requires updating the Microsoft Defender for Linux client; new Microsoft Defender for Containers solution," the company blogged on December 27th. They added, "Microsoft’s unified threat intelligence team, comprising the Microsoft Threat Intelligence Center (MSTIC), Microsoft 365 Defender Threat Intelligence Team, RiskIQ, and the Microsoft Detection and Response Team (DART), among others, have been tracking threats taking advantage of the remote code execution (RCE) vulnerability in Apache Log4j 2 referred to as 'Log4Shell'."