When Penetration Tests Backfire

3:40 PM -- A couple of weeks ago, I blogged about testing for security problems in tools used for incident response, network scanning, and similar functions. (See Debugging Your Bug Software.) RSnake blogged yesterday about the "Danger of Pre-Canned RFI Exploits," and how they often include additional code that lets the author access the system you exploit, or the system you're doing the exploiting from. (RFI, or remote file includes, is a vulnerability in Web applications that allows an attacker to view arbitrary files or include files from remote hosts.)

Just like the freely available security tools, how do you know if the PoC (proof of concept) exploit code you downloaded from Milw0rm or Packet Storm includes a backdoor?

Follow the same practices I outlined in the previous post. Most PoCs are the actual source code and not binaries, so auditing the code should be easy -- provided you have the programming skills to look through it. Then, run the code in a closed environment and monitor all system and network activity for unexpected behavior.

This brings me to something that I've wanted to mention for some time. A representative from a Big 5 consulting firm was recently giving a recruiting talk to some of our students interested in security. He told them that when his firm conducts penetration tests, they don't use buffer overflows or similar exploits in a production environment. I immediately asked why: If you are engaged in a pen test, where the ultimate goal is to gain access, why limit yourself? He said that most of the firm's customers would lose significant amounts of money if their production services went offline. Exploiting a buffer overflow for the purposes of a pen test wasn't worth the risk.

So keep this in mind when putting together your checklist for pen testing in-house or contracting it out: Is the target a test or production system? What type of exploits can be used? What happens if a production service is taken offline due to an exploit? Do the members of your security team have the skills to use the tools and evaluate them properly, or will they simply be firing off exploits blindly to see what works (at which point, you essentially have overpaid script kiddies)?

Actively using PoC exploits and pen testing against services in a production environment can be risky for two very real reasons: Unintended targets could get back-doored, and you could crash mission-critical servers. So take care and test in a closed environment before ever unleashing a POC in production.

– John H. Sawyer is a security geek on the IT Security Team at the University of Florida. He enjoys taking long war walks on the beach and riding pwnies. When he'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