On Thursday, 9^th December the Apache Foundation released an emergency update for a critical zero-day vulnerability in Log4j. Log4j is Java based logging tool used in servers and services all over the world. It is used by many companies including Apple, Amazon, Cloudflare, various Apache server types.

The critical vulnerability has been named Log4Shell and has received the identifier CVE-2021-44228. Log4j versions 2.15.0 and prior are subject to the vulnerability. CVE-2021-44228, received a CVSS severity score of 10.0, which is the maximum and is widely believed to be easy to exploit.

Many cybersecurity researchers have warned that hundreds of thousands of attempts to remotely execute code using the Log4j vulnerability have been detected in only a few days.

Since its discovery, Log4Shell has been exploited to release AWS keys, set up coin miners, and install remote access tools including Cobalt Strike to victims environments.

The impact of this vulnerability is huge and the speed at which attackers are using it is set to cause a disrupt to the cybersecurity sector over the coming weeks.

Affected Version

Apache Log4j 2.x <= 2.15.0-rc1

Affected Software

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

How it’s exploited in the wild

We have seen instances of payloads including cryptominers like Golang-based Kinsing ELF payloads, however this is only the beginning of it. This has the potential to scale massively as attackers ramp up their infrastructure to take advantage of this exploitation opportunity.

What happens now?

The CVE-2021-44228 vulnerability is still being actively investigated in order to properly identify the full scope severity. As 0-day vulnerabilities go this has an extremely high rating, meaning that attackers can remotely exploit it without any input from the victim and without high-level technical expertise. Furthermore, finding Log4j is a challenge as the way that Java packaging works, it is very possible that you could have Log4j hiding somewhere in your application and not know about it.

Mitigation Guidance

• Upgrade log4j 2 to the latest version, specifically log4j-2.15.0-rc2 or newer.
• According to Apache’s guidance, in releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Smarttech247

Sources: – https://securityboulevard.com/2021/12/log4shell-jndi-injection-via-attackable-log4j/

https://unit42.paloaltonetworks.com/

https://www.sentinelone.com/blog/cve-2021-44228-staying-secure-apache-log4j-vulnerability/