Relying On Tools Makes You Dumber

It takes a lot of time and effort to stay up on the latest vulnerabilities, attacks, and tools. Often, we in the security field rely on tools to automate parts of a vulnerability assessment or penetration test, but our testing should never rely only on the tools. If all we ran were some tools and blindly trusted their output,then we would be no better than your average script kiddie.A couple of recent presentations have followed a similar line of thinking. They've focused on people's reliance on the expertise of tools, the need to go beyond the crutch that tools provide to understand, and practical examples of using languages like Python to accomplish that goal. At Black Hat, Nathan Hamiel and Marcin Wielgoszewski presented "Constricting the Web: Offensive Python for Web Hackers" (video), and at Security B-Sides Las Vegas, frank^2 presented "F**k Tools, Do It Yourself Jerk."

The premise of the presentations was that tools are written to do one or two things well, but they may not apply to all situations or work with future versions of the targeted application. To deal with various tools' inherit limitations, the users of the tools need to learn what the tools are doing and be able to do it on their own.

For example, if you're using a tool to find cross-site scripting or SQL injection vulnerabilities in a website, then you need to know how to do that without the tool by using just your Web browser.

In the examples given during Nathan and Marcin's talk, they focused on the Python scripting language as the best solution for quickly interacting with Web applications and developing proof-of-concept tools. They chose Python because many popular security tools are written in Python, giving it a large support base, they say it's easier than Perl (YES!), and it does a great job parsing Web content like HTML and XML.

Personally, I've found myself doing more custom one-off type jobs with Ruby. The most recent were several SHODAN search scripts using the new API. I eventually turned them into a Metasploit module that is available here.

In closing, I think that having the ability to quickly provide a proof-of-concept script is important for two reasons: One, it gives you the ability to verify a tool's output is correct and the vulnerability it found does exist and is repeatable. Two, you can then provide the script to a client with full documentation so they can see it themselves.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.