Log4j: Where's Fancy Bear been? Right there, choppin' lumber...

One of the mysteries about Log4shell so far has been the relative absence of Russian exploitation, whether by privateers or intelligence services. Given the extensive activity observed on the part of China, North Korea, Iran, and Turkey, where have the Russian threat actors been? BGR noted that the usual Russian operators seemed to have been quiet, so far. Mandiant, in its own rundown of cyberespionage taking advantage of Log4j vulnerabilities, sensibly said, "We expect threat actors from additional countries will exploit it shortly, if they haven’t already. In some cases, state sponsored threat actors will work from a list of prioritized targets that existed long before this vulnerability was known. In other cases, they may conduct broad exploitation and then conduct further post-exploitation activities of targets as they are tasked to do so."

Drovorub associated with Log4j exploitation.

SecurityScorecard has solved that mystery. It reported this morning that it's observed Drovorub activity, and Drovorub points to its masters at Fancy Bear, APT28, Russia's GRU military intelligence service. Drovorub, which means "woodcutter," is a toolkit developed by the GRU's 85th Main Special Services Center for use against Linux-based systems. And that activity has been extensive. SecurityScorecard regards Russian reconnaissance, probing, and probable exploitation as comparable in scale to what's been observed from China. More developments can be expected, the researchers write: "It’s important to remember that we are still in the very early days of trying to understand this security issue and how it’s being used by threat actors."

Next steps in Log4j exploitation.

There's reason to think that self-propagating worms are under development to take advantage of Log4j bugs. Researcher Greg Linares believes at least three groups are working on a Log4j worm. SecurityWeek, which cites Linares, also quotes other researchers who think the news of a coming worm is unproven at least, unlikely at best, or probably likely to lead to worms less serious than some of the high-profile cases observed earlier this century.

Emergency Directive 22-02: CISA tells agencies to identify and patch Log4j.

The US Cybersecurity and Infrastructure Security Agency (CISA) this morning issued Emergency Directive 22-02, directing the US Federal agencies that fall within its remit to identify and update all vulnerable systems no later than 5:00 PM Eastern Standard Time on December 23rd. CISA gives the agencies until December 28th to report completion. In full, the required actions are as follows:

"By 5 pm EST on December 23, 2021:

"Enumerate all solution stacks accepting data input from the internet.
"Evaluate all software assets in identified solution stacks against the CISA-managed GitHub repository (https://github.com/cisagov/log4j-affected-db) to determine whether Log4j is present in those assets and if so, whether those assets are affected by the vulnerability.
"If the software product is not listed in the repository, request addition by submitting a “pull” request using the link on the GitHub page[1].
"For all software assets that agencies identify as affected by CVE-2021-44228:
"Update assets for which patches have been provided. Remediation timelines prescribed in BOD 22-01 “may be adjusted in the case of grave risk to the Federal Enterprise.” Given the criticality of CVE-2021-44228, agencies must immediately patch any vulnerable internet-facing devices for which patches are available, under an emergency change window.
"OR
"Mitigate the risk of vulnerability exploitation using one of mitigating measures provided at: link.
"OR
"Remove affected software assets from agency networks.
"For all solution stacks containing software that agencies identified as affected: assume compromise, identify common post-exploit sources and activity, and persistently investigate and monitor for signs of malicious activity and anomalous traffic patterns (e.g., JDNI LDAP/RMI outbound traffic, DMZ systems initiating outbound connections).

"By 5 pm EST on December 28, 2021:

"Report all affected software applications identified in (3) above using the provided template, including:
"Vendor name
"Application name and version
"Action taken (e.g. updated, mitigated, removed from agency network)
"Confirm with vulnerability@cisa.dhs.gov that your agency’s Internet-accessible IP addresses on file with CISA are up to date, as required by CISA Binding Operational Directive 19-02."

Questions for the open source software community.

Log4j is from Apache's open source library, and some have asked if the vulnerability exposed as Log4shell should call into question the very idea of using open-source software. The short answer would be, according to some, not at all. IT World Canada has a useful discussion of the issue, in which they point out that the Open Source Security Foundation is well-funded, backed by deep-pocketed tech firms, and that securing open source software is not a hobbyist's labor of love. The piece quotes the CTO of NCC Group, Ollie Whitehouse, who frames it this way:

“All software, open-source, closed-source, has latent cybersecurity vulnerabilities. We are only now getting to a point where we understand how to industrialize the detection and remediation of that. And the Open Source Security Foundation, with very large technology vendor backing now, is making concerted efforts to give it support, understanding that some of these projects are maintained by small teams.”

MIT Technology Review takes the contrary view, arguing that the security of open-source software is indeed overlooked and underfunded. Their article quotes Veracode's CTO, Chris Wysopal, who says, “The open-source ecosystem is up there in importance to critical infrastructure with Linux, Windows, and the fundamental internet protocols. These are the top systemic risks to the internet.”

In truth there are probably significant local variations in resourcing and attention, which is the case with software produced by a variety of teams in any organization.

Advice for organizations, and especially for small businesses.

Vendors are working to patch their products against Log4shell, and it's proving to involve the "struggle" most observers have foreseen, Reuters reports. As the patches are issued, they should of course be applies when practicable.

Ric Longenecker, CISO at Open Systems, wrote to offer an assessment of the Log4shell (and yes, he thinks, the exploits are indeed wormable):

“Some are calling Log4J the vulnerability of the decade. Forty percent of organizations are reportedly being targeted, and it is wormable. We’ve already gotten a taste of the potential impact of this vulnerability with Kronos Global being hit, and we should be wary of other potential organizations at risk and how it may impact the ability to distribute paychecks before the holidays. Companies must continue taking this very seriously and must ensure round-the-clock monitoring. We strongly encourage all companies to seek out a trusted security partner to help protect themselves against a potential attack. Log4J might be a doorway into an organization that’s used as a foothold, but not executed on for several months. When that time comes, enterprises may be able to avert a severe compromise or ransomware attack if proper steps are taken beforehand.”

He recommends that all organizations take these steps to protect themselves:

"Gather a team with an IR lead to identify potential software and third parties, then search code for vulnerabilities."
"Think about externally facing (websites, servers) systems and prioritize."
"Make a patching or remediation plan."
"Determine how to monitor, or report up, and respond to any potential incidents."

Rezilion also sent us some recommendations, and theirs are directed toward small businesses:

"Scan now with what you have, but make sure your scan also accounts for various types of nested JAR files and for cases in which Log4j isn't explicitly mentioned as part of the JAR name.

"Build a remediation plan that prioritizes patching Log4j instances that are loaded into memory first. This will ensure you patch what's actually exploitable first versus applying remediation efforts where it's not critically needed.

"Devote some resources into validating whether active exploitation of your organization is taking place. For organizations without appropriate commercial solutions, there are some recent open source projects available that are aimed at discovering exploitation attempts."

And the holiday season may be a busy one for IT and security teams. Randal Pinto, CTO of Red Sift, commented:

“The log4j vulnerability will still be around for some time and security teams will have a busy holiday season patching up systems. But our advice for organizations is to be thorough in your assessment. Don’t only look internally but also at your supply chain, given the number of ways this vulnerability can be exploited. Ultimately this is another stark reminder that hackers will try all channels as a way to infiltrate a system, not only the obvious ones.”