Due to their numerous components and dependencies, web applications often have multiple vulnerabilities—many of them unknown and susceptible to zero-day attacks—that can be exploited by malicious HTTP requests. Determining whether a vulnerability exists is challenging without visibility into an application’s real-time data and event flows, which isn’t possible with existing firewall-based solutions. Software composition analysis (SCA) can identify potential vulnerabilities but doesn’t prevent attacks from exploiting them. To safeguard their systems from these attacks, organizations must not only surface potential vulnerabilities but also block the malicious requests that target them before the code executes.

We’re pleased to announce Datadog Exploit Prevention (also known as runtime application self-protection (RASP)), a new security feature in Datadog App and API Protection (AAP). Exploit Prevention uses the Datadog tracer to control application execution in order to protect your system from runtime threats before code execution. Our In-App web application firewall (WAF) embeds directly within your application, providing deep visibility into its behavior and blocking attacks targeting vulnerabilities before they can be exploited.

In this post, we will explore how you can use Exploit Prevention to detect and block threats before they can damage your application while also identifying unknown vulnerabilities that need to be addressed.

Exploit Prevention: A new safety net

Instead of performing complex code analysis to detect vulnerabilities or merely analyzing request payloads to identify and block attacks, Exploit Prevention uses RASP heuristics) to analyze the input/output entry points in your code to check for potential vulnerability points. It then uses the data from requests as context to determine if the vulnerability is indeed being exploited.

Some possible entry points include:

• Local file inclusion (LFI), in which an attacker tricks a web application to open or execute files on a web server

• Server-side request forgery (SSRF), in which an attacker initiates and manipulates HTTP requests to gain access to a server

• SQL injection, in which an attacker inserts malicious statements into SQL commands in order to access databases

• Command injection, in which an attacker executes malicious shell subtasks

The main innovation of Exploit Prevention is its ability to block the control flow of a request handler at any point if an injection on a vulnerability is detected. Depending on the mode that you select for a vulnerability—Do Nothing, Monitor, or Block—Datadog Exploit Prevention will not only detect and confirm the vulnerability exploit but can also stop it from being exploited at runtime.

Detect and protect against attacks with a fully integrated security architecture

The ability to both detect vulnerabilities and block attacks at runtime is possible because of the way our security architecture is integrated with our monitoring tools. The Datadog tracer is directly embedded in your application code and provides a large number of monitoring features. The Datadog Agent reports data from all tracers on a host or a group of hosts to Datadog’s backend, which correlates and analyzes the data and triggers a security event when a vulnerability is detected.

Beyond monitoring and reporting, our In-App WAF within the tracer detects and blocks attacks before they can compromise your application. Because Exploit Prevention is part of Datadog AAP, you can also analyze clusters of attacks, correlate them with specific endpoints in your application, and provide business logic security rules and recommendations.

For each of your services, you can enable or disable Exploit Prevention for a specific type of vulnerability by activating monitoring or blocking mode through Datadog’s Remote Configuration. The new settings are immediately sent through the Agent to all the related tracers.

Prevent attacks by detecting vulnerabilities in your code before execution

Datadog’s In-App WAF has access to the incoming request payloads (including headers, query parameters, path parameters, cookies, and body), as well as internal application elements, such as SQL requests or opened files. During normal code execution, the WAF analyzes the input/output parameters to detect and potentially block a malicious threat.

In most RASP rules, the first step of Exploit Prevention consists of determining whether any of the request inputs are present in the instrumentation data or resource. For example, a SQL injection (SQLi) security rule might try to determine if any of the query parameters are contained in the final SQL statement. Exploit Prevention then evaluates whether the inclusion of the potentially unsanitized input in the resource constitutes an exploit.

This process is specific to each exploit and determined by a set of complex heuristics. In the SQL injection example, the mere inclusion of an input parameter does not constitute an exploit, but if the parameter is unsanitized, it does constitute a vulnerability. Therefore, in order to avoid false positives, the heuristic must verify the extent of the impact and the semantics of the tokens introduced in the final statement.

If an exploit is detected, Exploit Prevention will report it with many useful details, including the exploit type, source code location, and complete trace leading to that vulnerability, enabling you to quickly take action to patch it. When blocking mode is enabled, the vulnerable code is aborted to prevent the exploit from succeeding, and the request is gracefully canceled with an automated blocking response.

Exploit Prevention is very efficient as it does not perform any taint checking and is based on specific, fast RASP heuristics that don’t require code analysis.

Example of Exploit Prevention detecting a database injection attempt

Let’s walk through a typical use case to illustrate how Exploit Prevention works when a database injection attempt is detected.

1. When your application receives an HTTP request, Datadog’s embedded In-App WAF will analyze the content of the request parameters.

GET http://icecream-rocket.icr/myprofile?login=iclover

1. Later, during code execution on the server, the tracer will monitor the database access and its specific request.

"SELECT * FROM users WHERE id='iclover'"

Even if it appears that the request parameter, iclover, was used in the database query, the RASP heuristic will not consider that access to be suspicious and nothing will be done, as the parameter seems to have been used in a legitimate way.

1. Later, a new HTTP request is received on the same endpoint.

GET http://icecream-rocket.icr/myprofile?login=%27%20OR%201%20%3D%201%3B%20--

This results in the following database query:

"SELECT * FROM users WHERE id='' OR 1 = 1; --'"

In this case, the RASP heuristic will decide to mark that access as a successful exploit because the semantics of the SQL request changed with the direct inclusion of the HTTP query parameter ' OR 1 = 1; --'. A security event will be produced to indicate that a vulnerability and an attack have been found and, if blocking mode is enabled for this vulnerability, the control flow of the code will be interrupted before database access is made to ensure the safety of your system.

Protect your system from runtime exploits with Datadog

With our embedded In-App WAF, Exploit Prevention safeguards your application from vulnerabilities by detecting and blocking attacks before code execution. Without requiring any manual tuning, Exploit Prevention analyzes input/output entry points in your code and uses request data as context to provide an immediate response to threats while avoiding false positives.

Datadog Exploit Prevention is available in our .NET, Go, Java, NodeJS, and Python tracers for all of our customers using AAP. It will also be available soon in our PHP and Ruby tracers. For more information about how to deploy and enable Exploit Prevention, see our documentation. If you’re not already a Datadog customer, you can get started today with a 14-day free trial.