Trustwave security and engineering teams became aware of the Log4j zero-day CVE-2021-44228 overnight on December 9. We immediately investigated the vulnerability and potential exploits.

Trustwave infrastructure has not been affected by the vulnerability / exploit. Where there was potential for abuse via the exploit, we have remedied in our environments. We are diligently watching over our customers for exposure and associated attacks, as we are able to detect the exploit in the wild. We are taking action with approved mitigation efforts.

Turn of Events: Log4j Zero-Day

The security team from Alibaba Cloud reported the CVE-2021-44228 to Apache on November 24. The CVE impacts default configurations of Apache frameworks: Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others. It is a remotely exploitable security flaw, which does not require authentication.

CVE-2021-44228 has a CVSS score of 10.0. If exploited, an attacker can take control of a system running Log4j versions 2.0-beta9 to 2.14.1. Log4j is an open-source, Java-based logging utility created by the Apache Software Foundation and is widely used by enterprise applications and cloud services.

On December 9, proof-of-concept exploit was published on GitHub. Cybercriminals began scanning the internet for vulnerable systems.

GreyNoise Intelligence has reported "a sharply increasing number of hosts opportunistically exploiting Apache Log4j CVE-2021-4428". You can get the latest info from GreyNoise in the Tweet thread below.

— GreyNoise (@GreyNoiseIO) December 10, 2021

How To Identify if Your Organization Is at Risk

Organizations utilizing Apache log4j versions between version 2.0 and 2.14.1 are vulnerable.

To identify whether you've been affected, examine the log files for any services using affected log4j versions -- they will contain user-controlled strings. For example, "Jndi:ldap"(per CERT NZ).

Advisories and Mitigations for CVE-2021-44228

The Apache Foundation has issued a critical advisory and recommends users install the latest version, Log4j 2.15.0, and apply mitigations.

According to the advisory: In previous releases (>=2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to "true" or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against RCE by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".

The Cybersecurity Infrastructure Security Agency (CISA) and CERT NZ (New Zealand's national Computer Emergency Response Team) have issued security advisories as well.

At this time, the number of exploitations that have taken place is unknown.

General Guidance on How to Mitigate Zero-Days Moving Forward

An assume-breach mindset is critical to adopt in the age of rampant zero-days. As with all zero-day vulnerabilities, there are basic steps an organization can take to protect itself before and after such a flaw is uncovered.

• Manage Your Assets: Depending on the software you are running, not every instance of a zero-day will affect you. An organization should conduct ongoing asset inventory and vulnerability assessments. Then uninstall any software that is no longer needed and on software still required disable any features that are not necessary. This action will decrease your potential attack surface and may eliminate the impact of certain zero-days that target the removed software or the disabled features.
• Break the Attack Kill Chain: A successful compromise involves many phases, which is good news for you because it gives opportunities to thwart an incursion before it can inflict maximum damage. To accomplish this, however, organizations must continuously monitor their network. Monitoring can be conducted by deploying a full stack of intelligent security products, using generic, behavior, and heuristic-based approaches to threat visibility and detection. Next, utilize threat hunting to search systems for vulnerabilities actively. This activity will help prevent attackers that use zero-day vulnerabilities from gaining initial entry and residing for extended periods in a network.
• Patch, Patch and Patch: Patching after a zero-day has impacted an organization may not stop that attack, but it's still important to ensure all available fixes have been applied. The zero-day may rely on other components to complete its attack. For example, a local privilege-escalation zero-day may exist, but if the system is patched against a remote-code execution vulnerability that is used in tandem with the zero-day, major harm will be avoided. In addition, remember that once the zero-day receives a fix, attackers will still exploit it - and those that are tardy to the patch party may be in for a rude surprise.
• Stay Informed: System Admins need to keep an eye on not only their systems but on the news as zero-day activity, along with other types of attacks, often make headlines. In addition, employees must be trained and made aware that their actions can have negative consequences. This includes clicking on a malicious link that could trigger a zero-day. While perfect behavior is impossible, it's still important to rely on workers, especially if the security products in place do not provide the proactive defense needed to address today's threats. And remember, security awareness programs don't need to be agonizingly boring - effective lessons get creative and use stories to motivate the troops.