Adding custom/new exploits to metasploit framework 3

[hdm at metasploit.com (H D Moore)]

Grab an exploit and go basically :-) Practically, its not that simple, 
since you need to know enough Ruby to port it, the Metasploit API, and be 
familiar with exploit development to boot. The trouble with porting most 
public code is that it requires more investigation to make a module work 
with Metasploit. 

For example, if the exploit has a static block of shellcode, that doesn't 
give us enough information to do a port without basically rewriting it. 
We still need to know the maximum amount of code we can fit and which 
characters need ot be excluded from the payloads. The flexibility that 
Metasploit offers comes at the cost of a ton of upfront research into the 
vulnerability and its limits for exploitation.

If you look at the mod_jk exploit (http://milw0rm.com/exploits/6100), you 
will see three important things that require further work. First, the 
shellcode is a big blob of data, we still dont know if this amount is the 
most we can add, or just a value somewhere in the middle, or if changing 
the length affects the offset for exploitation. 

The second thing is the return address, the exploit 
hardcodes "\xcc\x2a\xd9\x77", which translates to the address 0x77d92acc. 
This, by itself, doesnt mean anything less we can figure out what 
instruction this corresponds to on the target platform. From the shell 
prompt, we can see he is exploiting Windows XP (build 2600), but this 
doesn't tell us what language it is. To figure it out, we need to find 
the corresponding DLL which loads at this address, dump the opcode at 
this instruction, then find other addresses for other platforms that 
correspond to the same opcode.

The last thing is restricted characters. Because the shellcode, return 
address, and nops are all hardcoded, we know that the characters that 
make them are allowed (a whitelist), but we don't know which characters 
we have to avoid. In most cases, sending a null byte usually breaks the 
exploit, but in the case of HTTP services, theres usually a much wider 
set of characters we have to avoid as well.

Once we have the previous three issues sorted out, then its time to 
actually code the exploit as a metasploit module. This is usually the 
easy part, but random suprises still pop up now and again (the Metasploit 
api may do something a little differently that conflicts with the 
exploit, etc).

Hope that sheds some light on why there aren't 5,000 Metasploit 
modules :-)

-HD

On Monday 21 July 2008, Clayton Dillard wrote:
> Understood, and thanks for the clarification.? Considering that there
> are thousands of exploits in the wild and only a couple hundred ship
> with MSF, how can we assist with speeding up the creation of
> standardized exploit code?