I recently gave a talk at OWASP Chicago called “Web app penetration testing with scripting languages”. Based on feedback since the talk (and dancing between the raindrops of a pretty hectic work schedule), I decided to try a series of blog posts cementing the ideas surrounding the development of PenTestConsole. To Mike, Mike, Al, Walter and the other 5 people I can’t remember right now, your tarball will be in the mail soon… I hope.

What is PenTestConsole?

In simplest terms, PenTestConsole is a set of Ruby libraries (and add-ons to existing libraries) that provide a scripting framework for web application testing. It allows you to work from an irb (Ruby shell) prompt or write scripts to automate tasks that would otherwise consume precious engagement time.

And Now… Some Context

Coming into this business from a QA background, I realize that testing is testing. In the QA world, positive testing is simply testing to show the product works (test to pass). Negative testing shows the product is broken (test to fail). One of my big lessons learned over the years is that you can’t positively test something unless you know what it’s supposed to do. Proving a negative is easy… it’s proving a positive that’s the hard part. These concepts hold equally true for application penetration testing and even though line between “positive” and “negative” blurs to a disturbing gray, the necessary piece of the puzzle is business context.

The problems that plague QA guys are a subset of the problems that hinder application pen testers. Not enough information, too little time and getting started in the wrong part of the development cycle just to name a few. The problems we face as security consultants are compounded by the breadth of expertise required to work any engagement that comes our way. As much as I would love to spend time pontificating about methodology, technology and software development practices (Niaaaagra Falls), I have work to do and that’s the reason for PenTestConsole.

By the time I get to an application it’s either deep into QA cycles or actually in production and I’m testing the production instance in an off-hours gig where I’m hamstrung by limits on what data I can enter into the system or how destructive I can be on a shift schedule that is grounds for divorce in 32 states (Slooooowly I turn). The key thing is that I am looking at an application that fills some business gap for my customer. Nirvana comes when I can use business justification to inform my assessment of security posture. I need to be able to find all the bread and butter issues (XSS check, session problems check, SQL|XML|XPath|Command|… injection check, CSRF check, error handling check…) and find the more complex and subtle (read fun) vulnerabilities that the customer needs to know about.

There are lots of tools out there to help me ranging from from proxies to fuzzers to scanners. Every one I have used has solved some particular problem during an engagement. My big challenge is that the more advanced or subtle functionality is not as accessible or obvious as the basic stuff. I need to spend cycles figuring out how the application under test works rather than ferreting out how my tool works. Even when I do figure it out, I keep running into situations where I need to code something specific because the app uses some new authentication mechanism or postbacks or includes HaveAFunTimeReadingMe.asp or you_need_to_be_on_meth_to_read_this.js (Step by step). Doing this over and over made me decide to write a framework that makes this job faster and less frustrating.

Coming next are the whys and hows of PenTestConsole’s development as well as some examples of how it works. Stay tuned.