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.
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.
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.
Open up the script code file and review the runtime instructions located in the top comments. Reviewing the code also allows you to ensure that no secret Trojans or malware are lurking inside. I've seen exploit code which did nothing but steal the current user’s password file and send it to a remote IP address. If you can’t analyze the code adequately beforehand, run it in a virtual environment or don’t run it at all.
Other types of exploits must be compiled into an executable before testing. Some malware samples can be compiled by almost any related language compiler, but others must be created by a particular compiler (and will say so in the starting comments). For instance, C+ programs often can be compiled into executable form using any C+ compiler. In the Linux world, I often use GNU’s C compiler, gcc, by typing something like this:
gcc –o outputfilename inputfilename.c
The –o indicates the following text will be the output file name of the executable.
Sometimes a compiler will need additional support files and libraries. The exploit code author or their code comments will usually indicate this; if not, troubleshoot your compiler’s errors and try again.
If you’re not one to compile code, download precompiled exploit code. Without reviewing the source code yourself and compiling it by hand, however, you’ll never know if it contains other malicious commands or bugs. Exploit code authors often disable their exploit code slightly to discourage script kiddies from running it so easily. By requiring some investigative work on behalf of the eventual user, they figure the increased level of expertise needed will dissuade overexuberant hacker wannabes.