(Updated original post to account for the fourth CVE log4j vulnerability and latest update to 2.17.1)
A reminder of the complex nature of technology systems. Code from third-party library open-source Apache Java tool has critical vulnerabilities and has required several patch upgrades to mitigate subsequent vulnerabilities.
- CVE-2021-45105: Vulnerability that could allow DoS attacks (CVSS 5.9)
- CVE-2021-45046: Vulnerability that could allow Remote Code Execution (CVSS 9.0)
- CVE-2021-44228: Vulnerability that could allow Remote Code Execution (CVSS 10.0)
- CVE-2021-44832: Vulnerability that could allow Remote Code Execution when there is access to the log configuration file (CVSS 6.6)
This log4j series of exploits are widespread and potentially damaging to organizations, both large and small and the US Cybersecurity & Infrastructure Security Agency issued a warning.
Millions of applications use Log4j for logging. This exploit is easy to execute, all the attacker needs to do is get the app or website using this library to log a special string. Logging is a ubiquitous process for most applications, keeping a running list of activities that were performed which can later be reviewed. Why reinvent the code for logging? Every system runs some sort of logging process. Popular libraries like log4j have an enormous reach. This exploit has an estimated potential to let hackers compromise millions of devices across the Internet.
Unfortunately, firewall protection does not eliminate this exploit risk. Due to the enormous range of applications and not to mention service platforms that are vulnerable there is no way to remove all possible delivery mechanisms. This is problematic as an attack string can be embedded in QR codes and other mechanisms that are not immediately connected to the Internet. Other verified triggers have been seen by renaming an iPhone over the Apple iCloud. The Log4Shell was recently seen on Minecraft servers where hackers used the vulnerability through chat messages. Even email, if crafted in the right way, can trigger this exploit.
What steps should you take next:
- Take inventory of your applications and infrastructure that utilizes log4J and upgrade to version 2.15.0 (old direction: set explicit system property configuration to log4j2.formatMsgNoLookups to true) (new: remove support for message lookup patterns and disable JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example is zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class)
- (New: Plan to upgrade to 2.17.1 as soon as possible to fully fix these vulnerabilities)
- Contact your service providers and vendors for more information about how they are addressing the vulnerability
- Review logs for potential indicators of compromise, here is a quick egrep command to find exploit attempts egrep -i -r ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’ {insert your access log file name(s) here}
Other exploits with similar severity and scope of potentially affected systems include Heartbleed and Shellshock. Heartbleed was a security bug in the OpenSSL cryptography library, which was a widely used implementation of the Transport Layer Security (TLS) protocol. Shellshock could enable an attacker to cause the Bash command to execute an arbitrary command and gain unauthorized access to Internet-facing services, such as web servers, that use Bash to process requests.
For small to medium-sized businesses this alert should be taken seriously. TECH LOCK can assist you and support your team by performing a risk assessment specifically for log4j exploit potential, helping in reviewing logs and providing the support to validate patching, and in examining your third-party vendors and their risk to your organization. Please contact us for immediate assistance.