Last updated at Thu, 08 Feb 2024 21:06:17 GMT

After more than 30 days of hardcore and intense exploit hunting, the Metasploit Bounty program has finally come to an end. First off, we'd like to say that even though the Metasploit Framework has made exploit development much easier, the process is not always an easy task. We're absolutely amazed how hard our participants tried to make magic happen.

Often, the challenge begins with finding the vulnerable software. If you're lucky, you can find what you need from 3rd-party websites that mirror different versions of the application, or you can download the trial version from the vendor (that is, if the trial version is still vulnerable).  If you can't find it this way, well, good luck getting your hands on it. This process alone can sometimes take more time than writing the exploit.  Unfortunately, quite a few of our participants gave up at this phase.

The next thing you do is gather as much information as possible about the vulnerability (CVE, OSVDB, ZDI, mailing lists, blogs, vendor's bug tracking system, etc). Reverse engineer the protocol or file format you're working with, find the root-cause by using whatever techniques (patch diffing, source code auditing, fuzzing, injection, etc), and then try to trigger a crash... hopefully a good one.  In two occasions, thanks to Joshua J. Drake, Jon Butler, and Carlos' reversing-fu, we found out that CVE-2011-0657 (MS11-030) and CVE-2011-1206 (IBM Tivoli LDAP) are most likely non-exploitable. Even if a vulnerability is not exploitable, the effort spent trying to exploit it is not wasted. Often times the experience of attempting a difficult exploit can be a great learning experience, and sharing that experience gives other people insight into the real impact of the vulnerability.

Once you have a nice crash, you try to exploit the bug and gain code execution.  Exploitation is all about precision, and there are many things you have to consider to get reliable code execution, which means there are many ways you can fail: bad heap layout, overwrite a freed object with an incorrect size, some variable on the stack you forgot to account for, overwrite a RET address, SEH, or a ROP gadget with an address that changes with every install, every service pack, or every patch level, etc, etc. Sometimes, you don't even realize that until you start throwing the exploit against all your VMs.  If that's the case, you go back and fix it... or worst case scenario, you rewrite four or five times just to get it right.  And that sucks!

Keep in mind that all this hard work had to be done within one week, and many of the participants could only do it in their spare time.  But of course, some lucky fews were blessed by other people from the security community with exploit writing, the Metasploit team also received assistance from fellow hackers with the vetting process.  To those who helped, you know who you are -- THANK YOU!:-)   But again, we would also like to thank the following people for participating, the amount of participation we saw was unexpected and greatly appreciated (for those who specified a nickname, that's the name you'll be listed here):

  • BH
  • Alino
  • Joshua J. Drake
  • glitch07
  • kc57
  • Lepke
  • HeadlessZeke
  • hal
  • diedthreetimes
  • woFF
  • Abysssec
  • Lincoln&  Corelanc0d3r
  • "hidden"
  • kralor
  • mog
  • axtaxt
  • rusko
  • AmonAmarth
  • Rob
  • Patrick Webster
  • Boris
  • xero_
  • nebojsa
  • Jon Butler
  • mr_me
  • cons0ul
  • Juan Vazquez
  • Mark Scrano

Lastly, as planned, we will move on to the paying phase. And for those who are going to Las Vegas for Black Hat / Defcon, we will see you there :-)