How to strengthen application security capabilities and fully intercept Log4j vulnerability attacks

For many developers in recent days, it can only be described as race against time and fear. The source of all this comes from the published Apache Log4j2 remote code execution vulnerability (CNVD-2021-95914). At present, almost all technology giants are using this open source component, and its harm will bring a series of chain reactions. According to incomplete statistics from industry organizations, this vulnerability affects 6w+ popular open source software and affects more than 70% of enterprise online business systems! The extent of the vulnerability and the degree of damage are comparable to the "Eternal Blue" vulnerability that exposed millions of hosts to the risk of being attacked by ransomware in 2017.

Vulnerability analysis

The reason why the Apache Log4j RCE vulnerability has such a big impact is not only its ease of use, but also its huge potential harm. This crisis was triggered by the Lookup function. Log4j2 will turn on the Lookup function by default, providing customers with another way to add special values ​​to the log. This function also includes Lookup for JNDI, but because Lookup does not impose any restrictions on the loaded JNDI content, an attacker can remotely load malicious classes into the application through JNDI injection, thereby causing RCE.

It is reported that all versions of 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. The dependencies that directly apply Log4j-core include popular frameworks such as SpringBoot, JBoss, and Solr. The vulnerability affects almost all users who use Log4j2 2.15.0, including 2.15.0-rc1, which has been bypassed.

Only four steps are required to fully intercept Log4j2 vulnerability attacks with the help of Alibaba Cloud ARMS application security

The Log4j2 vulnerability, as a logging framework, compared to the normal behavior of logging and other types, command injection and execution itself are obviously abnormal behaviors.

Under the default rules, RASP will block all dangerous behaviors such as deserialization, JNDI injection, command execution, arbitrary file reading, and malicious file upload. Different from the traditional defense method based on traffic characteristics, RASP (Runtime Application Self-Protection) is based on behavior and application runtime context, and will not fall into feature exhaustion and pay more attention to the "normal baseline". That is, what are the normal usage behaviors of the application? If this behavior (such as command execution) does not belong to the normal operation of the function, it will be intercepted.

This vulnerability is a command execution vulnerability caused by the JNDI function of Log4j2. It is in a RASP coverage scenario and can be defended by default without adding new rules. Therefore, ARMS application security is based on Alibaba Cloud RASP technology for attack protection against the above-mentioned vulnerabilities.

1. Log in to the Alibaba Cloud ARMS console

Note: Alibaba Cloud ARMS probe version container service application/EDAS application and other automatic upgrade scenarios>=2.7.1.2, other scenarios (manual upgrade)>=2.7.1.3. The application is opened for the first time to access the ARMS application security, and the application instance needs to be restarted.

2. In the left navigation bar, select Application> Attack Statistics Page

When being attacked by the Log4j2 remote code execution vulnerability, ARMS Application Security will identify and report the attack behavior event. You can also configure alarm rules to receive attack alarm notifications through SMS, DingTalk, email and other channels. The default protection mode is monitor mode. It is recommended to adjust the protection setting to monitor and block after observing for a period of time. Once an attack occurs, it can be directly blocked to ensure the safe operation of the application.

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

4. Full self-examination of dangerous components, search to see whether all connected applications contain Log4j components, and determine the component version

Repair upgrades and suggestions

(1) Check whether the application has introduced the Apache Log4j-core Jar package. If there is a dependency introduction and it is within the scope of the affected version, there may be a vulnerability. Please upgrade all related applications of 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 the applications and components that are known to be affected, such as spring-boot-starter-Log4j2/Apache Struts2/Apache Solr/Apache Druid/Apache Flink.

(3) The jdk version can be upgraded to 6u211 / 7u201 / 8u191 / 11.0.1 and above, which can restrict the use of vulnerabilities such as JNDI to a certain extent.

(4) As much as possible to prevent external open ports, strengthen application certificate verification management and control, and minimize the external network attack surface.

(5) Open the Web application firewall + RASP combination on the external network, and adopt behavior and application runtime context defense strategies.

(6) During the security configuration assessment, the security of open source software is strictly controlled, and the internal security version library is built by itself and updated in time.

(7) Establish a multi-layer detection and defense system, adopt multi-layer isolation on the internal network, and comprehensively improve the threat detection capabilities.

Click here , application security to see more information!