[WEB SECURITY] Re: Integrated Dynamic and Static Scanning

[arshan.dabirsiaghi at aspectsecurity.com (Arshan Dabirsiaghi)]

Without instrumentation this will be major, costly, epic fail. Assuming life without it for the time being, I think the 
future is brighter for dynamic-to-static integration. Let's consider a few of the logistical issues going the opposite 
way - from static findings to exploit generation after a simple source-to-sink, tool-identified path for a SQL 
injection vulnerability found deep in the business logic of an application:
 
1. The application has no idea what it's method/scheme/hostname/port for invoking it should be. It seems like a simple 
thing to deduce, but I guarantee it's a huge PITA for anyone actually doing the work to make it 100% reliable. After 
all, if it's not 100% reliable, how can we claim that this technology helps us any more than the static trace alone? 
The value-add here is in ease of verification. A mistake made in figuring out any of these values will mean that the 
exploit will not be verified and will turn out to be a false negative. All the infrastructure touched before the app 
makes this a complex problem - and if this little tiny bit of obvious information is complex to generate, what hope is 
there of getting the rest of the complex set of circumstances right that are required to re-create a vulnerability in 
action? Realistically the VA and the SA (VA+SA, it's everywhere you want to be) need to maintain synchronization per 
request to make this a semi-sane idea.
 
You could hardcode these values, but what if you use a mix of values and therefore aren't static across the 
application? Knowing the tools, I know the finding will still be reported somewhere deep in a "don't bother checking 
these" category. =)
 
2. The SQL injection vulnerability would have to understand the query and how to manipulate it in order to generate a 
meaningful query and resulting exploit. If proof that you can cause a syntax error is enough to verify exploitability 
then I guess this isn't such a big deal. But what if the syntax error never reaches the screen? Have you verified 
anything in this case?
 
3. The application would have no idea what server-side forwards, virtualized paths and filters were traversed to reach 
the application's action entry point. This reverse-engineering is especially hairy in J2EE, yet would be needed to be 
reliably generated in order to form an exploit. Put Spring on top of it and we're talking complexity that's practically 
impossible to re-model.
 
This is just the tip of the iceburg, I think. The only technically feasible application of this kind of integration can 
be found in instrumentation ideas like Fortify's "attack path tracing", which would ideally be tied into unit testing 
and regression testing when it makes sense. Are there any competitors to them in this market? Does anybody have 
real-life experiences with this tool set?
 
The idea of VA+Fortify+ptrace is intriguing, but we're looking at an explosion of complexity that I doubt many 
customers have the expertise to manage. +1 to Fortify for innovation, but can we get some technical information or user 
experiences here?
 
Arshan
 
P.S. Has anybody talked about cost/value analysis? It'd be cool tech, for sure, but is it worth it? I'm not trying to 
dissuade anybody from pursuing these ideas, but I just want to make sure all the cards are on the table.
 

________________________________

From: Jeremiah Grossman [mailto:jeremiah at whitehatsec.com]
Sent: Thu 8/6/2009 8:22 PM
To: James Landis
Cc: sc-l at securecoding.org; websecurity at webappsec.org
Subject: Re: [WEB SECURITY] Re: [SC-L] Integrated Dynamic and Static Scanning



Good catch, that is exactly right. My oversight. A while back Fortify 
released a white paper entitled "Misplaced Confidence in Application 
Penetration Testing" [reg required]

http://www.fortify.com/security-resources/library/overviews.jsp

Tools also available to help measure.


On Aug 6, 2009, at 5:04 PM, James Landis wrote:

> There's a big claim in area 2) that actually does exist: 
> instrumentation of static code to give you code coverage metrics for 
> your dynamic scanning efforts. Well, maybe it's not area 2), but 
> it's definitely a static analyzer vendor feeding dynamic analysis.
>
> -j
>
> On Thu, Aug 6, 2009 at 4:30 PM, Jeremiah Grossman <jeremiah at whitehatsec.com
> > wrote:
> Hey all,
>
> I've been monitoring this thread [1] and some excellent points have 
> been raised (cross-posting to websecurity as the subject matter 
> applies). I'm personally very interested in the potential benefits 
> of an integration between dynamic and static analysis scanning 
> technology. The spork of software security testing. The desire of 
> many is a single solution that unifies the benefits of both 
> methodologies and simultaneously reduces their respective well-
> described limitations. For at least the last couple of years there 
> have been vendors claiming success in this area, of which I remain 
> skeptical.
>
> A brief explanation of the bi-directional and somewhat simple 
> sounding innovations that vendors are trying to develop:
>
> 1) Dynamic Scanner -> Static Analyzer
> A dynamic analysis engine capable of providing HTTP vulnerability 
> details (URL, cookie, form etc.) to a static analysis tool. Static 
> analysis results narrowed down to a single line of insecure code or 
> subroutine to speed vulnerability remediation. Prioritize issues 
> that are located in a publicly available code flow vs. those that 
> are not technically remotely-exploitable. Isolate security issues 
> where source code was not available, such as third-party libraries.
>
> Static Analyzer -> Dynamic Scanner
> 2) A static analyzer capable of providing a remotely available 
> attack surface (URLs, Forms, etc.) to a dynamic analysis tool. 
> Dynamic analysis may realize additional testing comprehensiveness, 
> measurement of coverage depth, and hints for creating exploit proof-
> of-concepts. Not to mention able to provide more detailed 
> application fix recommendations.
>
> <vendor bias>
> As it stands currently, the state-of-the-art is basically a 
> reporting mash-up. Very little of the aforementioned advancements 
> have been proven to funtion outside of the lab environment. If 
> anyone has evidence to the contrary they can point to, please speak 
> up. For those curious as to Tom Brennan's comment, these are the 
> areas Fortify and WhiteHat are together working on.
> </vendor bias>
>
> This is an excellent time to be in the application and software 
> security industry. Over the next few years there is going to be a 
> lot of innovation and awareness in the "defense" side of the 
> industry. Talent, skill, and experience is going to command a premium.
>
>
> [1] http://www.mail-archive.com/sc-l at securecoding.org/msg02731.html
>
>
> Regards,
>
> Jeremiah Grossman
> Chief Technology Officer
> WhiteHat Security, Inc.
> http://www.whitehatsec.com/
> blog: http://jeremiahgrossman.blogspot.com/
> twitter: @jeremiahg
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:http://www.webappsec.org/rss/websecurity.rss [RSS 
> Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA


----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20090806/1f1abb7c/attachment-0001.html