Log4j Vulnerability Security Bulletin

What Happened

On Friday December 10, 2021, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued an alert based on the Apache Software Foundation security advisory regarding a critical (CVSS score of 10 out of 10) remote code execution vulnerability affecting Log4j.

• Log4j is a popular Java library developed and maintained by the Apache Foundation, and it is used in many commercial and open-source enterprise applications and cloud services as a Java logging framework.
• The purpose of Log4j is to take Java logs and, among other actions, parse, correlate, and alert on them as needed. The vulnerability results from how log messages are being handled by the Log4j processor.
• More specifically, the Log4j vulnerability is caused by the fact that inputs are not “sanitized,” and malicious arbitrary code can thus be processed and executed by Log4j version 2.0 to 2.14.1 as a result. If an attacker sends a specially crafted message, this may result in the execution of that code. Put another way, the exploit allows an attacker to load unauthorized Java code onto a server and run it as a command, and to potentially take control.
• The updated version of Log4j (2.17.0) has disabled the vulnerability by default.

Why It’s Important

As noted above, Log4j is an open-source, Java-based logging utility widely used in Apache web servers and many other enterprise applications and cloud services. While a patch is available, given the extent of Log4j™s use, an organization is still very much at risk as this library is so widely used “ both in internally-developed applications and third-party products. Bottom line, if your enterprise has this Java library in any of its enterprise software and cloud services, it is vulnerable if not updated to Log4j 2.17.0.

While the vulnerability could conceivably be exploited to target critical infrastructure, current reporting suggests the exploitation attempts have been limited to the deployment of large-scale botnet malware such as Mirai2, Kinsing3 and Tsunami3 to launch DDoS attacks (Mirai, Tsunami) or to mine cryptocurrencies (Kinsing).

What to do about it

Immediate Guidance

CISA has created this web page with guidance for managing the Log4J vulnerability: https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance.

CISA recommends asset owners take additional, immediate steps regarding this vulnerability:

1. Enumerate all devices that have Log4j installed.
2. Use CERT/CC’s scanner to identify assets that are vulnerable.
3. Make sure that your security operations center is actioning every single alert on devices with Log4j installed.
4. If possible, block outbound LDAP, DNS, and RMI except for documented business need to specific endpoints.
5. If possible, install a web application firewall (WAF) with rules that automatically update so that your SOC can concentrate on fewer alerts

More generally, it is important to continuously monitor known vulnerable devices.

• CISA recommends going as far back as December 1 or earlier for potential exploitation.
• Be aware that the patch only prevents future exploitation of Log4j. Even if you are patched, if your organization was exploited prior to the patch, a malicious actor may still have access.
• Be sure to engage your vendors regarding this vulnerability, especially if they do not have an official press release related to Log4J.

In a blog released on December 12, 2021, the Swiss government’s Computer Emergency Response Team (GovCERT), provided the following recommendations:

• As quickly as possible, try to get an overview of systems and software using Log4j in your environment (both internally developed and third-party software).
• Apply the corresponding security patches for internet facing software/devices immediately.
• Apply the corresponding security patches for internal software/devices at your earliest convenience.
• If patching is not possible for whatever reason, isolate the system from the Internet and/or apply identified mitigations measures such as:

• • For version greater than or equal to 2.10, set œLog4j2.formatMsgNoLookups to TRUE
  • For releases from 2.0 to 2.10.0, remove the LDAP class from Log4j completely by issuing the following command: ‘zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class’
  • For certain JVM Versions, it is possible to set ‘com.sun.jndi.rmi.object.trustURLCodebase’ and ‘com.sun.jndi.cosnaming.object.trustURLCodebase’ to “false” to mitigate the vulnerability. Some JVM versions already have this as default setting

• You may check for exploitation attempts in your web server logs using the following Linux/Unix command: ‘sudo egrep -i -r ‘${jndi:(ldap[s]?|rmi|dns):/[^n]+’ /var/log/’ and check your network perimeter logs for the presence of botnet indicators of compromise (IOCs).
• If you use a Snort or Suricata based (or compatible) Network Based IDS, you may want to use rules to detect exploitation attempts.
• If you have systems that are vulnerable, check them very carefully for any sign of exploitation as the scanning is very intense and we believe that vulnerable systems got exploited quickly.
• If you are using a WAF, deploy the Log4j specific rules. These exist for many commercial solutions such as Cloud Armo Cloudflare WAF, Signal Sciences WAF.

Applying Best Practice

Defenders can apply the following guidelines and best practices to address risks from the Log4j vulnerability and other disruptive cyber threats:

• Threat-informed defense. The Chertoff Group recommends that security practitioners apply security controls based on anticipated adversary behavior and an assumption that a breach may already have occurred. If attackers have already breached your network before you update to Log4j 2.17.0, they may lay dormant as they observe your network and choose the best ransomware data to target. By understanding the anatomy of recent attacks and associated tactics, techniques and procedures (TTPs), defenders can ensure risk-based defenses are in place. The MITRE Corporation’s Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework can help through its library of mappings between TTPs and defensive countermeasure coverage.

• Validating control effectiveness. Critical infrastructure owners & operators should also validate that defensive countermeasures are operating as intended. As more details emerge from the Log4j vulnerability, defenders should ensure existing security controls are effective against identified TTPs.

The Chertoff Group has deep experience helping organizations of all sizes rapidly implement threat and risk-informed cyber defenses. Contact info@chertoffgroup.com for more information.