Apache Log4j2 remote code execution vulnerability has broken out for a week. Security vendors provide various defense solutions and detection tools, and Party A’s team worked overnight to make emergency response.

The influence continues to this day, the Internet spread a variety of use and bypass posture is still emerging, the impact continues to expand. All security people are beginning to rethink the question: are the current defences effective? What would be the effective means for such a day to happen again?

Ali cloud security team participated in many customer emergencies this time, and summarized experience from the cloud platform’s own defense, trying to throw out some views for discussion.

First, let’s take a technical look at why Log4j2 is so difficult this time.

Apache Log4j2 vulnerabilities

The Log4j2 bug has two tricky features:

Arbitrary remote code execution can be implemented

“Understand the rules” loopholes, dangerous use of high threshold, the use of low threshold harm is small, but also in line with the law of nature. This loophole does not play cards according to the convention, not only impact wide, use of low threshold, the harm is also great. All three factors overlap and are hailed as “epic” everywhere.

Java is widely and ecologically used, while Log4j is used by almost all applications as a fundamental component of logging processing.

Arbitrary remote code execution through JNDI injection means that an attacker can do whatever he wants on a vulnerable server.

Even if JNDI external connection fails on the Intranet, an attacker can read a lot of sensitive information (such as database passwords and JAVA environment variables) using the LOOKUP feature, and then take the sensitive information out of the Intranet through the DNS protocol.

Traffic feature concealment

In some scenarios there are few strong features that can be distinguished from normal requests.

The PoC structure of this vulnerability is very simple, the trigger points of vulnerability are wide and flexible, and the nested bypass mode of various variables and protocols leads to very complex and hidden traffic characteristics. ${aaa:vv:cc:-j} Ndi {upper:JN}di ${aaa:vv:cc:-j} Ndi {upper:JN}di ${aaa:vv:cc:-j} Ndi Can break the continuity of the string, resulting in the use of traffic characteristics is very unclear.

This is a huge challenge for all security protection products based on traffic characteristics.

When traffic characteristics are not obvious, rules based on traffic characteristics fall into an embarrassment: they either fail to cover or generate serious false positives. You just keep adding rules, going around and around. This defense can be very effective in buying time to fix vulnerabilities in the early stages of a 0day outbreak. But with the increasing variety of exploitation methods, it is difficult to ensure that there are no bypasses or false positives.

Some “weak features” or even “0 features” of Log4j2 vulnerability are used in similar scenarios, as well as encrypted traffic and memory horses, etc. These methods have been brilliant in large-scale attack and defense drills, and the principle of hard to detect is similar.

Therefore, is there a technology that can ignore all kinds of changes or concealment of vulnerability utilization methods in traffic characteristics and defend against such 0days more naturally, even without relying on rule updates?

RASP is back on the scene

RASP (Runtime Application self-protection) is not unfamiliar to the security industry, but is not widely adopted due to the traditional impression.

The advantage of this type of technology is that, in the pandemic analogy, traditional border defense products are like masks/gowns, while RASP is like vaccines that inject themselves into the app, run alongside the app, and detect high-risk behaviors performed by the app in real time through hook critical functions.

The RASP is the natural enemy of the 0day species

Unlike detection based on traffic characteristics, RASP focuses on application behavior rather than traffic itself.

When RASP finds an application that does something it shouldn’t normally do, there is a high probability that the current application has been exploited by an attacker to do something risky (command execution, file reading, file uploading, SSRF, etc.).

The first advantage is that any behavior that RASP defends is already an actual attack that can be successfully exploited.

And the types of behavior applied, compared to the ever-changing, almost infinite traffic characteristics, are often exhaustive. From the perspective of application behavior anomaly detection, the range can converge to a limited number of types, which is the fundamental reason why RASP can ignore traffic characteristics and defend against almost all 0days (including encrypted traffic and memory horses) without relying on rule updates.

The reasons why 0DAY and some weak feature exploits are difficult to defend have been mentioned above. But no matter how traffic characteristics change, the essence of vulnerability exploitation comes back to getting applications to do unsafe things — that is, application behavior or attempts.

In this case, RASP does not look at whether the traffic in the request contains a malicious payload, but rather what Log4j2 actually does using JNDI functionality. If you do normal JNDI lookup, there is no problem; However, attempting to use JNDI functionality for command execution is an obvious and dangerous behavior.

It is at this stage that RASP plays an extremely important role: pulling applications back from the brink before they make mistakes.

From this point of view, a second advantage of RASP is that false positives are extremely low.

For example, if the application does not use Log4j2 at all, reporting attacks based on malicious features of the payload means false positives, which deplets security personnel’s energy to some extent.

Because RASP runs inside the application, it can know whether the payload from the traffic layer successfully enters the dangerous function of Log4j2, so there is no “invalid alarm”.

In recent years, from WebLogic to Shiro, Dubbo, and today Log4j2, there has been a massive explosion of 0days caused by third-party components.

Because the code for such components is not maintained by the developers of the applications that use them, it is not easy for security personnel to put a lot of effort into identifying which applications are using the vulnerable components in the first place. Especially for businesses with lots of applications and fast iterations, it’s quite normal to not be able to tell which applications, which components are being used, and which versions.

This brings us to the third advantage of RASP: third-party component self-checking.

When a 0day appears, the path of the affected component can be checked immediately, as shown below:

(Log4j component path located through Ali Cloud RASP)

For components that have been exposed with CVE vulnerabilities in the history, RASP can automatically detect and associate the corresponding CVE vulnerability number and vulnerability level, facilitating security and timely repair by developers.

Cloud native RASP, accelerating the landing of architectural advantages

In 2014, Gartner identified RASP as a key trend in application security, but the reality is that RASP has been slow to take off on a large scale in production environments, and only a few leading Internet companies have achieved it so far. The biggest obstacle is that RASP technology is invasive to applications themselves, and developers are very worried about performance, stability, compatibility and other issues.

Alibaba Group started to deploy its own RASP products in 2015. Years of practice has completed large-scale deployment in the production network, and experienced the actual combat test of the production network’s large flow business, achieving the best performance in performance, stability and security (self-protection) control. It has to be said that this does need a lot of time to precipitation experience and lessons, continuous tuning, which is the biggest difficulty of RASP built by party A’s security team.

Ali Cloud security team will try to export RASP best practices, last year launched a more general, more suitable for user scenarios of RASP version, and deployed and applied in a number of financial, educational users of the production network. This year, we will get through the advantages of cloud architecture and realize the silky experience of one-click access to RASP for cloud native ARMS product applications (open path: Ali Cloud ARMS- Application security menu), greatly reducing the threshold of RASP defense capability for cloud users.

Ali Cloud security team observed very aggressive Log4j2 vulnerability exploitation and dangerous behavior among RASP users. Taking a financial user as an example, RASP detected and blocked 184 real attacks involving 8 Java applications, including 43 command executions and 141 DNS vulnerability probes, within 2 days of access. These are highly likely to actually execute successful attacks without the RASP’s defensive ring to block them.

The current version of the free public beta, emergency security comrades can access RASP and then calmly upgrade. If you need to protect your application, you can also contact us to deploy the offline VERSION of RASP.

PS: Due to the vulnerability management regulations, the details of the vulnerability in the picture in this article have been blurred through Mosaic, please understand

Click * here * to learn more about ARMS!

Students who are interested in ARMS can search the group number (34833427) or scan the qr code below to communicate and answer questions in the group