Log4j zero-day vulnerability has the Internet in a race against the clock
The Internet is in a frenzy racing against the clock with patches to protect against the latest zero-day Internet vulnerability. The vulnerability is tied to a flaw in Log4j (also now known as “Log4Shell”), a Java library for logging error messages in applications.
Jen Easterly, director of the US Cybersecurity and Infrastructure Security Agency (CISA) characterized the severity of the vulnerability in this manner:
“This vulnerability is one of the most serious that I’ve seen in my entire career, if not the most serious. We expect the vulnerability to be widely exploited by sophisticated actors and we have limited time to take necessary steps in order to reduce the likelihood of damaging incident”
What is Log4j
The Log4j library is developed by the open-source Apache Software Foundation and is a key Java-logging framework. Log4j is used in many forms of enterprise and open-source software, including cloud platforms, web applications and email services, meaning that there’s a wide range of software that could be at risk from attempts to exploit the vulnerability.
Log4j vulnerability
The Log4j vulnerability is a remote code execution (RCE) vulnerability, a flaw that will allow a malicious actor to execute any code of their choice on a remote machine over the LAN, WAN, or Internet. The vulnerability first came to light on December 9 and is currently the highest-profile security vulnerability with a severity score of 10 out of 10. The vulnerability is tracked as CVE-2021-44228 in the National Vulnerability Database.
According to the New Zealand CERT:
“Log4j has an unauthenticated RCE vulnerability if a user-controlled string is logged. This could allow the attacker full control of the affected server. Reports from online users show that this is being actively exploited in the wild and that proof-of-concept code has been published.”
The Cybersecurity & Infrastructure Security Agency (CISA) has urged users and administrators to apply the recommended mitigations “immediately” in order to address the critical vulnerabilities.
Figure 1. Log4j attack & how to prevent it.
SOURCE: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
The Log4j JNDI Attacks and How to Prevent It
Systems affected
- Systems and services that use the Java logging library, Apache Log4j between versions 2.0 and 2.14.1
- This includes many applications and services written in Java as well as Apache Struts2, Solr, Druid, Flink, and Swift frameworks.
How to tell if you’re at risk
- Look for Apache Log4j versions between version 2.0 and 2.14.1
How to tell if you’re affected
- Here’s a list of Log4j related software and its vulnerability status provided by NCSC-NL:
https://github.com/NCSC-NL/log4shell/tree/main/software - The log files for any services using affected Log4j versions will contain user-controlled strings.
- Here are some rules to help with detection. Use these commands and rules to search for exploitation attempts against log4j RCE vulnerability:
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
Indicators of compromise
Following the release of the vulnerability, systems using Log4j started to be detected and exploited by hundreds of IP addresses from different countries.
The list here should be checked from the backlogs and added to the block list for potential scans. You can access Active Scanning IP Addresses from GitHub here:
https://raw.githubusercontent.com/CriticalPathSecurity/Public-Intelligence-Feeds/master/log4j.txt
The addresses to call the payload downloading the exploit are listed here:
https://gist.github.com/superducktoes/9b742f7b44c71b4a0d19790228ce85d8
Additionally, members of the Curated Intelligence Trust Group have compiled a list of IOC feeds and threat reports:
https://github.com/curated-intel/Log4Shell-IOCs
Prevention & mitigations
- Vendors with popular products known to be still vulnerable include Atlassian, Amazon, Microsoft Azure, Cisco, Commvault, ESRI, Exact, Fortinet, JetBrains, Nelson, Nutanix, OpenMRS, Oracle, Red Hat, Splunk, Soft, and VMware. The list is even longer when adding products where a patch has been released.
- CISA’s main advice is to identify internet-facing devices running Log4j and upgrade them to version Log4j-2.15.0, or to apply the mitigations provided by vendors “immediately”. But it also recommends setting up alerts for probes or attacks on devices running Log4j.
- Additional steps recommended by CISA include: 1.) enumerating any external facing devices with Log4j installed; 2.) ensuring the security operations center actions every alert with Log4j installed; and 3.) installing a web application firewall (WAF) with rules to focus on Log4j.
- Setting log4j2.formatMsgNoLookups to true by adding:
“‐Dlog4j2.formatMsgNoLookups=True” to the JVM command for starting your application. Note: this mitigation will only work for versions 2.10 and above. - AWS has updated its WAF rule set – AWSManagedRulesKnownBadInputsRuleSet AMR – to detect and mitigate Log4j attack attempts and scanning. It also has mitigation options that can be enabled for CloudFront, Application Load Balancer (ALB), API Gateway, and AppSync. It’s also currently updating all Amazon OpenSearch Service to the patched version of Log4j.
- Microsoft has released its set of indicators of compromise and guidance for preventing attacks on Log4j vulnerability: https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
- IBM said it is “actively responding” to the Log4j vulnerability across IBM’s own infrastructure and its products. IBM has confirmed Websphere 8.5 and 9.0 are vulnerable.
- Oracle also has issued a patch for the flaw:
https://www.oracle.com/security-alerts/alert-cve-2021-44228.html
