New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce number of modules available on BrowserAutopwn #2634
Conversation
I actually recommend depreciating exploits/windows/browser/ms12_004_midi.rb because in my opinion all the other similar ones are better than it. The Java ones seem to cover similar targets. If I recall correctly, java_jre17_provider_skeleton.rb covers 7u21, and is more up to date than other java_jre17_xxxx modules. If other java_jre17_xxxx modules actually cover different targets, then yes we should keep them. If not, I'd say yank them. |
As long as we have something for ancient machines (which is the bread and butter of pentesting for exploits), ya, let's keep the list light. I don't think it's punitive or anything -- just a tradeoff for a more rapid start up time and slightly fewer chances to get fingerprinted and blocked, vs exhaustive lists. |
Votes to delete for java_jre17_jmxbean? something else? @todb-r7 I think coverage of these modules should be good enough. If anyone has some module in mind which shouldn't be deleted, just propose :) Would love @jlee-r7 opinion about the list / deletions. |
PR needs an update. Probably because the aladdin module. |
Doesn't |
Yes it does. But I think the point Juan is trying to make is that we want to deploy whatever other exploit kits are using. If you just want target coverage, you won't have to load as many modules for sure. |
I think target coverage is more important than trying to mimic what others are doing. |
++ on target coverage over exploit kit emulation On Thu, Nov 14, 2013 at 5:23 AM, jlee-r7 notifications@github.com wrote:
|
@jlee-r7 right ms13_080_cdisplaypointer cover all the same IE versions as ms13_037_svg_dashstyle and more but ms13_037_svg_dashstyle provides ASLR bypass without office / java (or other non aslr modules). Because of that, decided to allow ms13_037_svg_dashstyle live on browser_autopwn. But now reviewing, the :jre target is the default one, so aslr bypass via leak only available under user decision.... so I can delete if all you feel comfortable. |
Maybe make the leak target the default? Is there a reason it isn't already? |
The leak relies on ntdll, and the module only covers two versions of ntdll. Although it doesn't change very often, we just don't know for sure how many different versions are out there, so we decided maybe it's safer not to make it as default. |
Ok, that makes sense. |
Basically the reason is the one explained by @wchen-r7, and even when I reviewed and just found these ntdll versions prior to the ms13_037 patch, hope I didn't forget nothing. Because of that we use to avoid the leaks as default targets when they rely on specific dll versions / fingerprinting and use prebuild rop chains. |
Okey, since has sense for @jlee-r7 keep the :jre target as default, just deleting ms13_037_svg_dashstyle from the browser autopwn list, indeed it was in the list because of the info leak to bypass aslr. |
Wouldn't it be better to have more customization in the module itself and leave all of them available to be included? You can then ship the default customization as a decent starting point but if people want ALL they can tick the all box (or however the options are customized) or add in specific modules? |
Would be nice to do something like, I've actually thought about that before too. My version of the idea is that the module provides more customization whitelisting which modules to run, or you can choose pre-configured options: You can do all Java, or IE, all recent added modules, or mimic other exploit kits. Just an idea, no actual implementation yet. |
Tested on rspec and runs fine in msfconsole. Need someone from Pro to test this right quick to make sure this doesn't affect Pro in a negative way. |
Giving a chance to MSF PRO. I'm going to try campaign + browser_autopwn as requested by @wchen-r7 (sorry my msfpro expertise is weird.... so I'm going just to see what can be done :)) |
Best way to tag pro is mention someone by name, like @shuckins-r7
|
Tested pro by myself:
Task Output:
|
The error while running pro which mainly concerns me is:
Would worth wich @dmaloney-r7 confirms there is nothing wrong :) In order to proceed I replaced the msf3 dir into pro for a symlink to a metasploit-framework dir with a checkout to this brnach:
|
As requested by @wchen-r7 : Running #0 Java Applet Field Bytecode Verifier Cache Remote Code Execution from pro (msf3 linked to metasploit-framework git checkout to this branch) Test successful, task output as requested by @wchen-r7 :
|
According to @dmaloney-r7 it shouldn't be a blocker for this pull request:
Indeed, verified with @wchen-r7 which the error only arises when two sessions are spawned from the same module from browser_autopwn. |
List reduced to 17 modules:
Still getting sessions according to test on xpsp3 / ie8 / java 6 old relsease:
The list of modules is build based on recent threats:
http://contagiodump.blogspot.com/2010/06/overview-of-exploit-packs-update.html
http://www.deependresearch.org/2012/11/common-exploit-kits-2012-poster.html
List of modules:
Sure the list isn't perfect, but hope is better than the current list of sixty and other modules, which is an huge list. Additions / Deletions are welcome of course :)