The last few days for many developers can only be described as frantic and scary. The source of all this is the Apache Log4j2 remote code execution vulnerability (CNVD-2021-95914) that has been published. The damage from this open source component, now used by almost every technology giant, will have a ripple effect. According to incomplete statistics from industry bodies, the vulnerability affects 6W + popular open source software and more than 70% of enterprises’ online business systems! The vulnerability is as widespread and damaging as the “Eternal Blue” vulnerability that put millions of hosts at risk of ransomware attacks in 2017.

Vulnerability analytical

Apache Log4j RCE vulnerability is not only easy to exploit, but also potentially harmful. This crisis is caused by the Lookup function, which is enabled by default in Log4j2 to provide customers with another way to add special values to logs. This functionality also includes a Lookup for JNDI, but because a Lookup does not impose any restrictions on the loaded JNDI content, an attacker can use JNDI injection to remotely load malicious classes into an application, resulting in RCE.

Apache Log4j 2.x <= 2.14.1 will be affected. Possible affected applications include but are not limited to: Spring-boot-strater -log4j2, Apache Struts2, Apache Solr, Apache Flink, Apache Druid, Elasticsearch, Flume, Dubbo, Redis, Logstash, Kafka, etc. Popular frameworks such as SpringBoot, JBoss, and Solr are included in dependencies that directly apply log4J-Core. The vulnerability affects almost all users of Log4j2 2.15.0, including 2.15.0-rc1.

Just four steps, with the help of Ali Cloud ARMS application security, fully intercept Log4j2 vulnerability attacks

The Log4j2 vulnerability, as a logging framework, compared with logging and other types of normal behavior, command injection, execution, itself is an obvious abnormal behavior.

By default, RASP blocks all dangerous behavior due to unsequence, JNDI injection, arbitrary file reads, and malicious file uploads. Unlike traditional defense methods based on traffic characteristics, RASP is based on behavior and Application Runtime context, does not fall into feature exhaustion and focuses more on “normal baseline”. That is, the normal usage behavior of the application. If the behavior (such as command execution) does not belong to the normal operation of the function, the application will be blocked.

This vulnerability is a command execution vulnerability caused by THE JNDI function of Log4j2. In RASP overridden scenarios, it can be defended by default without new rules. Therefore, ARMS application security is based on Ali Cloud RASP technology to attack and defend against the above vulnerabilities.

1. Log in to the Ali Cloud ARMS console

Note: Ali Cloud ARMS Probe version Container service application/EDAS application automatic upgrade scenario >=2.7.1.2, other scenarios (manual upgrade)>=2.7.1.3. If you enable the access to ARMS application security for the first time, restart the application instance.

2. In the navigation tree, choose Application > Attack Statistics

ARMS application security identifies and reports attack behavior events when attacked by Log4j2 remote code execution vulnerability. You can also configure alarm rules to receive attack alarm notifications through SMS, nailing, and email. By default, the defense mode is monitoring. You are advised to observe for a period of time and then adjust the defense mode to monitor and block. Once attacks occur, you can block them to ensure the safe running of applications.

3. In the left navigation bar, choose Application Security > Dangerous Component Detection to automatically analyze the CVE vulnerability library associated with third-party components and provide repair suggestions

4. Full self-check of dangerous components. Check whether all access applications contain Log4j components and determine component versions

Fixes upgrades and recommendations

(1) Check whether the application has imported Apache Log4J-Core Jar package. If any dependency is introduced and the version is within the affected range, vulnerabilities may exist. Please upgrade Apache Log4j2 to the latest log4J-2.15.0-Rc2 version as soon as possible.

Address: https://github.com/apache/Logging-Log4j2/releases/tag/Log4j-2.15.0-rc2

(2) Upgrade known affected applications and components, such as spring-boot-starter-log4j2 /Apache Struts2/Apache Solr/Apache Druid/Apache Flink.

(3) JDK version can be upgraded to more than 6U211/7U201/8U191/11.0.1, which can limit JNDI and other vulnerability utilization methods to a certain extent.

(4) Stop opening ports to the outside world as far as possible, strengthen the application certificate verification management and control, and reduce the external network attack surface as much as possible.

(5) Enable the combination of Web application firewall and RASP on the exnet, and adopt the behavior and application runtime context defense strategy.

(6) In the security configuration evaluation, strictly control the security of open source software, and build the internal security version database and update it in time.

(7) Establish a multi-layer detection defense system, adopt Intranet multi-layer isolation, and comprehensively improve the threat detection capability.

Click here for more information about application security!