When it comes to security vulnerabilities, they don’t get any worse than the one recently disclosed in the Log4j utility which was awarded the maximum CVSS severity of 10.  This is not some theoretical risk, it is an open door to affected systems. The NCSC calls it: ‘potentially the most severe computer vulnerability in years.’

Most software records details of how it is running in logs, to provide an audit trail of activities and to log details of errors to help the tech support teams resolve bugs. On modern computer systems where disk space is cheap, it is common for systems to be set up to log everything because you never know what might be useful when investigating an error.  Logs are much more useful if you can read and understand them easily – and this means you want your log formats to be similar across different systems as this makes automated monitoring and SIEM much simpler. To make this easier, common open-source libraries are often used to perform the logging function in many systems. After all, logging is important but hardly something that is going to give you a competitive edge.  For systems developed using Java, the Log4j open-source logging library from Apache is the most popular.

Log4j is used everywhere, from Apple’s iCloud infrastructure and Tesla motor cars to Microsoft Minecraft and a myriad of enterprise grade systems.  The problem that was discovered in Log4j is actually a designed in feature – not a bug – is being tracked as CVE-2021-44228 and CVE-2021-45046 and is also known as Log4shell.

According to the NCSC:

The Log4j library is frequently used in enterprise Java software and is included in Apache frameworks including Apache Struts2, Apache Solr, Apache Druid, Apache Flink and Apache Swift. Other large projects Including Netty, MyBatis and the Spring Framework also make use of the library.

The vulnerability was first privately disclosed to Apache on 24^th November 2021 and publicly disclosed on 9^th December 2021 – although CloudFlare reports seeing exploitation attempts in the wild starting on 1^stDecember.

Enterprise security firm CheckPoint reports in their blog that at least 44% of corporate networks globally had been targeted with an exploitation attempt within 72 hours of the vulnerability being disclosed.

The fundamental problem with Log4j is that it interprets the contents of the data that it has been asked to log – meaning programmers could embed a JNDI (Java Naming and Directory Interface) query into the logged data and log4j would execute the lookup when processing the log entry.  The danger comes because malicious users have realised how to include an executable JNDI query into data which the system is logging through Log4j.

A simple example exploit which performs an LDAP lookup against a site controlled by the attacker looks like this:

JNDI allows you to query various protocols including ldap, dns and most dangerously http.

This means, simply by sending specially crafted data to an affected system you can force the logging system to download and execute a file hosted on any internet connected server.  Because everything gets logged, activities such as changing the name of an iPhone cause the Apple iCloud servers to execute the jndi query included in the new device name – or typing a jndi query string into the chat function of a Minecraft game causes malicious code to be downloaded and executed on the game server. Anywhere a user is able to input data to a system is potentially vulnerable if the application records that input into a log that is created used Log4j.  Conceptually, the threat is very similar to an SQL injection attack except it is the logging function rather than the database which can be tricked into executing a command that is contained within text supplied by a user.

Microsoft’s Threat Intelligence Center has published details to help Security Managers identify and defend against attempts to exploit this vulnerability.  According to Microsoft nation state actors from China, North Korea and Iran are actively attempting to exploit this vulnerability.  Threat actors have been observed using Log4shell to install coin miners, botnets, ransomware, and Cobalt Strike beacons on vulnerable systems

The UK’s NCSC has published guidance for firms to deal with the risks posed by this software:

The first priority is to identify where you know Log4j is used on your network and get it patched as soon as possible in order to prevent any new attacks against your systems.

Next search for instances of Log4j that you were not previously aware of. It may not be obvious that Log4j is in use, especially where it is embedded within third party software.  To help identify these systems, use the lists of vulnerable products provided on the NCSC advisory page and reach out to the suppliers of your software.  You can also search for the Log4j file using a command such as:

find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null

which will search every folder from the root down looking for the log4j2 package. There may be multiple copies installed as part of different software applications – each copy will need to be updated.

Where updates have been published for applications that you use, these should be installed as soon as possible.  Also check that your firewall and web application firewall have been updated with the latest threat signatures – although because it is so easy of obfuscate the exploit attempts the NCSC warns that a WAF may not provide much defence against Log4shell and should not be relied upon as the only security control.

The vulnerabilities have been mitigated in Log4j version 2.12.2 for Java 7 and 2.16.0 for Java 8 and up by removing the ability to perform JNDI lookups by default – if you really need this feature it must be turned on in the configuration.

The Log4shell vulnerability is a reminder of the complexity inherent in many software supply chains and the need to maintain an inventory not only of applications used on your network, but also the open source and third-party libraries used and reused within those applications.

SecureTeam recognises that this specific vulnerability could have devastating consequences for our customers. With this being the case, we now offer a cost-effective, rapid test for the Apache Log4j vulnerability. This targeted vulnerability assessment covers all of your organisation’s Internet-facing services and provides you with same-day results. Get in touch with us today by phone or through the contact form below !