search

rapid7 / metasploit-javapayload

THIS REPO IS OBSOLETE. USE https://github.com/rapid7/metasploit-payloads INSTEAD
87 stars 82 forks source link

Java HTTP(S) problems #31

Closed timwr closed 9 years ago

timwr commented 9 years ago

I'm currently noticing some weirdness with java/meterpreter/reverse_http and reverse_https (reverse_tcp works great). e.g:

payload => java/meterpreter/reverse_http
lhost => 172.16.197.79
lport => 4444
ExitOnSession => false
[*] Exploit running as background job.

[*] Started HTTP reverse handler on http://0.0.0.0:4444/
[*] Starting the payload handler...
msf exploit(handler) > [*] 172.16.197.79:39083 (UUID: 684788547e5d8a86/java=17/java=4/2015-05-08T07:13:24Z) Staging Java payload ...
[*] Meterpreter session 1 opened (172.16.197.79:4444 -> 172.16.197.79:39083) at 2015-05-08 08:13:24 +0100

msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > ls
[-] Unknown command: ls.
meterpreter > ls
[-] Unknown command: ls.
meterpreter > ls
[-] Unknown command: ls.
meterpreter > ls
[-] Unknown command: ls.
meterpreter > ls

Listing: /home/user/dev/git/metasploit-framework
================================================
<snip>

After the initial weirdness things seem to work, but commands also seem to take a lot longer, so I suspect there is a timeout problem somewhere.

I also noticed this, however I can no longer reproduce:

payload => java/meterpreter/reverse_https
HandlerSSLCert => correct.pem
StagerVerifySSLCert => true
lhost => 172.16.197.79
lport => 4444
ExitOnSession => false
[*] Exploit running as background job.

[*] Started HTTPS reverse handler on https://0.0.0.0:4444/
[*] Starting the payload handler...
msf exploit(handler) > [*] 172.16.197.79:39936 (UUID: 3d6ea094545c7028/java=17/java=4/2015-05-08T04:26:04Z) Attaching orphaned/stageless session ...
[*] Meterpreter session 1 opened (172.16.197.79:4444 -> 172.16.197.79:39936) at 2015-05-08 06:33:41 +0100
[*] 172.16.197.79:39938 (UUID: cb00083855c7f36e/java=17/java=4/2015-05-08T05:33:48Z) Staging Java payload ...
[*] Meterpreter session 2 opened (172.16.197.79:4444 -> 172.16.197.79:39938) at 2015-05-08 06:33:48 +0100

msf exploit(handler) > sessions 

Active sessions
===============

  Id  Type                   Information  Connection
  --  ----                   -----------  ----------
  1   meterpreter java/java               172.16.197.79:4444 -> 172.16.197.79:39936 (172.16.197.79)
  2   meterpreter java/java               172.16.197.79:4444 -> 172.16.197.79:39938 (172.16.197.79)

msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > ls

Listing: /home/user/dev/git/metasploit-framework
================================================

<snip>

I'll hopefully fix this with the addition of the set_timeout command, but I thought I'd raise it here for visibility.

timwr commented 9 years ago

On android it's a different story:

[*] Started HTTP reverse handler on http://0.0.0.0:4444/
[*] Starting the payload handler...
msf exploit(handler) > [*] 192.168.43.203:33659 Unknown request to /JoWH_LoQuGLDY4Pe27LuD #<Rex::Proto::Http::Request:0x0000000ab05b08 @headers={"User-Agent"=>"Dalvik/1.6.0 (Linux; U; Android 4.0.4; Android SDK built for x86 Build/IMM76D)", "Host"=>"192.168.43.203:4444", "Connection"=>"Keep-Alive", "Accept-Encoding"=>"gzip"}, @auto_cl=true, @state=3, @transfer_chunked=false, @inside_chunk=false, @bufq="", @body="", @method="GET", @raw_uri="/JoWH_LoQuGLDY4Pe27LuD", @uri_parts={"QueryString"=>{}, "Resource"=>"/JoWH_LoQuGLDY4Pe27LuD"}, @proto="1.1", @chunk_min_size=1, @chunk_max_size=10, @uri_encode_mode="hex-normal", @relative_resource="/JoWH_LoQuGLDY4Pe27LuD", @body_bytes_left=0>...
hdm commented 9 years ago

It looks like Android is still using the old URI format, is this a freshly generated payload?

hdm commented 9 years ago

The delay looks like what happens when stdapi is still loading on Windows meterpreter.

timwr commented 9 years ago

It's a freshly generated payload but the URI format in this repository hasn't been changed for a while so it's probably out of date. Any links/specs/pull requests with info would be appreciated. Also it looks like the extension loading process is broken/non-existent on Android:

W/System.err( 1593): Unknown request detected:
W/System.err( 1593):    TLV_TYPE_METHOD = core_machine_id
W/System.err( 1593):    TLV_TYPE_REQUEST_ID = 13229083941442895921839819037572
W/System.err( 1593): Unknown request detected:
W/System.err( 1593):    TLV_TYPE_METHOD = core_enumextcmd
W/System.err( 1593):    TLV_TYPE_REQUEST_ID = 23467841292372398553576015459914
W/System.err( 1593):    TLV_TYPE_STRING = stdapi
D/dalvikvm( 1593): GC_CONCURRENT freed 389K, 6% free 9051K/9543K, paused 0ms+0ms
W/System.err( 1593): Unknown request detected:
W/System.err( 1593):    TLV_TYPE_METHOD = core_enumextcmd
W/System.err( 1593):    TLV_TYPE_REQUEST_ID = 50461722444296487041905258754958
W/System.err( 1593):    TLV_TYPE_STRING = android
hdm commented 9 years ago

Testing this, it all appears to be working as expected. HTTP is slower to respond than TCP and the lack of "stdapi" early on is because the framework hasn't loaded the stdapi client stubs. It has to wait for the initialization stuff to finish, which requires round-trips for machine_id and other requests. Arguably we should realize stdapi is immediately available for Java, but this currently works just like any other meterpreter.

I can't see any roadblock here for future testing. The android stuff looks normal as well, we want to add those new commands soon, but they dont hurt anything by being unimplemented today.

hktalent commented 6 years ago

me too @timwr auxiliary/server/browser_autopwn metasploit v5.0.0-dev-c525bc3c0a is bug