PassiveX-based payloads and MS06-055

[buffer at softmedia.info (Angelo Dell'Aera)]

Il giorno Tue, 13 Mar 2007 11:40:24 -0700
mmiller at hick.org ha scritto:

> Definitely sounds buggy.  I'll try to reproduce this later this
> evening and send a mail with my findings.  Thanks for the additional
> info.


I did few investigations and it seems to me the problem is located in
the function dispatch_request in lib/rex/proto/http/server.rb. Infact
the code says

def dispatch_request(cli, request)

        [..]

        # Search for the resource handler for the requested URL.  This
          is pretty 
       # inefficient right now, but we can spruce it up later. 
        p = nil 
        len  = 0
        root = nil

        resources.each_pair { |k, val|
                if (request.resource =~ /^#{k}/ and k.length > len)
                        p     = val 
                        len  = k.length 
                        root = k
                        end
                }

                if (p)

                        [..]

               else
                        elog("Failed to find handler for
                        resource:#{request.resource}",LogSource)

                        send_e404(cli, request)
                end


It seems p remains nil which leads to the log message and to the
HTTP 404 I saw yesterday. Moreover the log message clearly states that
when the problem occurs request.resource value is /.

For debugging purpose I modified the code this way

        resources.each_pair { |k, val|
                elog("[*] Handler for resource:#{request.resource}",
                                LogSource) 
                elog("[*] k: #{k} val: #{val}", LogSource) 
                if (request.resource =~ /^#{k}/ and k.length > len)
                        p    = val 
                        len  = k.length
                        root = k
                        end
                }

                elog("[*] p: #{p} resource:#{request.resource} ",
                        LogSource)

                if (p)
                        [..]

This time (using URIPATH "uripath" and PXURI "/pxuri") I see in
framework.log the following new lines

[03/14/2007 11:32:52] [d(2)] core: PassiveX listener started on
http://192.168.33.130:8080/pxuri 
[03/14/2007 11:33:21] [e(0)] rex: [*] Handler for resource: /uripath
[03/14/2007 11:33:21] [e(0)] rex: [*] k: /uripath val:
Rex::Proto::Http::Handler::Procfalse#<Proc:0xb77101bc at ./lib/msf/core/exploit/http.rb:322>
[03/14/2007 11:33:21] [e(0)] rex: [*] Handler for resource: /uripath
[03/14/2007 11:33:21] [e(0)] rex: [*] k: /pxuri val:
Rex::Proto::Http::Handler::Procfalse#<Proc:0xb711945c at ./lib/msf/core/handler/passivex.rb:207>true
[03/14/2007 11:33:21] [e(0)] rex: [*] p:
Rex::Proto::Http::Handler::Procfalse#<Proc:0xb77101bc at ./lib/msf/core/exploit/http.rb:322>
resource: /uripath 
[03/14/2007 11:33:22] [d(2)] core: windows/meterpreter/reverse_http:
Successfully encoded with encoder x86/shikata_ga_nai (size is 483)
[03/14/2007 11:33:28] [e(0)] rex: [*] Handler for resource: /pxuri
[03/14/2007 11:33:28] [e(0)] rex: [*] k: /uripath val:
Rex::Proto::Http::Handler::Procfalse#<Proc:0xb77101bc at ./lib/msf/core/exploit/http.rb:322>
[03/14/2007 11:33:28] [e(0)] rex: [*] Handler for resource: /pxuri
[03/14/2007 11:33:28] [e(0)] rex: [*] k: /pxuri val:
Rex::Proto::Http::Handler::Procfalse#<Proc:0xb711945c at ./lib/msf/core/handler/passivex.rb:207>true
[03/14/2007 11:33:28] [e(0)] rex: [*] p:
Rex::Proto::Http::Handler::Procfalse#<Proc:0xb711945c at ./lib/msf/core/handler/passivex.rb:207>true
resource: /pxuri

The strange thing is that this time I don't see the log message "rex:
Failed to find handler for resource: /" but even this time no luck...

msf exploit(ms06_055_vml_method) > exploit
[*] PassiveX listener started.
[*] Using URL: http://192.168.33.130:8080/uripath
[*] Server started.
[*] Exploit running as background job.
msf exploit(ms06_055_vml_method) > 
[*] Sending PassiveX main page to client

and nothing else..


Regards,

-- 

Angelo Dell'Aera 'buffer' 
Antifork Research, Inc.         http://buffer.antifork.org
Metro Olografix

PGP information in e-mail header


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20070314/15316375/attachment.pgp>