The Metasploit Framework provides different mixins you can use to develop a browser exploit, mainly they are: Msf::Exploit::Remote::HttpServer, which is the most basic form of a HTTP server. Msf::Exploit::Remote::HttpServer::HTML, which provides Javascript functions that the module can use when crafting HTML contents. And Msf::Exploit::Remote::BrowserExploitServer, which includes features from both HttpServer and HttpServer::HTML, but with even more goodies. This writeup covers the BrowserExploitServer mixin.
The BrowserExploitServer mixin is the only mixin specially designed for browser exploitation. Before you use this mixin, you should understand what it does behind the scenes for you:
1. It automatically collects the browser information, including things like: OS name/flavor/version, browser name/version, whether a proxy is used, Java plugin version, Microsoft Office version, etc, etc. If the browser doesn't have Javascript enabled, then it collects less info. All the info gathered will be stored in a profile managed by the mixin.
2. The mixin will then tag the browser to track the session. It will also use the same tag to retrieve the profile when needed.
3. Before the mixin decides if it should serve the exploit to the browser, it will check with the module for any exploitable requirements. If the requirements aren't met, it will send a 404 to the browser, and the operation bails.
4. If the requirements are met, the mixin will pass the profile (information about the browser gathered during the detection stage) to the module, and let it take over the rest.
Hint: In the module, you can check the :source key in the profile to determine whether Javascript is enabled or not: If the :source is "script", it means Javascript is enabled. If it's "headers" (as in HTTP headers), then the browser has Javascript disabled.
Exploitable browser requirements are defined under "BrowserRequirements" in the module's metadata. Here's an example of defining a vulnerable target running some ActiveX control:
You can also define target-specific requirements. This is also how the mixin is able to automatically select a target, and you can get it with the "get_target" method. Here's an example of how to define target-specific requirements for IE8 on Win XP and IE 9 on Win 7:
After the detection stage and the requirement check, the mixin will trigger the "on_request_exploit" callback method, that's where you handle the HTTP request, craft the HTML, and send back the exploit response. Here's an example of how to set up "on_request_exploit":
ERB is a new way to write Metasploit browser exploits. If you've written one or two web applications, this is no stranger to you. When you're using the BrowserExploitServer mixin to write an exploit, what really happens is you're writing a rails template. Here's an example of using of this feature:
The BrowserExploitServer mixin also offers plenty of other things useful while crafting the exploit. For example: it can generate a target-specific payload when you call the "get_payload" method. It also gives you access to the RopDb mixin, which contains a collection of ROPs to bypass DEP (Data Execution Prevention). Make sure to check out the API documentation for more information.
To get thing started, here's a code example you can use start developing your browser exploit:
