What you need to know about Log4J Exploits and How to Protect Yourself
In the early hours of Friday, December 10th, 2021, a new vulnerability was discovered in the Log4J software library that affects a number of components. Logging libraries like this are used across many different Java-based platforms and power many parts of the internet.
At Measured Analytics and Insurance, we aim to mitigate cyber risk with technology and education. On a continuous basis, we scan the internet for infrastructure assets that are vulnerable to various cyber security threats.
After the Log4j vulnerability was first released, we quickly developed a detection capability based on the new vulnerability. We have run the new scanner on all Measured cyber security insurance policyholders. Additionally, we will be in contact with all entities using the vulnerable versions of the Log4j library, or the software that uses Log4j as an integral part of its implementation.
What is Log4J?
Log4J is an open-source logging framework that is used by developers across different industries to track all kinds of actions and activities within their applications. It is used by platforms such as Minecraft, VMWare, Elasticsearch, Apple, Cloudflare, Amazon Web Services, and Tesla, along with various Apache platforms such as Struts, Druid, ActiveMQ, Flume, Hadoop, and Kafka, among many others.
Does the vulnerability have any impact?
Hackers can exploit Log4j’s vulnerability to execute arbitrary code and gain access to a computer system. If manipulated properly, the hacker will also be able to gain complete control of a server when they use this technique. According to the technical explanation, “An attacker who is able to control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.”. It is concerning since attackers have used it to gain access to computers in the past. Based on the reports, it appears that this issue has been resolved for users using Log4j 2.15.0 or higher. The reason is that Log4j 2.15.0 and later have behavior disabled by default.
As explained in the Log4J bulletin
I am a Measured Policyholder; how will this affect me?
If you have a Measured policy, please contact your broker or account representative, as they will be able to advise you on how to begin a remediation process with your organization’s IT team. In addition, it is important to note that we are publishing and regularly updating the next section with platforms that are vulnerable to CVE-2021-44228.
Note: We recommend that you check whether you are running any of the vulnerable software inside your network since Measured only has visibility into assets exposed to the internet. Once you have your list of assets, it is time to begin to mitigate the issue.
Mitigation: In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. You also need to update Log4j to the latest version, which can be downloaded here.
Vulnerable Platforms:
This section contains a list of platforms Measured has identified as potentially vulnerable to CVE-2021-44228.
For your major vendors not on this list, you should contact them and ask them the following questions:
- Do you use any software that relies on Log4J?
- Have you executed any mitigations for CVE-2021-44228?
- Did you do any investigation to confirm you have not been a victim of the exploitation of CVE-2021-44228?
Known vulnerable platforms:
Okta RADIUS Server Agent, Okta On-Prem MFA Agent Apache Struts, Solr, Druid, ActiveMQ, Flume, Hadoop, Kafka,Dubbo,Flink,Spark, Tapestry, Wicket Accellion Kiteworks Redhat OpenShift Container Platform 4, OpenShift Container Platform 3.11, OpenStack Platform 13 (Queens), OpenShift Logging. Grails Ghidra Minecraft VMWare Horizon, VCenter, HCX, NSX-T Data Center, Unified Access Gateway, WorkspaceOne Access, Identify Manager, VRealize Operations, VRealize Operations cloud proxy, VRealize log insight, VRealize Automation, VRealize Lifecycle Manager, Telco Cloud Automation, Site Recovery Manager, Caron Black Cloud Workload Appliance, Carbon Black EDR Server, Tanzu GemFire, Tanzu Greenplum, Tanzu Operations Manager, Tanzu Application Service for VMs, Tanzu Kubernetes Grid Integrated Edition, Tanzu Observability by Wavefront Nozzle, Healthwatch for Tanzu Application service, Spring Cloud Services for Vmware Tanzu,Spring Cloud Gateway for Vmware Tanzu, Spring Cloud Gateway for Kubernetes, API Portal for VMWare Tanzu, Single Sign-on for VMWare Tanzu Application Service, App Metrics, Vmware vCenter Cloud Gateway, VMWare Tanzu SQL with MySQL for VMs, Vrealize Orchestrator
Potentially vulnerable — Log4J isn’t enabled by default, but it is available.
- Apache Tomcat
- Dropwizard
- Elastic Kibana
- Hibernate
- JavaServer Faces
- Oracle ATG Web Commerce
- Spring Framework
A more extensive list is being updated by the cybersecurity community, which can be found here.
