On Tools

Not too long ago, I was asked to do a technical interview for a set of tests.  This isn't unheard of, but it is odd. Usually, folks have heard about me from someone and that is good enough.  In this case, however, there was a special reason.  They were trying to avoid testers that were overly reliant on tools.

That's something I can get behind.  Too often I have come in on a forensic test just to find out that the last tester just ran a report out of ZAP or Burp, and turned it over - no triage, no nothing. That is, admittedly, more or less useless. I was confident that I could explain the realities of the situation.

ZAP and Burp are "proxies" in the application sense.  They sit between the web browser and the web server and capture traffic for analysis.  The developer tools (F12 button in the web browser) do the same thing, but ZAP and Burp are designed with vulnerability analysis in mind, and as such, they have a lot of tools to help a tester out.  For instance, right now I am using a tool inside Burp to check commonly used usernames and passwords on the login screen.  There are 1,340,656 combinations.  Could I type those all in? Of course!  Can I have a week for just that test? No? OK, we'll I'll script it then.  That's a tool.

There are a lot of tools that are available for Burp and ZAP.  The one in the example above is built-in, and it is called Intruder.  Everything Intruder does the tester can do manually.  However, Intruder will save you a lot of time.  What's most important is that the tester understands what they are doing with Intruder. It's not enough to just push buttons - everything that the tester does with a ZAP or Burp toolset should be something that could be done manually and understood as to what exactly is being done.

I have an upcoming post with part of an answer to knowing exactly what is being done - a good test plan. Sneak Peek: I heartily recommend the Application Security Verification Standard from OWASP. But I have said too much already - that's for another time.

What is my toolset then, assuming I know what all of them are doing? It looks like this:

  • Most of my corporate customers expect Burp Suite history as evidence for the test, so I use Burp a lot. I'm a big fan of the addin model, and have even written a couple.  Right now, I have several addins installed from the BApp Store - which is under the Extensions tab in the main tool.
  • If I have a choice in the matter, I will often use ZAP. It has a very slick API that allows for even more automation - yes, tools for tools.  The results from the proxy are the same, of course.  It's just the output from the web server and the input from the web browser.
  • Powershell.  Yep, you heard me right. I run a Windows shop, and Powershell has a robust set of tools for testing services, handling certificates, and whatnot.  If you don't know it, highly recommended that you dig in a little.
  • Python. Like Powershell, it has a robust collection of tools for services and manipulation of requests.
  • Nikto.  This is a Perl application that tests for a boatload of known flaws in web servers and supply chain components.  Again, could I test each one manually? Of course.  Do I want to? Not that I don't want to, I just don't have time.  People like me but they won't pay me for a year for one test.

That's about it.  In my next post, "Vulnerability Analysis is just fancy QA" I'll talk a lot more about knowing what you are actually testing for, so this post and that one kinda go together.  Either way, I hope you got something from this info.

Postscript: I didn't get the job I mentioned at the top of the post. I use too many tools.

Add comment

Husband. Father. Pentester. Secure software composer. Brewer. Lockpicker. Ninja. Insurrectionist. Lumberjack. All words that have been used to describe me recently. I help people write more secure software.

 

 

profile for Bill Sempf on Stack Exchange, a network of free, community-driven Q&A sites

MonthList