Cross the grass with the hedgehog. Find all-all 0-day. Capture the Universe! 11

Summary

1. Incompatibility DAST / SAST.
2. IAST: Buzzword and reality.
3. The third way.

As we noted earlier , the SAST and DAST vulnerability scan systems have both advantages and disadvantages, so the problem of finding the optimal approach to automating application security analysis does not lose its relevance. Over the past few years, at least three approaches have been developed to solve this problem.

Method # 1

The first, lying on the surface method is the correlation and mutual use of the results of the work of DAST and SAST. In theory, such an approach makes it possible to expand the coverage of dynamic analysis at the expense of static results and reduce the number of false positives. This is the way IBM went.


This is how the method works.

However, it soon became clear that the merits of such an approach are exaggerated. Transfer of additional entry points from SAST to DAST without understanding the context (or additional conditions, if we follow our terminology) often leads only to an increase in the duration of work. Imagine that SAST detected and sent 10,000 combinations of URLs and parameters to DAST, but 9990 of them require authorization. If SAST does not “explain” DAST, that authorization is needed and how to pass this authorization, then the scanner will knock on these URLs stupidly and its operation time will increase 1000 times. Without much change in the result.
')
But this is not the most important thing. The main problem is the incompatibility of DAST and SAST for input / output. Indeed, in most cases, at the output of the static analyzer, you get the following information: in line 36 there is insufficient input filtering, which means that XSS can be implemented. For DAST, the HTTP request a la / path / api? Parameter = [XSS] & topic = important will be native, indicating the type of vulnerability, and it is desirable that there are many values ​​for the fuzzer taking into account filtering functions.



Somewhere here is XSS ... We must pass it on to DAST! But how?

Notice also the important parameter of the topic = important. This is just the condition that must be met in order for the fuzzer to get into the necessary, vulnerable API. It’s not a fact that the vulnerability is also present in the parameter when referring to the path / path / api? Parameter = [XSS] & topic = other. Where does the static analyzer take this information? It is not clear…

Difficulties add various modules a la mod_rewrite , as well as frameworks, web server settings and other elements that confuse.

Method # 2

The second approach was associated with the emergence of such a phenomenon in the world as IAST (Interactive or even Intrinsic Application Security Testing). In essence, this is an extension of dynamic analysis, consisting in tracing the execution of the server part of the application (during fuzzing using DAST). To do this, use either web server, framework, or executable code instrumentation, or built-in tracing mechanisms.



Stored XSS and its SpyFilter tracing

So, for searching SQL Injection it is very convenient to use the results of SQL Server Profiler or similar utilities, where you can see firsthand what really “flew” to the server through filtering functions.



Looks like I did a little IAST again ...

After Dynamic Taint Analysis IAST once again came to the AppSec industry, he had many adherents who extolled the advantages of the method. The advantages include the ability to increase the efficiency of dynamic analysis by tracking the propagation of fuzzer requests through different levels of the application, which allows minimizing the number of false positives and trapping, for example, Double Blind SQL Injection. In addition, instrumentation at various levels of the application makes it possible to identify delayed attacks, such as Stored XSS or Second Order SQL Injection, which are traditionally given up by SAST and DAST.

It is important that the method solves the problem of correspondence between application entry points and source code terms (URL-to-source mappings). All this is not easy: it is done in three stages, and the server must be instructed - but somehow it is carried out.


Hybrid analysis HP Look (RAST = IAST)

However, IAST has drawbacks. First of all, the need for instrumentation code and (or) agent installation for dynamic instrumentation of a web server (DBMS, frameworks). Obviously, this situation is undesirable for industrial systems, and that questions may arise when it comes to compatibility and performance.

In addition, IAST in its current state is an extension of DAST (which, by the way, is clearly indicated by Gartner ) and inherits not only positive but also negative aspects of this method. There are, of course, rumors of pure IAST , but this is more likely to intrusion detection systems and firewalls, which can also reveal vulnerabilities under successful circumstances (which we will also tell you about soon).

Returning to the topic notes. The use of IAST as an intermediate allows partly to solve the problem of compatibility of SAST and DAST - but only partly. Although in some cases (especially with suitable SAST), everything can turn out quite well.



Coverity + NTOSpider - better together!

A critique of hybrid analysis is given in a report by Chris Eng ( A Dose of Reality on Hybrid Analysis, Chris Eng) . Note that much of his report is relevant for both the simple correlation of SAST and DAST results, and for hybrid analysis using IAST.

Method # 3

The apparent bulkiness of the approach requires a better solution. And the appearance of such a decision is coming, although it is still unclear where it comes from. An appropriate word has not yet been invented for him, but in scientific publications its aspects are encountered more and more often. Its essence lies in the combination of static and dynamic analysis without the need for an intermediate link. That is, the basis remains the same, but at the same time, static analysis as a potentially more complete one is used as the main one. To solve this problem, SAST must be able to prepare data for verification in a manner understandable to DAST. For example, in the format of an HTTP request with the indication of the necessary additional conditions and a set of parameter values ​​for fuzzing. It is possible so:



Exploit, backdoor and two trunks additional condition

Or so:



Here Double Blind SQL Injection, we need Time-Based ...

How to achieve this is a topic for a separate note, but nothing is impossible here. By the way, this approach allows you to implement another task - the integration of SAST with the Web Application Firewall, which is very, very useful for quickly closing detected vulnerabilities.

PS To avoid a false impression, it should be noted that we are not at all against IAST, but even for. Some sharpness is a reaction to statements like: “I> S + D!” This technology has a clear niche. In addition, the method allows to implement the concept of continuous monitoring, which is more fashionable. But in order to obtain results similar to IAST, it is not necessary to fang the entire application, and sometimes there is no need to execute it in the literal sense of the word. But about this, as has already been said, - later.

Positive Technologies Application Inspector team