Saturday, 21 November 2009

Why I had to build O2?

I had to build O2 because the state-of-the-art tools (both commercial & open-source and both white & black box) where not designed for knowledgeable web application security consultants (like me).

There is a reason why the adoption rate of these tools is very LOW (by security professionals, developers, software architects, etc..), and even more importantly, there is a a reason why even when they are used, very few people actually get decent (& actionable) results from it. Of course that the sales & marketing departments paint a different story, but most of the current sales result in shelf-ware (and if you have doubts on this statement, I just have one word for you: Frameworks)

In addition to:

  1. lack of support for Frameworks like Struts, Spring, Enterprise Library, ASP.NET MCV, (heck, most don’t even ‘properly support’ J2EE’s or ASP.NET’s request execution flow),
  2. the customizations made to those Frameworks, and
  3. custom or ‘client / vendor specific’ Frameworks
... the reason why those tools don’t work in the real world, is because they (currently) don’t ‘understand’ how the target application works.

For example, when they DO provide a finding, that finding will only cover a very small part of the entire code flow that creates that vulnerability (for example the URL with the exploit or the internal Source-Sink trace).

This is why the market perceives these tools as NOT working, and why the security professionals (who should be its MOST active users and promoters) look down on them and ignore them.

Remember that my objective on my security engagements is to ‘Automate Security Knowledge and Workflows’.

This way less experience users will be are able to replicate my actions and fix, mitigate or accept (the risk of) the security issues on their applications.

Application security will never scale if we required everybody to be security experts!!


Back to O2...

Historically O2 was built on top of the Ounce’s Labs (now called AppScan Source Edition) product when I was hired (in my 2007) as an independent consultant, and was tasked of using their tool on ‘service-driven’ engagements and provide feedback to the product team.

After getting my head around on how the Ounce Engine, I was in love with its data-flow analysis and wide coverage (since I was used to doing it by hand), but was very disappointed by its lack of support for Frameworks and for ‘building custom analysis’ on top of those findings (which remember, only represent a small part of the ‘real’ traces & exploit flow).

So having a programming background, I did what every security consultant does today.

I wrote scripts ...

And more scripts & command line tools...

And more scripts & some GUIs ...

Who eventually become so complex and feature rich, that I decided that I needed to build a host for those scripts, tools and GUIs.

And that is when O2 was born :)

In fact, originally this tool was called F1 (as in the ‘F1 racing car’ vs ‘the normal cars that run on the road’), and was renamed O2 (for Ounce Open) when the Ounce Labs guys made the decision to allow me to Open Source it (which happened Nov 08 (last year) at the OWASP conference in NYC)

In the beginning, O2’s capabilities were almost 100% dependent on the Ounce’s engine (since originally O2 (i.e. F1) was designed to automate and increase it capabilities). So at this stage, one could not use O2 without a valid (i.e. paid for) Ounce Engine.

Eventually, as O2’s capabilities matured and (aided by the fact that I was doing other Security Engagements outside of Ounce where I was using & developing O2), the number of features that did NOT require Ounce’s commercial license started to grow. Eventually taking O2 to a level that enormous value can be obtained by ALL users and making O2 worthy of being an OWASP project (and being called ‘A Platform’).

Today (Nov 09), O2 has reached a maturity level where I (Dinis) can finally perform security engagements with a type of visibility and automation that I could only dream off a couple years ago.

There are a small number of people (me and the few brave O2 users) that get a LOT of value from O2, the challenge now is to make this scale, and dramatically simplify O2’s workflows so that it can be easily used by new users.

3 comments:

Daniel said...

Have an idea.

Why don't you and I collaborate on making O2 an easier tool to use. We both know the benefits, problem is many out there struggle to find out the best approach to using it.

thoughts??

diniscruz said...

Sure man, that would be great. I think your fresh pair of eyes will make a massive difference.

Basically what we need to do is to create the 'Daniel O2 View' which represents your workflow and how you like to work.

What you need is to do is to have a target application and have a number of problems which O2 can solve.

For example:
- "I want to analyze this web app and get XYZ out of it" or
- "I want to use the information gathered from static-analysis (white-box) to drive my dynamic analysis (black-box)" or
- "I want to submit these web requests and then cross map what I learned from the source code"

David Rook said...

Hi Dinis,

I agree with the comment Daniel made about making O2 easier to use. After I saw you presenting it at OWASP Ireland I attempted to try the tool out. The biggest issues I see currently with O2 is not knowing where to start with it and not knowing what each module really does/is supposed to do.

That frustrates me, I can see that O2 probably does some really cool stuff but getting it to do something isn't as easy as it probably should be.

I'm going to have another attempt at using it over the weekend and see if I can "get" it. If I can figure it out I'm more than happy to contribute docs/steps on usage etc to the project.

Dave