What does LOG4J mean for CIOs and CISOs?

Back on December 9, 2021, a zero-day vulnerability - meaning at the time that the flaw involving arbitrary code execution in Log4j 2 is either not known or a patch has not yet been developed - was published by the Alibaba Cloud Security Team.  

According to the FT, Hackers have already launched more than 1.2m attacks through the Log4J flaw.

IBM, Amazon, Oracle, Cisco and VMware are among those to have already issued patches in response, as the threat level was deemed to be extremely high. Warnings were issued by several national cybersecurity agencies, including the Cybersecurity and Infrastructure Security Agency (CISA) and the UK's National Cyber Security Centre (NCSC). 

When did this start?

Log4j exploits were believed to have started as early as 1st December. Last week, CERT New Zealand revealed that this remote code execution flaw (CVE-2021-44228), was already being exploited by hackers.  

Widely used Java library for logging error messages in applications, Log4J is used in enterprise software applications, including many custom applications developed in-house by businesses.

It's also a crucial component of cloud computing services.

What devices and applications could be at risk? 

Any device connected to the internet that is running Apache Log4J, versions 2.0 to 2.14.1. 

Identity and access management vendors like CyberArk, ForgeRock, Okta and Ping Identity, as well as security firms who serve the SMB community through the channel like Fortinet, SonicWall, and Sophos, are all busily working on patches to combat the threat.

According to the NCSC, the affected version is included in Apache Struts2, Solr, Druid, Flink, and Swift frameworks.  

Botnets such as the notorious Mirai malware - which targets all manner of internet-connected (IoT) devices - has adopted an exploit for the flaw. 

Actions for discovery and detection

CISA director Jen Easterly said: "To be clear, this vulnerability poses a severe risk. We will only minimise potential impacts through collaborative efforts between government and the private sector. We urge all organisations to join us in this essential effort and take action."  

Advice recommended by CISA:

• Identify internet-facing devices running Log4j and upgrade them to version 2.15.0 or apply the mitigations provided by vendors "immediately".
• Set up alerts for probes or attacks on devices running Log4j.  
• Enumerating any external facing devices with Log4j installed
• Ensuring the security operations centre actions every alert with Log4j installed
• Installing a web application firewall (WAF) with rules to focus on Log4j. 

The Netherland's National Cyber Security Centrum (also called NCSC) also recommends updating to version 2.15.0 or later or if not possible, setting system property "log4j2.formatMsgNoLookups" to "true" or removing the JndiLookup class from the classpath. 

Potentially vulnerable vendors   

Atlassian, Amazon, Microsoft Azure, Cisco, Commvault, ESRI, Exact, Fortinet, JetBrains, Nelson, Nutanix, OpenMRS, Oracle, Red Hat, Splunk, Soft, and VMware. 

Any products where a patch has been released aren't included.

The 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.

Where did it come from?

Researchers have claimed that Chinese government groups are among the perpetrators, though this is yet to be substantiated.

Industry comments

Jeff Watkins, Chief for Technology at AND Digital:

"As this is a zero day in a common library used for many years now, it means it’s there, lying in wait in many systems. You don’t even need to be directly using Log4J for it to matter, you could be using a dependent library or service that uses it, so just looking at your own code is nowhere near enough."Unfortunately, the first attempts at patching it out also had vulnerabilities in them, which was a bit of a fail.

As this is a fairly simple vulnerability to exploit, there will be a huge wave of drive-by attempts. Obscurity will not save you on this one. Other techniques can even sniff if you’re using a Java stack at all (which have been used for things like the Unsafe Deserialisation OWASP 2017 vulnerability).

In the short term, there are configuration steps to take to prevent this exploit being used by disabling JNDI lookups. Helpfully, there are tools available to check if you are vulnerable, this would be an immediate recommendation along with scanning dependencies (including transitive ones) for vulnerability. As this is an arbitrary code execution attack that can load potentially any malicious code onto the remote server for execution, it is possibly one of the most serious kinds of vulnerabilities. Using a modern WAF that can detect suspicious and bot related activity will also help. Now is a good time to also check your network segregation to avoid unnecessary exposure to drive-bys."

Pandian Gnanaprakasam, Co-founder and Chief Product Officer at Ordr:

“Log4j is an Apache Java logging library used in many forms of enterprise and open-source software. This includes cloud platforms, web applications, and email services that could be at risk from attackers attempting to exploit this vulnerability. While the full scale of affected devices and systems is still being analysed, healthcare organisations should consider any web-connected device vulnerable as they likely use Java-based applications or other Java components. Organisations should take immediate action to map and identify all devices using Apache Log4j2 from versions 2.0-beta9 to 2.14.1 and monitor networks for devices communicating with malicious IPs.

Identifying medical devices with Log4J vulnerability may require a slightly different approach. In a typical IT scenario, security teams can go to each server and run a set of scripts to see what kind of log4j version is built into the server. In healthcare situations, however, hospital staff do not have the privilege to run scripts directly on heavy iron devices like CT and X-ray machines or patient monitoring devices. As medical device manufacturers disclose affected products, security platforms can correlate this with inventory and flag vulnerable devices immediately. In some cases, it is not feasible to patch these systems and the only way around is to monitor device communications from these machines for connections to suspicious IP/URLs and analyse traffic patterns of external communication to ensure malware is not being downloaded.

The severity of this vulnerability cannot be understated. A single string of text can trigger an application to reach out to an external location if it is logged via a vulnerable instance of Log4j. It can allow unauthenticated remote code execution and access to servers. There are already active examples of attackers attempting to exploit this Log4j vulnerability in the wild, from installing crypto-mining malware, installing Cobalt Strike malware, and of botnets attempting to use it for botnet activities.”