Note: this blog has been updated on December 20, 2021, and we will continue to make updates as more technical information becomes available
Exploit Background The Log4j exploit is a vulnerability in an open source Apache logging framework that allows attackers to gain arbitrary execution abilities on an affected device. Used commonly in modern Java applications (even some non-enterprise applications like Minecraft), services are scrambling to defend against this vulnerability. Earliest evidence of this exploit was found December 1st, according to Cloudflare CEO Matthew Prince.
This vulnerability can be exploited through sending a single crafted string that is then logged by versions 2.0 and up of Log4J. Users on Twitter, Minecraft, and iCloud have been seen changing their usernames or posting chat messages that include the string, successfully gaining access. The exploit can also be used to read server environment variables, which can read static credentials in some cases without full remote code execution.
The situation with this exploit is currently ongoing as researchers continue to find affected applications and further holes in the logging framework. Some have dubbed this situation ‘Log4Shell’. More information on this CVE can be foundhere.
Impact Currently, the Log4J vulnerability is causing a sharp uptick in traffic with the triggering string. Though most hosts are able to fight against it by layering security measures, discontinuing use of some Java applications, or dropping/banning traffic, others are scrambling to review their assets for any inclusion of Log4J or components using the framework.
An arbitrary execution can result in catastrophic damage, as it allows for near full access to all server resources. After successfully triggering the vulnerability, attackers can upload scripts to the server that can retrieve files, use the server for DDoS attacks, monitor the server, and more.
Needless to say, this sort of vulnerability has been classified as a Critical or 10.0 severity on CVSS version 3 and is highly dangerous. As a result, we have put together some automation and this release to help our customers.
Detection In response to this vulnerability, we have implemented some logic to detect it in customer instances. This detection first searches out items using LDAP and certain ports associated with LDAP. It will also search for unusual URIs (which would find instances of attempts using the custom string). After assigning scoring and sorting by least frequent/unusual hosts, cases are created for triage.
New Release In our new release, Milestone 86, we’ve implemented the Apache-recommended fix to prevent attempts against our instances. We’ve also done thorough checks of customer instances and done reviews of known customer assets for notifications.
The Apache recommendation, though followed for this article, has since been invalidated by Apache and continues to be vulnerable. A later release is in progress to further patch issues related to Log4J. Please keep an eye on our latest releases page for details.
Remediation Within LogicHub, please ensure you keep up on our latest instance version releases as they become available. We will continue to monitor for additional instances of this activity and new attacks under the Log4j vulnerability umbrella.
Please also follow the advice given under the Apache remediation page for devices that are not running LogicHub instances. Please see Sources in this release for more information.