Infosec leaders around the world are being urged to heed warnings from national computer emergency teams, software suppliers and cybersecurity experts about a critical logging-related vulnerability in Apache, Apple iCloud and other business applications. Managed service providers are likely also affected, say experts.
The bug, CVE-2021-44228, affects a Java logging package called log4j. It was revealed Thursday by Lunasec and on Friday by Huntress Labs, and is already being exploited, according to an alert from the Canadian Centre for Cyber Security. The U.S. Cyber Security and Infrastructure Security Agency also issued a notification.
Huntress reports that ConnectWise has issued advisories and concerns for ConnectWise Manage installations, N-able has confirmed that its RMM and N-Central are affected, and one researcher says the UniFi controller platform is also vulnerable.
Log4j is a library that helps IT administrators create logs. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from Lightweight Directory Access Protocol (LDAP) servers when message lookup substitution is enabled, says the National Institute of Standards and Technology (NIST).
The vulnerability is in log4j versions 2.0-beta9 to 2.14.1. Within hours of being notified, Apache issued version 2.15.0 for application developers; it disables message lookup substitution by default. Oracle has also distributed the patch. However, developers now have to push out updates for their applications, which may give time for exploitation to attackers. In the meantime, IT managers will have to rely on advice from application providers to apply mitigations.
Adobe also says Java 7+ users should migrate to version 2.8.2 or avoid using the socket server classes. Java 6 users should avoid using the TCP or UDP socket server classes, or they can manually backport the security fix from 2.8.2.
Many open source projects like the Minecraft server, called Paper, have already begun patching their usage of log4j, according to LunaSec
In an interview, Johannes Ullrich, dean of research at the SANS Institute, predicted it will take years for organizations and cloud providers to patch their applications to close this hole. Oracle is still patching some of its applications from different log4j vulnerabilities discovered several years ago, he pointed out.
“This is one of those issues like Java (Apache) Struts and Heartbleed, where we have a library included in tons and tons of mission-critical software. The exploit allows you to completely take over a system it’s running on. It will be an absolute nightmare to patch this vulnerability in large enterprise environments.”
One worry is that threat actors may have already exploited the vulnerability, he said, so patching for them is too late.
Asked what IT managers should be doing, Ullrich said they should be trying to identify software in their environments that includes log4j. “If the software is written in Java then it’s often using log4j. There are some configuration changes that you can make that may help. Depending on how the library’s being used, it may not even reach those configuration changes if you link them back to an application’s configuration file.
“You may be able to add additional security around an application, like additional firewall rules and intrusion protection rules that block the vulnerability. Try to find whatever mitigating rule you can find to add additional layers to sort of put ‘bubble wrap’ around those applications.”
The notice from LunaSec includes temporary mitigations, he added.
The vulnerability can be triggered by an attacker sending a string from a server to an application with a vulnerable version of log4j. A threat actor might supply special text in an HTTP User-Agent header or a simple POST form request, says Huntress.
Huntress has created a tool to help IT departments test whether their applications are vulnerable.
Arshan Dabirsiaghi, co-founder and chief scientist at Contrast Security, said that any Java application that logs data uses log4j. It’s the most popular logging framework in the Java ecosystem and is used by millions of applications. “Make no mistake, this is the largest Java vulnerability we have seen in years. It’s absolutely brutal,” he said.
“There are three main questions that teams should answer now—where does this impact me, how can I mitigate the impact right now to prevent exploitation, and how can I locate this and similar issues to prevent future exploitation?”
In an end-of-the-week news commentary, SANS Institute instructor Chris Elgee said the discovery of this vulnerability is a case for continuous in-house pentesting for organizations large enough to support it. “Apache log4j is one of those web application plumbing components that many companies won’t know they’re using – much like Apache Struts 2. In fact, if you’re running Struts 2, you’re likely running a vulnerable version of log4j. Further, much like Struts vulnerabilities, it’s the kind of flaw that generally needs to be checked actively and won’t come up in typical vulnerability scans.”
