Professional hackers or security testers tend to write a lot of code. We write exploit code, fuzzers, code to handle esoteric protocols and data structures, unpackers, disassemblers, reversers, parsers, and so much more.

We write this code because often what we’re doing is so specific that is requires one off tools. Over time we develop an enormous arsenal of our own tools, scripts, functions and code snippets that make us significantly more efficient, but are hacks that are only beneficial to us. We then turn around and present them at conferences, we show off their magic in the hands of the original developer and the crowd goes wild, but the ecosystem stops there, because they are unsupported, undocumented and nearly unreadable by anybody but the original author.

I’d like to fix that.

At Security Innovation the tools we write, are less like tools, I suppose and more like libraries that are meant to make one thing that we do often easier, faster, better, more concise or at least reusable. My colleague, Marcus Hodges, released an incredibly powerful asynchronous programming library for python last, called Black Mamba last year that we’ve used on many projects to level the playing field between client and server (Servers have had asynchronous, multi-threaded, multi-core, multi-process client handling forever, clients are at a serious disadvantage here). Another coworker is working on another library that will make parsing the har format much easier. This opens up a ton of new doors for rapidly testing a complex web server. Another colleague has developed the incredibly powerful, yet sometimes overwhelming O2 platform to make testing easier.

The point of all of this is that as a security tester passes that 10,000 hour mark, then tend to look to tools that haven’t been created yet, so we turn to our development environments. After writing the same function 10 times (or even twice) to send an HTTP request it’ll go into some library, probably called Joe, so later on I can say import webstuff from Joe and have it setup and tear down the request for me easily, every time.

I think there is a bell curve of tooling out there actually, where the X axis is the target user and the Y axis is the number of tools. There are a few really simple tools for truly new users, but they’re tough to write because they have to be so verbose and robust, and there are a few great professional tools like IDA pro and some binary unpackers, but they’re either expensive, unsupported, and/or almost impossible to use. In the middle there are hundreds of tools that target the newish professional security tester, that sort of knows what they’re doing. Take for example localhost proxies: Burp Proxy, Web Scarab, Paros, Fiddler, ratproxy, suru and more come to mind. These all have pros and cons, but we all usually settle on Burp, with it’s nice set of tools built in for every day use and is flexible to be useful to new testers and pros alike.

But let’s say you want to do something a bit out of the ordinary with Burp: you have a server that is URL encoding a subset of the response, then HTML encoding certain malicious characters, then base64 encoding the whole thing. Now let’s say you want to fuzz the request 100,000 times with different values before all of that happens. Extending any tool to do that is going to be very difficult.

That’s where a library comes in. We end up writing a lot of code to do things like this, or other complex sequences of events (multi-part logins?).

My call to action is this: Write tools that you want to use. Write them the way you want to use them. Write them cleanly and with future extensibility in mind. Document and comment them well. Then open source the libraries, put them on github (or where ever you want). Publicize them through blogs, hacker news, our company website and popular other social sites like reddit.com/r/netsec and maintain your tool.

Once we start sharing and developing the tools that make our jobs easier we can stop focusing on the tools and start finding more and deeper vulnerabilities. Free from the burdens of developing and maintaining our own tool chains we can push the industry forward.

Posted By: Joe Basirico