Payload Handler issues in MSF 3.0-r3

[rhyskidd at gmail.com (Rhys Kidd)]

Hi All,

 

I've been working through updating the exploits that are currently missing
in the MSF 3.x release, and have noticed some curious behaviour with the
payload handlers.

 

Attached is backbone_netvault.rb, which is working correctly and providing a
bind shell when attacking:

 

Server

-----------------

7.30 Build 37 Release R2004NOV06-DAATAA (2K)

7.10 Build 42 Release R2003OCT31-CHIEF  (2K)

 

Client

-----------------

7.11 Build 10 Release R2004AUG19-CHIEF (2K)

7.10 Build 42 Release R2003OCT31-CHIEF (2K)

 

 

It is effectively a direct port of backbone_netvault_heap.pm as far as I am
aware. 

 

However, when I watch the actual packets flying between the attacking
console ( 192.168.213.1 ) and the target ( 192.168.213.130 ), I see that as
soon as the 'exploit' command is issued, the bind handler immediately begins
attempting to contact port 4444 on the target, even though the Framework
could of gone no further than executing:

 

          def exploit     

                   connect

                   print_status("Trying target #{target.name}...")

 

It is my understanding that by adding at the beginning of the payload:

 

include Exploit::Remote::Tcp

 

The "connect" call is in reference to the socket with parameters RHOST,
RPORT etc and NOT the payload handler socket.

 

 

While the port 4444 attempts are simply met with a RST flag until the bind
socket is correctly initialised, I'm wondering why the attempts begin so
early. This particular exploit does take some time to run through the
exploitation process, and the ret overwrite doesn't occur until we have made
~6 further attempts to connect to the vulnerable service after the payload
is delivered.

 

Can anyone shed some light on why the payload handler is so eager?

 

 

- Rhys

 

 

 

 

Details you may want

=========================

 

Msf > version

Framework     : 3.0-alpha-r3.1.19

Console         : 3.0-alpha-r3.1.71

 

I had it running from within cygwin, using their current ruby package. 

I did however try this exploit on a Fedora Core 5 host, and had the same
result.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20060630/88061055/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bakbone_netvault.rb
Type: application/octet-stream
Size: 4143 bytes
Desc: not available
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20060630/88061055/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bakbone_netvault_msf3.0.pcap
Type: application/octet-stream
Size: 320039 bytes
Desc: not available
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20060630/88061055/attachment-0001.obj>