Adding custom/new exploits to metasploit framework 3

[jerome.athias at free.fr (Jerome Athias)]

As HD explained; it's not possible to completely automate the task of
porting exploits codes to the MSF.
One of the big advantage of using the MSF for writing exploits is that
it offers standardization of them (\o/). (and a very quick way to write
them, with reusability, etc, blabla ;-) )
(Please mil change your banner with "MSF need you, it is good for you")

One difficult thing when trying to port an exploit to the MSF is often
to first find the target (binary of the vulnerable software, package...)
Here, repositories of old softwares versions are helpful
https://www.securinfos.info/old-softwares-vulnerable.php
sourceforge, google, friends...

Note: thank you if you're still reading :-)

Anyway, if you're not familiar with Ruby, the Metasploit API and even
exploit development...
The unofficial MSF-eXploit Builder platform could help you.
https://www.securinfos.info/metasploit/MSF_XB.php

Quickly, you can install and run it (Windows only... gurus don't need it ;p)
Then "Editor/New"
Go to "Badchars" and copy/paste the shellcode from
http://milw0rm.com/exploits/6100

shellcode  = "\xeb\...
...
shellcode += "\x4f\x69\x46\x4b\x4f\x6e\x30\x68";

Remove "shellcode  = ", "shellcode  += ", ", ;
(done in just one click in my version)

At this point it gives you easily the size of the used shellcode (2784/4: 696)
We don't know more, but we know at least this.

(Note: one function -not available in the current public version?- will check the shellcode and display missing 
characters (possible badchars))
(not speaking of the lazy "Bruteforce badchars" button ,-()

Dealing with the return address; MSF-XB comes with a local opcodes database
( https://www.securinfos.info/international-opcodes/index.php updated every year for HD's birthday ;-))
(Note that you can help me populate this database! ie with XP SP3 addresses... 
https://www.securinfos.info/OPCODES_LIST.zip )
with a "reverse research" feature, so you find 0x77d92acc (as a "universal" return address) jmp ESP in USER32.DLL Win 
XP SP2 French, German, Dutch, Spanish (and maybe others?)
(but also as 0x77D92ACC pop ESI - pop - retbis in USER32.DLL Win XP SP0 US !)

> From the original code, you can easily retrieve the "Design" of the exploit and report it in MSF-XB
buf = nop*foo_base + shellcode + nop*(buf_base - foo_base - len(shellcode) - buf_offset) + ret
buf += "\x90\x90\xb0\x53\x6b\xC0\x28\x03\xd8\xff\xd3" + nop*(buf_offset - foo_base - 3)

And then you'll generate the MSF exploit code (at least skeleton) with MSF-XB; it will give you additional return 
addresses for other platforms (ie Win2K SP4)
(assuming, of course that the offset is the same, blabla)


Hope it can help you to start writing MSF exploits modules...

/JA

H D Moore a ?crit :
> 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?
> >