Hardening Log4j defenses with new Contrast Protect JNDI Injection rule

It’s been a year since many Application Security (AppSec), IT and development teams around the globe were sent scrambling to shore up defenses against the infamous Log4j zero-day attack (CVE-2021-44228). 

Long days, nights and weekends were spent over a traditional holiday period to sort out the issue, patch and prevent damage.

It’s a problem that hasn’t gone away. The U.S. Department of Homeland Security believes Log4j is an “endemic” problem that will pose security risks for potentially a decade or more.

The Contrast Security Runtime Application Protection (aka Runtime Application Self-Protection [RASP]) offering — Contrast Protect — has been a bright star in preventing the Log4j zero-day attack, helping to keep the initial attack from causing damage. Teams that had Contrast Protect deployed got to enjoy their holidays last year, unlike teams that were exposed. Over the course of the year, Contrast has continued to fortify against Log4j and related attacks. 

But Log4j is still out there, and it’s still a serious threat. Contrast data shows that up to this point, one year after Log4j’s emergence, only 50% of organizations have upgraded to a fully fixed version of Log4j, which means that many are still exposed to potential breach. As well, other attacks similar to Log4j — as in, other Java Naming and Directory Interface (JNDI) injection attacks — have been discovered in other libraries, such as the Log4j alternative logback. 

Because of these continuing and evolving threats, Contrast has added explicit proactive protection against the entire class of JNDI injection attacks to Contrast Protect. Protect JNDI Injection is a specific rule set that leverages internal telemetry that the deployed Contrast agent sensors read to detect JNDI injection or Log4Shell attack.  

JNDI is a lookup feature that comprises an application program interface (API)  and service provider interface. Several directory services integrate via the service provider interface, including Domain Name System (DNS), Lightweight Directory Access Protocol (LDAP) and Network Information Service (NIS). 

The Log4Shell exploit tries to use JNDI lookups to request data from any LDAP server.  Before the service blindly loads the raw binary data from the URL, the Contrast Protect agent will detect anomalous behavior.

Why this matters

With Contrast Protect, Contrast has always tried to follow the principle of creating rules that protect against a class of vulnerabilities instead of tracking individual Common Vulnerabilities and Exposures (CVEs). Contrast Protect has the ability to add specific CVE protection, but the power of the protection mechanism lies in its ability to completely stomp out a vulnerability class, just as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) have done for *nix systems. 

To that end, we created a specific detection mechanism for JNDI injection vulnerabilities that enables an application to rely on Contrast’s Protect solution to cover all JNDI injection attacks, even if they have not been identified as CVEs. Of course, the rule protects against CVEs as well.

This is essential, given that every new vector that’s used to exploit a JNDI injection entails individual CVEs.

Protect’s JNDI rule is a microcosm of what makes Contrast’s technology so special: it proactively detects attacks and does not rely on existing information and lookups. The following example will illustrate why.

Log4Shell example

Oftentimes, one-off CVEs are not enough to prevent an attack. In the case of Log4Shell, there was one original CVE that covered the initial vulnerability — CVE-2021-44228.  Within two weeks, three more CVEs were released. Days later, CVE-2021-42550 described a vulnerability in logback (another logging framework for Java) wherein users could take advantage of a vulnerability in logback so as to escalate to a JNDI injection exploit that would ultimately result in remote code execution (RCE). 

Protection for the Log4j CVE does not provide the same protection for the logback CVE. When the logback vulnerability was added on top of the Log4j issue, organizations had to manage two CVEs for two uniquely different logging frameworks that may be used in many of their Java applications. Not having the ability to protect against the vulnerability class (JNID injection), organizations were left scrambling to update their libraries, make sure their Web Application Firewalls (WAFs) were patched numerous times or take applications offline while they determined the path forward. This wash, rinse and repeat process continued over a two-week period with multiple Log4j CVEs. Organizations’ exhausted security and development teams ran out of steam.  

The danger is real, expensive, arduous and still present. Almost half of Log4j has not been fully patched. As well, JNDI injection has been found in other libraries, including logback. However, with Contrast’s Protect technology, the playing field changes.  A given application can be protected from an entire class of attacks without the need to individually update, patch and maintain the entire encyclopedia of CVEs. 

And now, with the release of the JNDI Injection rule, Contrast Protect can protect against any type of JNDI injection attack: Just set it and forget it.

Click here for a demo.