The library is developed by the open-source Apache Software Foundation and is a key Java-logging framework. Since last week’s alert by CERT New Zealand that CVE-2021-44228, a remote code execution flaw in Log4j, was already being exploited in the wild, warnings have been issued by several national cybersecurity agencies, including the Cybersecurity and Infrastructure Security Agency (CISA) and the UK’s National Cyber Security Centre (NCSC). Internet infrastructure provider Cloudflare said Log4j exploits started on December 1.
What devices and applications are at risk?
Basically any device that’s exposed to the internet is at risk if it’s running Apache Log4J, versions 2.0 to 2.14.1. NCSC notes that Log4j version 2 (Log4j2), the affected version, is included in Apache Struts2, Solr, Druid, Flink, and Swift frameworks.
Mirai, a botnet that targets all manner of internet-connected (IoT) devices, has adopted an exploit for the flaw. Cisco and VMware have released patches for their affected products respectively.
Log4j flaw coverage – what you need to know now
Log4j flaw: Attackers are making thousands of attempts to exploit this severe vulnerability Security warning: New zero-day in the Log4j Java library is already being exploited Log4j RCE activity began on December 1 as botnets start using vulnerability
AWS has detailed how the flaw impacts its services and said it is working on patching its services that use Log4j and has released mitigations for services like CloudFront.
Likewise, IBM said it is “actively responding” to the Log4j vulnerability across IBM’s own infrastructure and its products. IBM has confirmed Websphere 8.5 and 9.0 are vulnerable.
Oracle has issued a patch for the flaw, too.
“Due to the severity of this vulnerability and the publication of exploit code on various sites, Oracle strongly recommends that customers apply the updates provided by this Security Alert as soon as possible,” it said.
Necessary actions: Device discovery and patching
CISA’s main advice is to identify internet-facing devices running Log4j and upgrade them to version 2.15.0, or to apply the mitigations provided by vendors “immediately”. But it also recommends setting up alerts for probes or attacks on devices running Log4j.
“To be clear, this vulnerability poses a severe risk,” CISA director Jen Easterly said Sunday. “We will only minimize potential impacts through collaborative efforts between government and the private sector. We urge all organizations to join us in this essential effort and take action.”
Additional steps recommended by CISA include: enumerating any external facing devices with Log4j installed; ensuring the security operations center actions every alert with Log4j installed; and installing a web application firewall (WAF) with rules to focus on Log4j.
SEE: A winning strategy for cybersecurity (ZDNet special report)
NCSC recommends updating to version 2.15.0 or later, and – where not possible – mitigating the flaw in Log4j 2.10 and later by setting system property “log4j2.formatMsgNoLookups” to “true” or removing the JndiLookup class from the classpath.
Part of the challenge will be identifying software harboring the Log4j vulnerability. The Netherland’s Nationaal Cyber Security Centrum (NCSC) has posted a comprehensive and sourced A-Z list on GitHub of all affected products it is aware are either vulnerable, not vulnerable, are under investigation, or where a fix is available. The list of products illustrates how widespread the vulnerability is, spanning cloud services, developer services, security devices, mapping services, and more.
NCCGroup has posted several network-detection rules to detect exploitation attempts and indicators of successful exploitation.
Finally, Microsoft has released its set of indicators of compromise and guidance for preventing attacks on Log4j vulnerability. Examples of the post-exploitation of the flaw that Microsoft has seen include installing coin miners, Cobalt Strike to enable credential theft and lateral movement, and exfiltrating data from compromised systems.
