There are times when network security defenders need to compile exploit code. It is not unusual for more than a dozen new exploits against Windows and Linux machines to be released each day, and unfortunately, you can’t always trust the exploit author or security write-ups.
First, many exploits don’t work as advertised. They either don’t work at all, only work some of the time, or only work in a much smaller subset of machines than originally advertised. The more exploit code that you test, the more you’ll see the truth of that statement.
Second, many networks contain defenses that offset the exploit’s attack vector. For example, the exploit may work against Windows XP SP2, but if your computers contain hardware-based anti-buffer overflow chips (NX, for instance), the exploit may not work or its effects may be lessened. Maybe your machines contain anti-virus scanners, IPSes, or host-based firewalls that prevent the attack from being successful. And when the patch comes out, does it really fix the exploit hole? You can't know for sure until you try it out.
Last, testing exploit code gives you a sexy demonstration that can be used to convince team members and management about the value of your computer security defenses.
Some exploits are published in their compiled form: Just run the executable and at most, you have to manually compile or run using a scripting language. In this case, the first order of business is to locate the exploit code. If you subscribe to multiple security mailing lists, chances are you’ll have an e-mail in your inbox with the links to the exploit code.
One of my favorite exploit code mailing lists was from FrSIRT, but they recently ended their public disclosure of exploits. It’s now pay for play only.
There are other security mailing lists that still routinely publish exploit code, including the Full Disclosure list and Dave Aitel’s Dailydave.
Packet Storm is another good site for malicious code, although searches often return too much information and require a little digging. Metasploit is always a resource for exploit and shell code, but it isn’t as thorough as some of the other sites.
If all that fails, go to your favorite search engine and enter the appropriate keywords. You’ll often find the exploit author’s original e-mail, and from there find links to the code. Most of time the author’s Web site will have more details on the exploit, updated exploit code, and lots of other interesting peripheral information you previously knew nothing about.
Most browser exploit code comes in the form of JavaScript, VBScript, Perl, or Python scripting languages. Copy the scripting language to an ASCII-based editor (Kwrite, Notepad, Vi, Wordpad, or the like), save with an HTM or HTML extension, and then point your browser to it.
Non-browser script-level exploits run outside the browser and require that the exploit code be run through the native scripting engine with one or more syntax parameters. For example, you might be told to run the exploit with syntax like this:
perl –w exploit.pl –n –vv –h 10.1.1.1 –i.
