Log4j RCE and mitigation techniques

For quite some time it seemed as if cyber vulnerabilities in the Java ecosystem would be losing ground. Instead, it was the calm before the storm: a vulnerability in the Log4j library threatens web servers and other applications in a variety of ways.

Log4j RCE made its first appearance on December 1st, 2021. That’s how far you need to backdate your analysis, if not more.

Matthew Prince, the Co-founder & CEO of Cloudflare (NYSE: NET), declared on Twitter:

‘Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC. That suggests it was in the wild at least 9 days before publicly disclosed. (…)’.

Also, look for signs of malware mining crypto on your systems.

Log4j RCE out in the wild

It’s very hard to avoid using the Log4j library. It is ubiquitous. Talos Intelligence Group, a security arm of Cisco, said that it observed a lead time between attackers’ active penetration attempts and callbacks from affected systems, which may indicate lateral movement.

Log4j is used in software running on a wide variety of systems, not just traditional web servers. Vulnerable systems include SIEMs and log collectors.

Attackers may use a plethora of protocols, including LDAP(S), RMI, DNS, NIS, IIOP, CORBA, NDS and HTTP, and a variety of obfuscation techniques.

So far, botnets such as Mirai are having great success taking advantage of this vulnerability. Mirai is a malware that targets smart devices which run on ARC processors, turning them into a network of remotely controlled bots or ‘zombies’. Those networks of bots (a.k.a. ‘botnets’), can be misused to launch DDoS attacks.

Log4j RCE (also known in the NIST database as CVE-2021-44228) scored a maximum of 10.0 points on the CVSS severity scale.

How dire the situation is show lists of vulnerable products at VMware and Cisco. (Don’t look. It’s nauseating.)

There is a perfect storm brewing that will occupy the Java community in the months ahead, maybe even much longer. It is not enough to merely identify affected packages. They need to be patched URGENTLY.

Here is what happens

Here is a quick overview of the attack on the main vector:

an attacker injects JNDI lookup (JNDI is Java Naming and Directory Interface, a Java API for a directory service that allows Java software clients to discover and look up resources) into something that’s going to be logged.
Log4J logs the string, which causes it to query a malicious LDAP server under the attacker’s control
the LDAP server returns malicious code
bad things happen

Workarounds for Log4j RCE

What can you do to dodge this rolling calamity? For the time being, your options include:

applying a patch to your Log4J library (to at least log4j-2.1.50.rc2)

But what if you cannot upgrade? You could use the vulnerability to patch itself with Logout4Shell, actually.

Other things that might help:

blocking $(jndi:ldap:// in your web application firewall
disabling JNDI lookups by setting the system property ‘log4j2.formatMsgNoLookups’ to true
replacing and disabling Log4J entirely, but that’s somewhat more drastic

Also, it might be temporarily advisable to remove the JndiLookup class from the classpath that’s used by Java.

The Five Eyes Alliance—intelligence agencies in the United States, United Kingdom, Australia, Canada, and New Zealand—issued a Cybersecurity Advisory offering guidance for mitigation of Log4j related vulnerabilities.

Before you can roll up your sleeves, though, you need to figure out which systems, if any, are affected.

Scanners for Log4j RCE

Luckily, Log4J RCE scanners are free and open source.

While it is certainly possible to misuse Log4j to exfiltrate Java system properties, that’s unfortunately not all there is to it. According to the NCC Group, AWS secrets are also affected.

On the upside…

Java is back!

According to ‘The State of Developer Ecosystem 2021″ by JetBrains, 69% of all developers in large-scale enterprises around the globe rely on Java.

From the get-go, Java JDK 8 was a hit with developers, JDK 11 not so much. Mostly because Oracle antagonized its user base with a licensing that was widely seen as a rip-off. A counter-revolution soon emerged and became known as OpenJDK.

The exodus got so bad that even Oracle took notice.

And it kept getting worse, before only recently, Java finally began turning the corner with JDK 17.

How do you know that Java is back? When you have world-class hackers in your rear-view mirror, you know you made it back to the top.

The road ahead

The Log4j RCE is here to stay for some time, perhaps even a year. Log4j is sure to cause nightmares for affected system administrators, Java developers and others in charge of cyber security.