browser_autopwn exploit ordering updates (Bug #7253) #1612

Closed
wants to merge 4 commits into
from

Conversation

Projects
None yet
4 participants
Contributor

neinwechter commented Mar 19, 2013

Updates to how browser_autopwn chooses exploits related to:
http://dev.metasploit.com/redmine/issues/7253

Results in higher ranked exploits being attempted before less stable low ranked exploits, regardless of status as a JS or non-JS related exploit.

I essentially placed JS and non-JS exploits into a single list (instead of the JS only list), ordered by exploit rank. If javascript is detected, this list is iterated through from highest exploit ranks to lowest and appropriate output written. When javascript support is not present, nothing changes from the past.

I have tested with clients connecting from OSX (Chrome), Ubuntu (Chrome and Firefox) and Windows XP (IE6,IE7,IE10), verifying exploit count and the fixed exploit order between pre-change and post-change versions of browser_autopwn (using debug to follow through on the client side).

Example of testing from IE6 in Windows:

Original Version:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.2)

os_name Microsoft Windows
os_flavor XP
os_sp undefined
os_lang en-us
arch x86
ua_name MSIE
ua_version 7.0

starting exploits (42 total)
next_exploit(0)
trying /windows/browser/ie_createobject of 42
this client does not appear to be vulnerable to /windows/browser/ie_createobject
next_exploit(1)
trying /windows/browser/ms10_018_ie_behaviors of 42
test says it is vuln, writing iframe for /windows/browser/ms10_018_ie_behaviors
next_exploit(2)
trying /windows/browser/ms11_003_ie_css_import of 42
this client does not appear to be vulnerable to /windows/browser/ms11_003_ie_css_import
....
trying /multi/browser/java_jre17_method_handle of 42
test says it is vuln, writing iframe for /multi/browser/java_jre17_method_handle
next_exploit(40)
trying /multi/browser/java_rhino of 42
test says it is vuln, writing iframe for /multi/browser/java_rhino
next_exploit(41)
trying /multi/browser/java_verifier_field_access of 42
test says it is vuln, writing iframe for /multi/browser/java_verifier_field_access
next_exploit(42)
End

New Version:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.2)

os_name Microsoft Windows
os_flavor XP
os_sp undefined
os_lang en-us
arch x86
ua_name MSIE
ua_version 7.0

starting exploits (42 total)
next_exploit(0)
trying /multi/browser/java_atomicreferencearray of 42
test says it is vuln, writing iframe for /multi/browser/java_atomicreferencearray
next_exploit(1)
trying /multi/browser/java_jre17_exec of 42
test says it is vuln, writing iframe for /multi/browser/java_jre17_exec
next_exploit(2)
trying /multi/browser/java_jre17_glassfish_averagerangestatisticimpl of 42
test says it is vuln, writing iframe for /multi/browser/java_jre17_glassfish_averagerangestatisticimpl
next_exploit(3)
...
trying /windows/browser/tom_sawyer_tsgetx71ex552 of 42
test threw an exception: Syntax error
next_exploit(40)
trying /windows/browser/winzip_fileview of 42
test threw an exception: Syntax error
next_exploit(41)
trying /windows/browser/wmi_admintools of 42
test says it is vuln, writing iframe for /windows/browser/wmi_admintools
next_exploit(42)
End

neinwechter added some commits Mar 18, 2013

@neinwechter neinwechter Updates to browser_autopwn to attempt exploits by rank for enhanced
reliability
	modified:   modules/auxiliary/server/browser_autopwn.rb
c76fb01
@neinwechter neinwechter Small cleanup of browser_autopwn updates
	modified:   modules/auxiliary/server/browser_autopwn.rb
29b4219
@neinwechter neinwechter Fix nil ua_name processing and other minor tweaks
	modified:   modules/auxiliary/server/browser_autopwn.rb
bf7ba24
Contributor

todb commented Mar 19, 2013

This looks great, thanks! I'll take a look later today and see is we can't
merge it.

Contributor

todb-r7 commented Mar 19, 2013

So I am testing through on this:

vuln-image

So far, so good. I did see that firefox likes to crash out pretty much right away, so already the java exploits are winning (the java meterpreter sessions open and migrate out before the crash). Opera on Windows is kind of a fail though; I wonder if autopwn needs to special-case Opera exploits? Need to install Opera 9.1 and see if that one picks up. Also need to check on Safari, and also a Linux target if we have anything useful in that set.

Contributor

todb-r7 commented Mar 19, 2013

...and currently (without this PR), Firefox crashes right away and MSIE8 appears to be misidentified, so no shells, so already a huge improve right there.

Update: IE tested version here is:

IE8 SP3 8.0.6001.18702
Update Versions: 0

@todb-r7 todb-r7 commented on the diff Mar 19, 2013

modules/auxiliary/server/browser_autopwn.rb
@@ -501,17 +505,15 @@ def start_exploit_modules()
print_line
# Sort the tests by reliability, descending.
- @js_tests.each { |browser,tests|
- tests.sort! {|a,b| b[:rank] <=> a[:rank]}
- }
-
+ # I don't like doing this directly (wihout a !), but any other sort wasn't sticking - NE
+ @all_tests = @all_tests.sort.reverse
+
@todb-r7

todb-r7 Mar 19, 2013

Contributor

This would probably work

@all_tests.sort!.reverse!

but I wouldn't worry about it. I kinda don't like the ! methods because I always get burned by nil as a return value.

@jlee-r7

jlee-r7 Mar 20, 2013

Contributor

You don't have to worry about the return value if you do it in separate statements:

@all_tests.sort!
@all_tests.reverse!
@neinwechter

neinwechter Mar 20, 2013

Contributor

Ahh - good call, completely overlooked the obvious. I'll keep that in mind for future uses, unless for project preference/consistency reasons you'd rather have it changed here. Thanks.

Contributor

todb-r7 commented Mar 19, 2013

Yep, without your fix, browser_autopwn fails out completely on IE8 XPSP3, no hotfixes:

[*] 192.168.145.128  browser_autopwn - Handling '/master'
[*] 192.168.145.128  browser_autopwn - Handling '/master?sessid=TWljcm9zb2Z0IFdpbmRvd3M6WFA6dW5kZWZpbmVkOmVuLXVzOng4NjpNU0lFOjguMDo%3d'
[*] 192.168.145.128  browser_autopwn - JavaScript Report: Microsoft Windows:XP:undefined:en-us:x86:MSIE:8.0:
[*] 192.168.145.128  browser_autopwn - Responding with 43 exploits
[*] 192.168.145.128  itms_overflow - Generating payload...
[*] 192.168.145.128  itms_overflow - => 445 bytes
[*] 192.168.145.128  itms_overflow - Generating HTML container...
[*] 192.168.145.128  itms_overflow - Sending itms page
[-] 192.168.145.128  firefox_escape_retval - Exception handling request: Connection reset by peer
[*] 192.168.145.128  itms_overflow - Generating payload...
[*] 192.168.145.128  itms_overflow - => 445 bytes
[*] 192.168.145.128  itms_overflow - Generating HTML container...
[*] 192.168.145.128  itms_overflow - Sending itms page
[*] 192.168.145.128  ie_execcommand_uaf - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
[*] 192.168.145.128  ie_execcommand_uaf - Redirecting to sZHMg.html
[*] 192.168.145.128  ie_execcommand_uaf - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
[*] 192.168.145.128  ie_execcommand_uaf - Loading sZHMg.html
[*] 192.168.145.128  ie_execcommand_uaf - Using msvcrt ROP

Contributor

todb-r7 commented Mar 19, 2013

I will endeavor to land this March 20; just needs a code review now, happy path seems to work out well.

Thanks again!

Contributor

neinwechter commented Mar 19, 2013

No problem! Since I'm familiar with this module now, let me know how you make out with Opera (and anything else that misreports) and I'll take a look at that separately.

Glad to see this PR improves the results.

Contributor

neinwechter commented Mar 19, 2013

Just double checked and the OS/browser detection is done using javascriptosdetect, which I know there are other redmine issues opened up on, i.e.:
http://dev.metasploit.com/redmine/issues/7252

I have a feeling javascriptosdetect.js needs a comprehensive review to resolve some of these underlying issues to anything that relies on it for detection.

Contributor

neinwechter commented Mar 19, 2013

FWIW - I also just popped Opera 9.50 on XP SP3 with the PR version (resulted in two sessions)

todb-r7 closed this in 011b689 Mar 20, 2013

neinwechter deleted the neinwechter:browser_autopwn-updates branch Mar 25, 2013

@dougsko dougsko added a commit to dougsko/metasploit-framework that referenced this pull request Jun 20, 2013

@todb @dougsko todb + dougsko Merge 'neinwechter/browser_autopwn-updates'
Brings in neinwechter's BAP fixes. Seems to not only be a more sane
strategy, but in practice, ends up with tons more shells for at least
MSIE which is what most people are using it for anyway.

[Closes #1612]
600d1eb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment