Log4j or Log4Shell, a critical vulnerability in the widely used Apache Log4j Library, has raised alarms and security concerns across the tech and info security communities.

By Rudra Srinivas, Sr. Feature Writer, and Minu Sirsalewala, Editorial Consultant, CISO MAG

The Log4j flaw (CVE-2021-44228), reported last week, is a remote code execution (RCE) vulnerability that enables hackers to execute arbitrary code and take full control of vulnerable devices.

What Is Log4j?

Apache Log4j is a Java-based logging utility developed by the Apache Software Foundation. Several companies use the Log4j library worldwide to enable logging and configure a wide set of applications. The Log4j flaw allows hackers to run any code on vulnerable machines or hack into any application directly using the Log4j framework.

Looking at its severity, MITRE rated the vulnerability as critical and assigned a CVSS score of 10/10.

Affected Systems and Enterprises

The vulnerability reportedly affects systems and services that use Apache Log4j versions from 2.0 up to and including 2.14.1 and all frameworks (Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc.). However, several security experts opine that it also impacts numerous applications and services written in Java.

Microsoft-owned Minecraft was the first to acknowledge the flaw, stating that the Java edition of the game was at risk of being compromised. The company has urged users to upgrade to its latest release and defend against the deployment of the Khonsari ransomware variant exploiting the Apache Log4j vulnerability. The vulnerability is also leveraged to deploy cryptocurrency miners and remote access Trojan Orcus.

“Everything across heavy industrial equipment, network servers, down to printers, and even your kid’s Raspberry Pi is potentially affected by this flaw. Some affected systems may be on-premises while others may be hosted in the cloud, but no matter where they are, the flaw is likely to have an impact,” said Glen Pendley, Deputy Chief Technology Officer at Tenable.

The vulnerable code also affects some of the prominent IT service companies and tech vendors such as Amazon Web Services, Oracle, Cisco, IBM, Fortinet, and VMware.

“This vulnerability, which is being widely exploited by a growing set of threat actors, presents an urgent challenge to network defenders given its broad use. End users will be reliant on their vendors, and the vendor community must immediately identify, mitigate, and patch the wide array of products using this software. Vendors should also be communicating with their customers to ensure end-users know that their product contains this vulnerability and should prioritize software updates,” said Jen Easterly, Director of Cybersecurity and Infrastructure Security Agency (CISA).

Log4j: It’s Severe and Getting Bad 

The flaw’s severity stresses the inevitability of known vulnerabilities, patched vulnerabilities, and half-day and zero-day exploits in the open-source code libraries, often resulting in major data breaches, supply chain attacks, or ransomware attacks.

Experts also uncovered a second critical vulnerability (CVE-2021-45046) that affects all versions of Log4j from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 and could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup or a Thread Context Map pattern to craft malicious input data using a JNDI Lookup pattern, resulting in a DDoS attack. However, CVE-2021-45046 can be mitigated by applying the patch released by the Apache Software Foundation (ASF) in its latest advisory.

Remedial Actions

1. CISA

Federal agencies and security personnel across the globe are working on several mitigation measures to fix this flaw and identify any associated threat activity.

CISA has urged all organizations and security admins to upgrade their systems to log4j version 2.15.0 or apply their appropriate vendor-recommended mitigations immediately to prevent any risks. “To be clear, this vulnerability poses a severe risk. We will only minimize potential impacts through collaborative efforts between the government and the private sector. We urge all organizations to join us in this essential effort and take action,” CISA said.

CISA recommends asset owners take three immediate steps to mitigate the risks from this vulnerability, which include:

• Enumerating any external-facing devices that have log4j installed
• Ensuring your security operations center is actioning every single alert on the devices that fall into the category above
• Installing a web application firewall (WAF) with rules that automatically update so your SOC can concentrate on fewer alerts

For more information, visit Apache Log4j Vulnerability Guidance.

2. Apache Log4j

The Apache Log4j team has issued patches and suggested mitigation steps to address the Log4j security flaw.

• Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.
• Log4j 2.x mitigation: Implement one of the mitigation techniques.
• Java 8 (or later) users should upgrade to release 2.16.0.
• Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
• Otherwise, Apache recommends removing the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

3. Cisco Talos

Cisco Talos in its advisory recommends disabling the JNDI feature.

“For the largest segment of users, JNDI represents an unnecessary risk, so we suggest disabling this feature so that this threat surface is unavailable. Therefore, we recommend upgrading to Log4j 2.16.0—the latest version—which disables JNDI by default,” said Talos.

Per the advisory, Log4j 2.16.0 is the most recent patch Apache has released. It fixes CVE-2021-44228 and CVE-2021-45046 by:

• Disabling JNDI by default and limiting the default protocols to Java, LDAP, and LDAPS.
• Requiring the log4j2.enableJndi system property to be set to “true” to allow JNDI.
• Completely removing support for Message Lookups.
• Customers are encouraged to examine their internal and third-party usage of Log4j for vulnerable configurations and take remediation actions.

“If you are uncertain or unable to determine if your implementation is vulnerable, patch aggressively. Given the risk of third-party appliances that include Log4j, we also recommend that customers and partners conduct routine vulnerability scanning and engage in conversations with vendors, partners, and suppliers for additional mitigation support.”

4. SOPHOS

Sophos’ Naked Security revealed IPS rules, WAF rules, firewall rules, and web filtering could help by blocking malicious CVE-2021-44228 data from outside, and by preventing servers from connecting to unwanted or known bad sites. It recommends that users:

• Patch systems right now. Don’t wait for everyone else to go first.
• Use one of the mitigations if you can’t patch yet.
• Be part of the solution, not part of the problem!

Experts Take 

Commenting on the risks involved with the Log4j vulnerability, Dr. Charlene K. Coon, the Board President of Pentagon Cyber, Inc., said, “It is time for everyone to RETHINK how we approach cybersecurity, particularly in our software development. Log4j v1 reached the end of life in 2015. Log4j v2 has been around since 2015. Log4j v1 has been around since 2001, a full 20 years! Log4j v2 has been around six full years! Every version except for 2.12.2 is vulnerable. Every single one. Businesses might start getting mad that programmers are not checking their code better. We will continue to see businesses devastated by cybersecurity vulnerabilities until the industry demands better. Recently Pentagon Cyber, Inc. and Cyber Science Institute, Inc. have partnered up to drive change and offer solutions to this very large Fukushima software development issue.”

Conclusion

As the year draws to a close, and with the holiday season around the corner, we see a new shift in attack sophistication and scale. And the Log4Shell exploit sounds the alarm that it is much more serious than SolarWinds, Kaseya, or other critical infrastructure attacks reported in the last two years.

About the Authors

Rudra Srinivas is a Senior Feature Writer and part of the editorial team at CISO MAG. He writes news and feature stories on cybersecurity trends.       

More from the Rudra.

Minu Sirsalewala is an Editorial Consultant at CISO MAG. She writes news features and interviews.

More from Minu.

The post Log4j Explained: How It Is Exploited and How to Fix It appeared first on CISO MAG | Cyber Security Magazine.