Log4j and the offense-defense seesaw.

Threat actors continue to take opportunistic but systematic advantage of Log4j vulnerabilities they find in their targets. CISA continues to help US Federal agencies catch and close exploitable vulnerabilities while more speculation circulates about a larger role for the Government in addressing open-source software supply-chain security.

Log4j vulnerabilities in VMware Horizon servers are being actively targeted.

The UK's National Health Service has issued a warning that "unknown threat actors" are working to exploit vulnerable VMware Horizon servers to set up webshells in their victims, thereby establishing persistence in their targets. The versions under active exploitation include Horizons Connection Server (64bit) 2006-2111, 7.13.0-7.13.1, and 7.10.0-7.10.3. NHS explains the way the attacks have been unfolding:

"The attack likely consists of a reconnaissance phase, where the attacker uses the Java Naming and Directory Interface^TM (JNDI) via Log4Shell payloads to call back to malicious infrastructure.

"Once a weakness has been identified, the attack then uses the Lightweight Directory Access Protocol (LDAP) to retrieve and execute a malicious Java class file that injects a web shell into the VM Blast Secure Gateway service.

"The web shell can then be used by an attacker to carry out a number of malicious activities such as deploying additional malicious software, data exfiltration, or deployment of ransomware."

There are three suspicious markers NHS advises organizational threat hunters to watch for:

• "Evidence of ws_TomcatService.exe spawning abnormal processes
• "Any powershell.exe processes containing ‘VMBlastSG’ in the commandline
• "File modifications to ‘…\VMware\VMware View\Server\appblastgateway\lib\absg-worker.js’ - This file is generally overwritten during upgrades, and not modified"

Organizations seeing any of this suspicious behavior are invited to report it the NHS by emailing  carecert@nhsdigital.nhs.uk.

VMware was quick to respond to notification of Log4j vulnerabilities, and its products have received appropriate upgrades. Nonetheless, as the Record points out, a non-negligible number of users haven't yet updated their software, and the threat actors are misbehaving accordingly.

NHS doesn't identify the threat actor whose behavior it describes, and indeed there may not be any single actor responsible for the attempts. Duo Security's Decipher says that there are more than one bad actor engaged in this kind of exploitation: "[S]ince the first disclosures of the Log4j bug a wide variety of attack groups have been exploiting it. APT groups, lone actors, and cybercrime groups all have been seen exploiting one or more of the Log4j flaws that have been disclosed in the last few weeks."

US Federal agencies continue to mitigate Log4j vulnerabilities.

Duo's Decipher also points out that, while the US Cybersecurity and Infrastructure Security Agency (CISA) has indicated that the agencies it oversees are now in general compliance with Emergency Directive 22-02 (Mitigate Apache Log4j Vulnerability), the agency has been tight-lipped about details of compliance. This is understandable in what CISA characterized to MeriTalk yesterday as an ongoing process of remediation, and the agency intends to issue a cross-agency status report by February 15th.

The complexity of the software supply chain.

The experience of finding and fixing Log4j vulnerabilities has demonstrated how complex the software supply chain is, and how complicated the process of vetting it will inevitably be. As ZDNet puts it in writing about this particular case, "the Log4j flaw for Java web applications will haunt tech people for years." An essay in POLITICO argues, in part, that Log4j has exposed the limitations of the self-correcting, evolutionary model of security that's long informed the open-source community's practices. If the software is openly accessible to inspection by multiple users with diverse purposes, the thinking had run, problems would be rapidly exposed and swiftly corrected. "But in practice," the piece says, "Log4j and other similarly ubiquitous open-source libraries often receive little dedicated scrutiny and maintenance, allowing flaws to remain hidden for long periods of time." The essay sees US Federal resources as having the potential of making a decisive contribution to open source security, especially when they're applied through the framework of preparing software bills of materials. POLITICO notes that this sort of Federal contribution is appropriate, given the Government's dependence on open-source software.