Metasploit mailing list archives
Payload Handler issues in MSF 3.0-r3
From: rhyskidd at gmail.com (Rhys Kidd)
Date: Fri, 30 Jun 2006 00:17:51 +0800
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>
Current thread:
- Payload Handler issues in MSF 3.0-r3 Rhys Kidd (Jun 29)
- Payload Handler issues in MSF 3.0-r3 Simple Nomad (Jun 29)
- Payload Handler issues in MSF 3.0-r3 Chris Byrd (Jun 29)
- Payload Handler issues in MSF 3.0-r3 H D Moore (Jun 29)
- Payload Handler issues in MSF 3.0-r3 H D Moore (Jun 29)
- Payload Handler issues in MSF 3.0-r3 Nicob (Jun 29)
- Payload Handler issues in MSF 3.0-r3 H D Moore (Jun 29)
- Re: Porting to MSF 3.x Rhys Kidd (Jun 29)
- Re: Porting to MSF 3.x H D Moore (Jun 30)