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.