Log4j Vulnerability and Cloud Guard AppSec Machine Learning
based Approach for Preemptive Prevention

Initially published: Tuesday, December 14, 2021 at 02:45 PST
Last updated: Saturday, December 18, 2021 at 16:40 PST

Check Point’s Infinity Platform is the only security platform that offered pre-emptive protection for customers against recent Log4j exploits(Log4Shell). Leveraging contextual AI, the platform provides precise prevention of even the most sophisticated nascent attacks, without generating false positives. Customer web applications remain safe as the security auto updates without the need for human intervention or rule sets, as the app and threat landscape evolve and expands.

See AppSec in action and learn more about how it prevented the Log4j exploits.

In this document, we will explain how log4j CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105 exploits work and why Check Point CloudGuard AppSec was able to stop them preemptively, alas new variants coming up within hours.

The first family of Log4j exploits (CVE-2021-44228) make use of the Java Naming and Directory Interface, which allows distributed Java applications to look up services in an abstract, resource-independent way. Certain versions of Log4j allow to include a lookup meta command that orders Log4j to connect to the JNDI on a specified server. Log4j’s JNDI support has not restricted what names and protocols could be resolved. This allowed an exploit, as some protocols are unsafe or can allow remote code execution. Recent patches are now disabling these features by default.

A typical Log4j exploit string looks like this: ${jndi:<protocol>://<server>/}. The first samples of attacks in the wild were using ‘ldap’ as protocol and so signatures that were issued by some traditional IPS and WAF players were looking for ‘${jndi:ldap’. But then other samples appeared using other protocols: “ldaps”, “rmi”, “dns”, “iiop” or “http”, so more signatures were released. This led to a wave of evasions as demonstrated in this publicly published exploit tool on GitHub.

Check Point is witnessing these evasions in real world exploit attempts. Also, Microsoft reported on December 11th: “we’ve seen things like running a lower or upper command within the exploitation string ({jndi:${lower:l}${lower:d}a${lower:p}) and even more complicated obfuscation attempts (${${::-j}${::-n}${::-d}${::-i}) that are all trying to bypass string-matching detections”.

Few days after the first wave, CVE-2021-45046 was published. This newly published Log4j CVE allows attackers to create a Denial of Service, by executing infinite loops on the victim server. This time another feature of Log4j is exploited. Originally the CVSS risk score of this vulnerability was 3.7, but it later changed to 9.0 – Critical.

Log4j enables patterns as a way for developers to add meta-data to a log message. This enriches the log message with content that is dynamically determined at runtime, such as date, time, log level, thread id, etc. It also let developers to customize the log information by utilzing ThreadContext objects, by referring to them as follows: ‘${ctx:}. In certain situations an attacker can make the context refer to itself, resulting in a Infinite Java loop.

On December 18th, 2021 a new CVE-2021-45105 was published with CVSS Risk Score of 7.5. This time describing a new attack that can lead to DoS by triggering an infinite recursion by using native Java constructs with a pattern like ‘${${::-${::-$${::-j}}}}’. Noticeably different from previous ones using jndi and ctx references. As response Apache released Log4J2 Version 2.17.0, sending tens of thousands to upgrade Log4j yet again

The challenge with the types of vulnerabilities described above for signature based WAF and IPS solution is that attack patterns can look differently and so new signatures need to be deployed to block different exploits. If the signature are too “narrow”, they could cause blocking of legitimate traffic. Preemptive protection against cyber attacks, is critical because vulnerabilities may have been known by bad actors before publication and because it naturally takes time for everyone to patch them, also known as “vulnerability window”.

Check Point CloudGuard AppSec

Check Point CloudGuard AppSec is using a Contextual Machine Learning using a three-phase approach for detecting and preventing attacks.

Phase 1 – Payload Decoding
Effective machine learning requires a deep understanding of the underlying application protocols which is continuously evolving. The engine is analyzing all relevant fields, including HTTP headers, which are critical in this case, JSON/XML extraction and payload normalization such as base64 and other decodings. A set of parsers covering common protocols feeds the relevant data into phase 2.

In the case of Log4j, we see in the wild that some exploit attempts are using base64 and escpaing encoding so it is it’s possible to pass (space character) for applying parameters.

Phase 2 – Attack Indicators
Following parsing and normalization, the network payload input is fed into a high-performance engine which is looking for attack indicators. An attack indicator is a pattern of exploiting vulnerabilities from various families. We derive these attack patterns based on on-going off-line supervised learning of huge number of payloads that are each assigned a score according to the likelihood of being benign or malicious. This score represents the confidence level that this pattern is part of an attack. Since combinations of these patterns can provide a better indication for an attack a score is also calculated for the combination of patterns.

In the case of Log4j we had several indicators from Command Injection / Remote Code Execution / Probing families that signaled payloads to be malicious in a very high score which was enough on its own, but to ensure accuracy and avoidance of false positives, the engine always moves to the third and last phase.

Phase 3 – Contextual Evaluation Engine
This contextual engine is using machine learning techniques to make a final determination whether the payload is malicious, in the context of a specific customer/environment, user, URL and field that in a weighted function sums up to a confidence score. If the score is larger than the threshold the request is dropped.

These are the factors that are considered by the engine:

Reputation factor
In each request, the request originator is assigned a score. The score represents the originator’s reputation based on previous requests. This score is normalized and used to increase or decrease the confidence score.

Application awareness
Often modern applications allow users to modify web pages, upload scripts, use elaborate query search syntax, etc. These provide a better user experience but without application awareness, these are detected as malicious attacks. We use ML to analyze and baseline the underlying application’s behavior.

Learn user input format
The system can identify special user input types that are known to cause false detection and apply ML to modify our detection process and allow legitimate behavior without compromising attack detection.

False detection factor
If there is an inconsistency in detection a factor is applied to the confidence score based on the reputation factor per detection location.

Supervised learning module
Optional module that shows administrators payload and ask them to classify them thus accelerating the learning process.

AppSec IPS

In addition to the above Contextual Machine Learning Engine, CloudGuard AppSec employs also additional engines including IPS, Web Anti-Bot, API Protection and Schema Validation.

The IPS engine is based on Check Point’s NSS-award winning technology and uses the same signatures as well as the ability to deploy custom SNORT signatures.

Whenever a new IPS HTTP signature is released by Check Point Research, it is fed automatically to all CloudGuard AppSec agents/gateways without admin intervention.

In the case of Log4j as soon as Check Point released a signature, it was automatically deployed to customers. That was on Friday Dec 10th at 21:30 UTC.

It should be noted that since the attack was already blocked by the preemptive Machine Learning Contextual Engine, the value of the signature in this case was more cosmetic – it allowed a Log that actually indicates the CVE number of the attack.

You can see below two logs – first the one detected by the ML based Engine and then the one detected by the Web IPS:

To ensure that you are protected by CloudGuard AppSec, the only thing you need to do is to make sure that the Web Application or Web API Best Practice of your Asset is set to the Default Prevent Mode. No updates or other settings are needed.