Friday, 11 June 2010
The First Step towards Hybrid Analysis
In the past couple of months we've had several blog posts on hybrid analysis, including Jacob West’s preview of his RSA talk with Jeremiah Grossman on Correlating Static and Dynamic Security Results and Fredrick Lee's pointer to HP's writeup on the benefits of hybrid analysis. While the first one introduced the idea of correlating static and dynamic analysis results and the second emphasized that such correlation leads to a more complete analysis of the application, better prioritized results, as well as reduction of time and cost of fixing vulnerabilities, this current post is a follow-up that goes into a bit more detail with regards to implementing the first step necessary to do such correlation.
The fact of the matter is these two types of analyses work on two different types of input: while static analysis looks at source code, dynamic analysis looks at web traffic. Thus, in order to do correlation between the two there has to exist or be generated a common link that connects two types of findings. While implementing a correlation mechanism by looking at web traffic seems hard, doing it on the static analysis side is a lot more promising. Static analyzer can infer URLs for the findings by analyzing various configuration files. The generated URLs can be included as auxiliary data in as many static findings as possible. This can later serve two purposes, namely assist in matching dynamic and static findings and also provide inputs to dynamic analyzers. The first will lead to better prioritized results and reduction of time and cost to fix vulnerabilities, while the second -- to a more complete analysis of the application.
As of Q2 2010 rulepack update release, Fortify SCA generates URLs for four different Java frameworks: standard J2EE servlets, JSF, and Struts 1 and 2. Generating these URLs turned out to be trickier than it seemed at first due to heavy usage of wild cards and reliance on default context root, which makes it difficult to identify statically scanned application's web root. In general, in order to generate the URLs, SCA (with assistance from rules) looks at the following configuration files (as well as all others that have different names, but the same structure): web.xml, faces-config.xml, struts-config.xml, and struts.xml. We analyze URL patterns as well as direct and indirect URL mappings when possible. We also look at forms and navigation rules to collect information about the page flow of the application. Then we match these up with regular SCA findings based on the source code location of sources and sinks of the findings.
To give a better idea of what I am talking about, here is a concrete example. Fortify SCA finds the following privacy violation vulnerability in PerformRegistration.java class, which is part of an application written with Struts 2 Java framework:
...
Profile profile = new Profile(username, password, firstName, lastName, email, ssn);
System.out.println("added profile for " + profile.getUsername() + " (" + profile.getSsno() + ")");
...
In the code above, an SSN (private information) gets printed to the screen and therefore exposed to the outside world. From struts.xml configuration file we learn that PerformRegistration class is a struts action in a /login namespace:
...
<package name="login" namespace="/login" extends="struts-default,tiles-default">
<action name="PerformRegistration" class="com.fortify.samples.riches.PerformRegistration">
...
</action>
</package>
...
From web.xml configuration file we learn that struts actions have a .action extension:
...
<filter>
<filter-name>struts2</filter-name>
<filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
</filter>
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>*.action</url-pattern>
</filter-mapping>
...
Using these two pieces of information we construct the URL for the PerformRegistration action by concatenating the action’s namespace, name, and extension. Now we know that /login/PerformRegistration.action URL triggers the privacy violation vulnerability described above, and include the URL in the dataflow path for the finding.
While this is just the first step (a.k.a. Hybrid 1.0), we plan on expanding URL generation for static findings to other frameworks and building a much more sophisticated technology on top of it later this year. Once static and dynamic findings are matched up, they can be automatically re-prioritized by taking both analyses into account. Plus, the evidence generated by both types of analyses can be aggregated in one place for each correlated issue, thus demonstrating an exploit of a statically identified finding on the one hand, and a source location for fixing a dynamically identified finding on the other. And this is exactly what Hybrid 2.0 will offer.
