What to Do While Waiting for the Log4J Updates

Researchers are warning that attackers are actively exploiting the newly publicized unauthenticated remote code execution vulnerability in Log4j, the Java-based logging tool from Apache. While the bulk of the work to mitigate CVE-2021-44228 falls on application owners and software developers, enterprise security teams also have to do their part to keep their organizations secure.

This Tech Tip provides short-term mitigations for affected enterprise security teams who don’t yet have updates available, can’t install the updates right away for whatever reason, or won’t be receiving updates at all.

Consider the following scenario: a vendor has a financial application that uses Java and the vulnerable version of Log4j. Any organization that uses the client application to access that Java application is also vulnerable to remote code execution since the client is also likely using Log4j. In this scenario, the organization is in a tougher position because it has to wait for the vendor to update both the main application and the client. That could be never for a legacy application.

“Any java application using the affected log4j versions and accessible over the network can be exploited, and many of those applications are likely third-party and out of the user’s hands administratively,” says Karl Sigler, Senior Security Research Manager, Trustwave SpiderLabs.

Step 1: Identify Exposure

The potential attack surface is incredibly large, says Luke Richards, Threat Intelligence Lead at Vectra. Randori has an application that helps check whether the log4j instance is vulnerable. You can search for the presence of JAR files log4j-core-*.jar to determine if log4j is in use.

The security flaw (CVE 2021 44228) exists in versions of Log4j before 2.14.1, so any Java application that uses the vulnerable version is at risk. A number of Apache tools are vulnerable — Struts 2, Solr, Druid, and Fink – but the issue goes far beyond that list because Java is so widely used in the enterprise.

The number of total scans against the Log4j vulnerability increased three-fold in a single day, BitDefender Labs says. The figures are based on telemetry from Bitdefender’s global honeypot network. Most of the scans originate from Russia-based IP addresses, the team says.

The initial vector is also difficult to detect because it requires looking through the logs for a specific string, Richards says. Analysts can look at the raw input to the log4j server and alert on all LDAP external connections, or look for external connections from log servers to Java class files, Richards says. The patterns in text fields such as User-Agent: /\$\{jndi:.*/  are “telltale sign of attempts to compromise servers,” Richards says.

Organizations need to identify which of their applications are using the vulnerable component, says Avi Shua, Co-Founder & CEO of Orca Security. One way to do that is with continuous scanning tool. Assets that are external-facing should be blocked. “We recommend blocking external-facing applications that use the vulnerable library, unless there is certainty that this vulnerability is not exploitable or an updated version is released,” says Shua.

Yara rules
to search for potential compromise attempts have also been released.

Richards recommends finding hosts potentially running log4j (Apache Tomcat and Struts, for example) and moving them into a group to make them easier to monitor and follow up.

In the original scenario, the organization blocked LDAP, and potentially RMI and the CORBA. End users can update with other people in the group, Sigler says. The organization should block LDAP traffic (and potentially RMI and CORBA depending on future variants), and monitor traffic.

Step 2: Apply Mitigations

Update to the latest version of Java, as it will prevent loading a remote codebase using LDAP, says Bojan Zdrnja, Senior Instructor at SANS Institute and Chief Technical Officer at INFIGO. “The current exploitation mechanism is blocked by the latest version of Java, which sets com.sun.jndi.object.trustURLCodebase to true,” Zdrnja says.

If Log4j cannot be updated, setting the log4j2.formatMsgNoLookups parameter to true when starting the Java Virtual Machine makes the vulnerability not exploitable, Apache says in its advisory. The command-line option is -Dlog4j.formatMsgNoLookups=true . Setting the JVM flag (log4j2.formatMsgNoLookups=true) in a component.properties file on the classpath also prevents lookups in log event messages.

Apache also suggests manually removing the JndiLookup class from the classpath
(zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class) to protect against remote code execution. Removing the Jndi Manager class from will cause JndiContextSelector and JMSAppender to no longer function.

Specifying %m{nolookups} in the PatternLayout configuration prevents lookups in log event messages.

Another option is for the organization to control outbound traffic at the perimeter and block LDAP and RMI traffic, if possible, Zdrnja says.

Step 3: Use Existing Protections

The above methods assume that updates will eventually become widespread. In the case of legacy applications, there will not be any updates, security or otherwise. Legacy tools “must use some kind of other runtime protection,” says Arshan Dabirsiaghi, Co-Founder & Chief Scientist, Contrast Security. An application-level RASP is perhaps the most robust.

WAFs aren’t as effective here because the input might not come from HTTP in modern architectures, the exploit path contains out-of-band elements, and blocking this attack at the perimeter may also end up triggering false positives and disrupting normal traffic, Dabirsiaghi says.

That said, Cloudflare has released new signatures for its Firewall to block the malicious activity on the application level. The rule block the jndi lookup in common locations in an HTTP request.  Other web application firewall vendors are expected to follow suit shortly.

Step 4: Update

There is only thing in this step: Apply patches and update as soon as possible.

Read More HERE