A new exploit has been discovered in Log4j (version 2.0 or higher) that could have wide-scale implications and has already been detected in use in the wild, why is this important and so serious? Well, Log4j is an open-source Java logging library that is very widely used across applications and in multiple services as a dependency across enterprise services, application stacks and the internet. It’s used in many frameworks such as:
- Apache Druid
- Apache Flink
- Apache Solr
- Apache Struts2
- Apache Swift
- Spring
As you can see it will affect many Java applications built on those frameworks, such as Docker, Elasticsearch and many others. Such a wide scope means there are plenty of avenues to use the exploit on. But what exactly is the exploit itself? Basically, allows an attacker to remotely execute Java code on a server allowing them to take control and execute various other attacks via unsanitized input strings.
This graphic gives a great overview of how the issue works in practice:
Thankfully Apache has quickly fixed this issue and released a new version of Log4j 2.17.0 where the ability to execute code remotely has been disabled by default. However, this now relies on companies and projects to update their products to this new version, build and release the new version to the public. Which in turn requires systems that use these products or the old Log4j version up to date by patching/updating their whole estate. A time consuming and human error-prone process which will take time.
Now if you can’t install the new versions for legacy issues or other reasons well there is still a way to remediate the issue there are a couple of methods to use:
- Add the java parameter -Dlog4j2.formatMsgNoLookups=true which will change the system property for version 2.10 > 2.14.1,
- Another option is to remove the JndiLookup class for the classpath in the code.
These once again require rebuilding and redeploying of the application to take effect.
It should be noted that these remediations above are no where near as good as updating the library to the latest version and you should strive to do so.
Elasticsearch
As an AWS managed service provider and Elasticsearch partner Mobilise supports and deploy multiple Elasticsearch clusters and their log shippers (Logstash and filebeats) for many customers. Elasticsearch and Logstash are partially affected by this vulnerability – it does not allow remote code execution but is susceptible to information leaks. To remediate this issue, Elastic has released a new version 7.16.1 and Logstash 6.8.22.
Mobilises in house CI/CD pipelines allow us to change the version of Elasticsearch easily and quickly via our Ansible playbooks – pushing out the new builds across multiple systems in multiple accounts using rolling deployments preventing any outages. This follows our own best practices and more about those can be read about here.
Other versions managed in public cloud providers or Elastic Cloud are being automatically patched by suppliers.
Contact us today if you need help on this issue.
