New developments on the Log4J 0-day exploit.

Unfortunately, Log4J vulnerabilities aren’t yet fully resolved and in the last few days, two new vulnerabilities have been found. The latest Log4J version is now 2.17.0 and you should update as soon as possible. As mentioned in the previous blog post, we are now seeing an increase of attacks, like ransomware, worms, etc…

Table of Contents

• What happened in the last few days?
• I don’t have any Java applications on my infrastructure, should I be concerned?
• How to fix it
• How to test it

What happened in the last few days?

Since the finding of CVE-2021-44228, researchers, IT security experts, and pen testers have been busy trying to find more exploits on the logging universe (Log4J and logback), and they did.

• CVE-2021-42550 reports a vulnerability on Logback, LOGBACK-1591, that’s fixed by version 1.2.9, though, it requires write access to the configuration files. Logback decided to remove some functionalities.
• CVE-2021-45105 reports a vulnerability on Log4J that affects all versions from 2.0-alpha1 through 2.16.0 (excluding 2.12.3), which allows the attacker control over thread context map (TCM) data, allowing a possible DOS on crafter string interpretation.
• CrowSec shared a gist, with a list of IP Addresses that are exploiting CVE-2021-44228 vulnerability.
• Apple XCode team is aware of a possible vulnerability, since it ships a Java Runtime and Apache Log4J 2.11.2 (on version 13.2.1) is included.
• Google’s open-source team scanned Maven Central and found 35,863 Java packages use Apache Log4J vulnerable versions. These include CVE-2021-44228 and CVE-2021-45046).

Ransomware

• A specific kind of ransomware was already detected, as BleepingComputer shared, targeting Windows and Linux devices with vulnerable versions of Apache Log4J.
• Conti ransomware has been detected that uses Log4Shell exploit to gain rapid access to the internal VMWare vCenter Server instances and encrypt virtual machines.

Mining Monero

Instead of using the now popular JNDI LDAP vulnerability, attackers switched focus to JNDI RMI (or used both) to maximise the chances of success.

Worms

A possible Log4J worm identified by Germán Fernández has been tweeted by vx-underground. But Marcus Hutchins, aka MalwareTech, reverse engineered and considered the worm as completely ineffective and harmless, since it doesn’t self-propagate.

I don’t have any Java applications on my infrastructure, should I be concerned?

Yes, you still should be. Given how popular Java is, it’s very likely you might be running Java software on your infrastructure that contains an affected version of Apache Log4J.

You should keep an eye on the following curated lists that are updated daily with known vulnerabilities:

• https://www.bleepingcomputer.com/news/security/log4j-list-of-vulnerable-products-and-vendor-advisories/
• https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
• https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

How to fix it?

Before applying any possible fix you find, be mindful that it might be outdated or wrong and it will still leave you vulnerable to attacks. Always double-check and test it locally, if possible. A curated list of common bad advice is available here.

You should make use of trusted tools like grype, Log4j-scan or Log4 Scanner and search for vulnerabilities ong applications, docker images, tools, etc…

We strongly encourage you to update to the latest version if you can: https://logging.apache.org/log4j/2.x/download.html.

The other options available while you upgrade the dependency are:

• Disable JNDI lookups in log4j versions >= 2.10.0, by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• On versions < 2.10.0, remove the JndiLookup class from the classpath.

Kubernetes (AWS)

AWS has developed an RPM that performs a JVM-level hot-patch which disables JNDI lookups. There are more details here on how to apply it.

What not to do

• Apply a rule in your web application firewall (WAF). You are still susceptible to nested payloads.
• Update every logging pattern to have %m{nolookups} instead of %m on logging config files.

How to test it?

Details on how to test this vulnerability are available here.

Marcus Hutchins also shared a YouTube video on his process of investigating a malware intrusion attempt.

Sources:

• https://www.bleepingcomputer.com/news/security/tellyouthepass-ransomware-revived-in-linux-windows-log4j-attacks/
• https://blogs.juniper.net/en-us/threat-research/log4j-vulnerability-attackers-shift-focus-from-ldap-to-rmi
• https://www.bleepingcomputer.com/news/security/log4j-attackers-switch-to-injecting-monero-miners-via-rmi/
• https://www.bleepingcomputer.com/news/security/log4j-list-of-vulnerable-products-and-vendor-advisories/
• https://therecord.media/google-more-than-35000-java-packages-impacted-by-log4j-vulnerabilities/
• https://www.bleepingcomputer.com/news/security/conti-ransomware-uses-log4j-bug-to-hack-vmware-vcenter-servers/
• https://thehackernews.com/2021/12/hackers-begin-exploiting-second-log4j.html?m=1
• https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/
• https://twitter.com/LiveOverflow