Payload Handler issues in MSF 3.0-r3

[cbyrd01 at gmail.com (Chris Byrd)]

Although I didn't investigate to the level that you have, I have
noticed similar behavior.  I had chalked it up to alpha behavior, but
it did prevent some otherwise valid exploit attempts from succeeding.
In general msf3 hasn't been as reliable (for me) in exploiting targets
with the same exploits as msf2.6, and I wonder if this could be part
of the issue.

- Chris

On 6/29/06, Rhys Kidd <rhyskidd at gmail.com> wrote:
> 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.