Add BrowserExploitServer mixin #2613
Conversation
If something is undetectable, the value may be empty, which triggers a undefined method error because the regex always assumes there is something. So instead of +, we use *.
* Moves shim to data/js/network/xhr_shim.js * Add some yardoc comments
|
Testing browser_autopwn against Windows XP SP3 (no updates) / IE8 (no updates) / Oracle Java 6u32 I get:
(9 sessions indeed, but some died.)
I've retried browser_autopwn, after modifications, 2 times, always restarting the target system. The two times I've got the same results. Not sure if I should be confident about these browser_autopwn results, neither if it means a loss of success on browser_autopwn because of changes, thoughts? (I will proceed with more testing with browser_autopwn) |
|
Tested browser_autopwn under 7 SP1 / IE8 but the java warnings "kill" browser autopwn |
|
Running specs for Rex::Exploitation::JS::* Oka.... more review coming before this can be landed, also feedback about the browser_autopwn thing would be welcome. |
|
@jvazquez-r7 I'm on the browserexploitserver branch, and when I test browser autopwn, I get 22 java meterpreter sessions, all stay alive. I have the full log if you wanna read it. Target is also Winodws XP SP3 + Java 1.6. When I'm on the upstream-master branch, browser autopwn gives me 24 sessions, all java meterpreters except for one win32 meterpreter session. The only thing we have in common is browser autopwn currently loads 66 exploits. So browser_autopwn.rb doesn't rely on anything much. It needs 'rex/exploitation/js/detect', 'rex/exploitation/jsobfu', and Msf::Exploit::Remote::HttpServer::HTML (which is based on HttpServer), and then most of the code are in the module. The pull request makes very little changes to browser autopwn's dependencies, so I'm not sure how they'd affect browser_autopwn.rb:
|
|
Working on it again! |
|
rspec failure is unrelated to this PR: "The command "bundle exec rake" exited with 1." |
|
For testing purposes I've ported aladdin_choosefilepath_bof to use the new mixin. The resulting code can be found here: https://gist.github.com/jvazquez-r7/7421555 The only warning on my side is when IE8 shows a warning activex prompt, the mixin shows a warning on the console about the actvx requirement not met. I guess because of the warning prompt while trying to get browser info. Not a big deal since the exploit finally runs successfully: So looks like the new mixin is mainly working :) just trying to ensure there is nothing bad with the old mixin, which is my only worry at this moment indeed :) Hope to land it soon! |
|
@jvazquez-r7, if you want, you can do a PR to this branch and then I can merge it here. Code looks good to me. I think you can probably make it shorter by using js_property_spray, but looks like the module already works fine. |
|
ooo cool, yes if it looks okey to you, then sending pr there! glad to listen it looks okey, looks like my BrowserExploitServer education is going fine! heh :) |
|
Other tests using the old mixin and the existent exploits to ensure "back compatibility":
At this point really looks like the old mixin and already exsitent exploits shouldn't be affected at all by the new mixin. And the new mixin looks like working :) So if there aren't stoppers of any side looks like it is really really close to be landed :) |
|
rspec's passing after last changes: |
|
Still working eh? Yeah, existing modules using the old mixin should be okay, at least that's the intention of my design. People in the future can still use HttpServer if they decide for some reason BES isn't suitable to their needs. |
|
Prolly it's not the place to post it, since looks more related to browser_autopwn, but just discussing because found it while testing this pr. Looks like the aladdin module doesn't work under browser_autopwn: I've added the browser_autopwn information to the ported module: include Msf::Exploit::Remote::BrowserAutopwn
autopwn_info({
:ua_name => HttpClients::IE,
:ua_minver => "6.0",
:ua_maxver => "8.0",
:javascript => true,
:os_name => OperatingSystems::WINDOWS,
:rank => Rank,
:classid => "{09F68A41-2FBE-11D3-8C9D-0008C7D901B6}",
:method => "ChooseFilePath",
})And launch browser_autopwn with the next options (used the MATCH option to just run the aladdin module under autopwn: And exploit: Nothing :? Neither on the browser. Switching to master and doing the same thing, I get the same thing, nothing: Am I doing something wrong :? |
| platform = platform.gsub(/^Mac OS X$/, 'OSX') | ||
| platform = platform.gsub(/^Microsoft Windows$/, 'Windows') | ||
|
|
||
| regenerate_payload(cli, platform, arch).encoded |
There was a problem hiding this comment.
Not sure if would be a good idea just return the payload, but not the encoded_payload, because there are exploits, for example java ones, which would like to do something like:
p = get_payload(cli, target_info)
jar = p.encoded_jarThere was a problem hiding this comment.
I thought about that before and went undecided what to do: Either that should be another method, or it can automatically return a jar based on target platform, but you'll have to assume having a java platform must mean it needs a jar final payload - which isn't always necessarily true. The original plan is to support this in the next update package, because remember I spent too much time on this and all we wanted was to push this out? If you insist needing this now, I can add this, no problem. But I kind of have to know how you prefer the design.
There was a problem hiding this comment.
I'm not worried if it isn't added atm, just warning which, for example, java exploits, will need to redefine this method. If you're aware and it's good enough atm, then nothing to do here!
There was a problem hiding this comment.
Also warning which this get_payload method works as well as regenerate_payload does. I mean, this doesn't allow a real multi-platform exploit.
There was a problem hiding this comment.
Yeah, I have a list of feature requests that will be filed on redmine right after the mixin is pushed to master. Can't really do it now because technically speaking the mixin does not exist in master.
|
After porting java_storeimagearray to use the new mixin: https://gist.github.com/jvazquez-r7/7438687, it's working okey over browser_autopwn: |
|
|
||
| var query = objToQuery(d); | ||
| postInfo("<%=get_resource%>/<%=@info_receiver_page%>/", query); | ||
| window.location = "<%=get_resource%>/<%=@exploit_receiver_page%>/"; |
There was a problem hiding this comment.
This is going to have problems when get_resource is /, I think. Maybe this instead?
window.location = "<%= "#{get_resource.chomp("/")}/#{@exploit_receiver_page}" %>";There was a problem hiding this comment.
There's a new get_resource() method in this mixin that does this:
super.chomp("/")
|
Landed, saying welcome to BrowserExploitServer :) |
This is a mixin for browser exploit development. This release includes the following features:
Everything is also documented, run "yard" to see. Some methods are spec'd, some will need to rely some manual testing for now.
There are more features planned for the mixin, but won't be included in this release.
This PR also covers the following Redmine tickets:
http://dev.metasploit.com/redmine/issues/8501
http://dev.metasploit.com/redmine/issues/5005
In order to do manual testing, I suggest you play with test/modules/exploits/test/browserexploitserver.rb module.