CISA discusses progress on Log4shell (as other open-source vulnerabilities are reported).

As CISA delivers an update on the progress of Log4j remediation, other open-source issues come to attention.

CISA's Log4j update.

Like others interested in security, the US Cybersecurity and Infrastructure Security Agency (CISA) found out about Log4shell on December 10th, when the vulnerability was first disclosed. This morning CISA held a media call to outline, one month into the Log4shell affair, how the community it serves has responded to the widespread open-source software vulnerability. CISA Director Jen Easterly and Executive Assistant Director for Cybersecurity Eric Goldstein both spoke during the call. While Director Easterly emphasized that while Log4shell was easily the most serious vulnerability she'd seen in her career (being widespread, easily exploitable, and high in potential impact) the news she brought to this update was on balance "a good news story." CISA has seen an "unprecedented level of collaboration among its partners," and that, so far, the agency has observed no serious consequences of Log4shell exploitation.

Such exploitation as has been observed so far have been commonplace, of a fairly low-grade criminal nature. They've seen mostly cryptojacking and botherding, the latter presumably preparation for subsequent opportunistic use. CISA hasn't been able to confirm that Log4shell had been used to deploy any ransomware. The agency, Goldstein said, was aware of the risk of ransomware, and was particularly alert to threats to hospitals, but that so far ransomware seems not to have made extensive use of Log4shell.

CISA has also not been able to independently confirm reports of nation-state attacks. And the US Government seems to have escaped disruptive attack. Goldstein said that CISA has observed scanning of US Government agencies, but no successful attempts to compromise them. That said, he cautioned against complacency, given that the Government faces "a long tail of remediation."

CISA's role in the Log4j response exemplifies how the agency sees itself discharging its mission. CISA has sought to serve as a single authoritative source for information and remediation guidance. It's provided crowdsourced scanning tools, and it's aggregated advice from its partners, again in a single, accessible location. Goldstein drew attention to the importance of the Binding Operational Directives CISA has issued to the one-hundred-one Federal civilian agencies of the Executive Branch that it supports. While such directives are binding on those agencies, they're also made publicly available, and can serve as a useful source of practical guidance to others. He paid tribute to what he called "the incredible power of crowd-sourcing" (and made particular mention of CISA's use of BugCrowd in preparing its response to the incident.

The CISA executives confined their discussion specifically to Log4shell, and not the other ancillary vulnerabilities the Apache Foundation has recently found and mitigated. But they did offer some thoughts for the future of regulation and for the open-source software community as a whole. Easterly expressed disappointment that mandatory incident reporting legislation had stalled in Congress (but she also noted that incident disclosure is different from vulnerability disclosure, and that mandatory incident disclosure wouldn't necessarily have brought Log4shell to light) and hoped that it would pass in some form. Goldstein said that the Log4shell incident showed the need for widespread use of software bills of materials. These would contribute greatly to organizations' ability to determine their exposure to any particular vulnerability. He also said that CISA believed the incident showed the extreme importance of open-source software, and said that the agency was looking into ways of working to ensure that it was working with partners to invest appropriately in the open-source community. Easterly added that CISA was working to catalogue vulnerabilities and would continue to work closely with its partners in the public and private sectors. She alluded, briefly, to a forthcoming effort that would prioritize "primary important system entities," thereby focusing attention and resources on areas an adversary would consider high-value targets.

Not Log4j, but "Log4j-like."

The Java SQL database, H2, has been found to have vulnerabilities similar to those that afflict Log4j. JFrog, whose researchers identified the vulnerability, describe H2 and its use as follows:

"H2 is a very popular open-source Java SQL database offering a lightweight in-memory solution that doesn’t require data to be stored on disk. This makes it a popular data storage solution for various projects from web platforms like Spring Boot to IoT platforms like ThingWorks. The com.h2database:h2 package is part of the top 50 most popular Maven packages, with almost 7000 artifact dependencies."

Naked Security writes that the most probable avenues through which an attacker might exploit the H2 vulnerability are either through an "active H2 web-based console" or an "H2 console listening on an external network interface." Some attacks could open targets to unauthenticated remote code execution.

JFrog says, "Although this is a critical issue with a similar root cause" as Log4shell, which is JNDI remote class loading, accepting lookup URLs, "CVE-2021-42392 should not be as widespread as Log4Shell (CVE-2021-44228). Users of the H2 database should update their instances to version 2.0.206 as soon as possible.

Felipe Duarte, Security Researcher at Appgate, wrote to explain how the H2 vulnerability could be exploited, and what the consequences of such exploitation might be:

"The vulnerability discovered in the H2 console is considered critical, as it can allow an unauthenticated user to execute arbitrary Java code from the H2 console.

"Tracked under CVE-2021-42392, this flaw is caused by the same component as Log4Shell, the JNDI (Java Naming and Directory Interface) API. Although it's a critical vulnerability, this console is not commonly exposed to the internet. In fact, by default, it only executes in localhost. The exception is third-party tools like JHipster framework that expose the H2 console through other interfaces, but even then, it should still only be available on the internal network. Of course exceptions exist, and it's possible for misconfigured servers to expose H2 consoles to the internet, but that is not the general case.

"For the reasons above, we expect it to be used more as a lateral movement exploit (allowing an attacker to go deeper into the network) than as an initial infection vector (like the way Log4Shell can be used.) Log4Shell received a CVSS of 10, the highest possible, as it is potentially very destructive. Many applications implement this library at different levels, and it's only necessary for the application to log a malicious string to trigger the vulnerability.

"In summary, CVE-2021-42392 is critical, and companies need to rush to update their applications, but Log4Shell represents a much higher danger. In many applications, it can be easily triggered without access to the internal network. As Log4Shell is getting a lot of attention, we expect many other exploits using the same technique to be published, as developers and pentesters review their code. It's very important for any company developing Java-based applications to review the security of their applications, preferably with a pentest team, and to segment their network, isolating all critical servers from the internet exposed services."

Some open-source developer dissident activity.

BleepingComputer reports that Marak Squires, developer of the widely-used open-source libraries "colors" and "faker," introduced an infinite loop into the libraries so that applications that used them would be "bricked" with gibberish. Mr. Squires is apparently disgruntled by his sense of being ill-used and uncompensated by the companies who use open-source software.