Log4J Vulnerability Explained
A severe new security risk has emerged this weekend concerning Log4J, the popular logging library used in Java programming language.
The Log4J vulnerability has the potential to affect millions of services across the internet and has been graded with a CVSS score of 10, the maximum severity rating possible. Urgent action is required if your organisation uses systems built with this library as it is actively being exploited by hackers.
As mentioned by Sean Gallagher, senior threat researcher at Sophos:
"Log4Shell is a library that is used by many products. It can therefore be present in the darkest corners of an organisation’s infrastructure, for example, any software developed in-house. Finding all systems that are vulnerable because of Log4Shell should be a priority for IT security."
What is the Risk?
It was recently discovered that if a specifically crafted pattern of code is submitted to a query field (such as a search field, name or anything that takes an input) in an application that uses Log4j library, attackers can take control of the server with pieces of software known as RCE (Remote Code Execution) tools.
The bulk of attacks observed at this time have been related to mass scanning by attackers attempting to thumbprint vulnerable systems. If any other systems in your infrastructure have vulnerabilities, these could be detected by attackers and open your organisation up to further security risks.
In cases where full control has been obtained, attackers have installed coin miners, Cobalt Strike to enable credential theft and lateral movement, and exfiltrated data from compromised systems.
How to Check if you are Affected by the Log4J Vulnerability
If you use applications which utilise the Log4J library, we strongly recommend that you firstly check your versions to see if you are affected:
- Log4j version – all 2.x versions before 2.15.0 (which was released last Friday 10th December) are affected
- JVM version - if lower than:
- Java 6 – 6u212
- Java 7 – 7u202
- Java 8 – 8u192
- Java 11 - 11.0.2
If your versions for both are lower than what’s listed above, you are most certainly affected. As attackers are actively exploiting the Log4J vulnerability, it is possible that your internet-facing infrastructure has already been compromised.
There is a patch now available (Log4J version 2.15.0) to prevent code execution. Though currently at the time of writing, these patches won’t disable inline message lookup. This can be used by attackers to expose environment variables and system configuration settings.
Firstly, you should download the mitigated Log4J version: https://logging.apache.org/log4j/2.x/download.html
For Log4J versions 2.10 and newer, the lookup functionality can be disabled three ways:
By setting the “log4j2.formatMsgNoLookups” property to “true” in the configuration file.
By setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true at the process level.
By setting the "-Dlog4j2.formatMsgNoLookups=true" in the JVM command line.
For older Log4J releases (2.0-beta9 to 2.10.0), mitigating this issue requires removal of the JndiLookup class from the jars in the classpath:
$ zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
It is worth noting that an updated version of the Java runtime is NOT a sufficient mitigation. Newer versions of Java block the URL class loader by default but can still be abused to leak secrets from the environment, and deserialisation attacks may still succeed using classes already loaded by the process.
The widespread severity of this issue will make it one of the most memorable security incidents since the inception of the internet.
With the largest risk currently being the potential for further vulnerabilities being exposed, there will no doubt be a wave of follow-up attacks in many other areas of IT infrastructure.
Our recommendation to prevent further damage to your infrastructure is to ensure you understand if you have any vulnerabilities, where they are and how to mitigate them. This can be easily achieved with a Vulnerability Assessment, either as a scheduled test, one-off or on-demand.
Speak to our cyber security experts if you have any further questions about this risk and what measures you can take to ensure you do not fall victim to an attack.