By now nearly everyone has heard about Log4j or  CVE-2021-44228, a Java vulnerability disclosed late last week. The vulnerability impacts Java and more specifically, the library Java uses to log application error messages. Researchers have rated the vulnerability a 10/10 in terms of severity, and for good reason. Hundreds of millions of devices and applications run Java, which means virtually everything – from your kid’s Minecraft install, to home routers, web-based applications and connected IoT devices will be impacted. 

What you need to know: 

  • CVE-2021-44228 is a critical zero-day exploit in the Apache Log4j Java library that allows a remote attacker to execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. This impacts applications that make use of the Log4j library with versions 2.0-beta9 up to 2.14.1. 
  • The vulnerability allows bad actors remote code execution, giving them access to all data on affected machines and devices with read/write access.  
  • All devices that connect to the internet are vulnerable if they’re running Apache Log4j2<=2.14.1 JNDI features. This vulnerability puts devices at risk to botnets like Mirai and its variants, which researchers note are already running exploits. 
  • The vulnerability spans a number of enterprise products too, including: Oracle, Cisco, RedHat, IBM, VMware and Splunk and cloud features from Amazon Web Services and Microsoft Azure.
  • Apache has released Log4j 2.15.0 library to mitigate this vulnerability. However, each application that makes use of an impacted Log4j library would need to be rebuilt with the newer version and distributed by the software vendor. 
  •  

Why it matters: 

  • While this vulnerability is specific to Log4j, a single patch won’t fix the vulnerability. Application, cloud and software vendors are racing to issue a patch unique to its service’s risk. 
  • This vulnerability highlights supply chain risk – as a business you use a number of products and vendors in your tech and security solutions stack; you’ll have to track and install patches for every one of them. 
  • The impact of this issue is likely going to unwind over time as software vendors patch their applications and release new versions. 

What you need to do: 

  • Immediately check for vulnerable versions of Apache Log4j in your environments and applications. 
  • Applications that allow changes to the Log4j configuration can also set the system property “log4j2.formatMgNoLookups” to “true” on versions 2.10 and later. 
  • Implement the latest patch to production environments as soon as possible. 
  • Monitor your logs for malicious activity on an ongoing basis. 

Detection of this vulnerability is somewhat complicated as individual applications that make use of Log4j can be difficult to find due to the way Java packaging works. Some open source projects like Syft and Grype can help identify if a Java application is making use of an impacted version of Log4j. Currently these toolsets are only built for macOS/Linux. Because of the vulnerability’s far reaching impacts and the sheer number of impacted services and vendors, patching will be an ongoing process and might take months to fully execute.  

Monitor your network for data exfiltration 

Beyond device and application vulnerabilities, Log4j makes sensitive data vulnerable to future exfiltration, which makes knowing what data you have more critical. Ensuring your data inventory is up-to-date and appropriately classified will help your team mitigate sensitive data exfiltration risk.  

We’re here to help 

The Cavelo platform runs continuous data discovery and classification by data type, which establishes a real-time and up-to-date data inventory. We’re ready to help, whether you need to vet your risk or stand up your data inventory. 

Let's Talk