Our teams are actively responding to the Log4Shell (or LogJam) 0-day threat which has been reported in the Apache Log4j 2 Java library and has been awarded a severity rating of 10 out of 10 by NIST. We are alerting customers to systems and services that may potentially be impacted and assisting with the investigation and remediation of any attacks that may result, in line with guidance from the National Cyber Security Centre.
What’s the problem?
The issue does not just impact services written wholly in Java; it simply requires a single java application leveraging the log4j library on the network. This makes it necessary to check all Java code across the network regardless of whether they are running Linux, Mac or Windows and to determine if these are using the Log4j library.
How does it work?
Vulnerability CVE-2021-44228 allows unauthenticated remote code execution which is triggered by a string provided by the attacker through a variety of different input vectors which is parsed and processed by the Log4j (version 2) vulnerable component.
According to Microsoft, most of the activity to date has been mass scanning of systems. It states the string contains “jndi”, which refers to the Java Naming and Directory Interface followed by the protocol, such as “ldap”, “ldaps”, “rmi”, “dns”, “iiop”, or “http”, which precedes the attacker’s domain. However, attackers have obfuscated these requests using additional characters making them harder to detect.
What should I do?
Customers are advised to patch their systems by updating all copies of Log4j to version 2.15.0 as soon as practicable.
NCSC advice states: “If you are using the Log4j 2 library as a dependency within an application you have developed, ensure you update to version 2.15.0 or later
If you are using an affected third-party application, ensure you keep the product updated to the latest version. The flaw can also be mitigated in previous releases (2.10 and later) by setting system property “log4j2.formatMsgNoLookups” to “true” or removing the JndiLookup class from the classpath.”
For those unable to carry out the update immediately, Apache has suggested three workarounds as explained by Sophos here as follows:
{$jndi:...}
activity from triggering a network connection, which prevents both exfiltration and remote code implantation.set LOG4J_FORMAT_MSG_NO_LOOKUPS=true
log4j-core-*.jar
file by unzipping it, deleting the component called org/apache/logging/log4j/core/lookup/JndiLookup.class
, and zipping the other files back up againWhat’s the advice from vendors?
The NCSC recommends following vendor best practice advice in the mitigation of vulnerabilities. Firewall vendors have been quick to issue patches and advice including:
In the meantime, if you have any concerns, please do reach out to us at contact@prisminfosec.com or on 01242 652 100.