Metasploit mailing list archives
favicon.ico handler & meterpreter reverse_tcp encoder problems
From: jlbrown1980 at comcast.net (jlbrown1980 at comcast.net)
Date: Thu, 10 May 2007 16:00:06 +0000
Ahh that makes sense, did not realize that it regenerated the shell code. I cant for the life of me figure out why the stdapi extension for meterpreter is not loading then. So for a single connection to the URL the exploit is being hosted on (eg. http://192.168.1.105:4444/zWejak) , it will keep trying to re-encode the payload? I'm trying to figure out how to explain what i'm thinking about.... for example, I setup the exploit get it running on my linux computer, then I run across the hall to my windows xp computer. Paste in the exploited URL to IE7. Then I just let it sit there with the few lines of giberish, no hitting refresh or anything like that. Under those circumstances should it keep trying to encode, or should it successfully encode the payload, upload it, then discontinue encoding if no other sessions/connections are present? For some reason when I am having the windows xp computer connect to the SRVPORT (using meterpreter/reverse_tcp) I cannot get the target computer to connect back to the linux comp via open LPORT. In the MSFCONSOLE display it will display nothing (no uploading DLL or anything like that) when the target computer con nects to it via SRVPORT. When I use the LPORT, I immediately see text on the MSFCONSOLE. DLL uploads, then a meterpreter session is opened by the target PC. When they connect through the SRVPORT, it seems useless though as the extension will not load (stdapi). Thats all I can think of so far. If my understanding of this is correct, shouldn't the target computer connect to the exploited URL using the SRVPORT. Then code is loaded and computer redirects to the LPORT, and open up a meterpreter session? If that is the case, it would appear the problem I'm having lies somewhere in the redirection process. Thanks -------------- Original message ---------------------- From: Kurt Grutzmacher <grutz at jingojango.net>
Ah, I hadn't even realized that IE7 started doing favicon. It's still not a problem because the http server code is recognizing that the URI being passed (/favicon.ico) isn't mapped to any expoit so it's just dropping the request. Part of the exploit routine regenerates shellcode on every connection to reduce the likelihood that two machines will receive the same set of strings, throwing off (H,N)IDS. In on_request_uri the line: # Re-generate the payload, using the explicit target return if ((p = regenerate_payload(cli, nil, nil, target)) == nil) does this. It's just before the send_response function. If you use curl to send multiple requests they payload should be changing on each one. -- ..:[ grutz at jingojango dot net ]:.. GPG fingerprint: 5FD6 A27D 63DB 3319 140F B3FB EC95 2A03 8CB3 ECB4 "There's just no amusing way to say, 'I have a CISSP'."
Current thread:
- favicon.ico handler & meterpreter reverse_tcp encoder problems jlbrown1980 at comcast.net (May 09)
- favicon.ico handler & meterpreter reverse_tcp encoder problems Kurt Grutzmacher (May 09)
- favicon.ico handler & meterpreter reverse_tcp encoder problems jlbrown1980 at comcast.net (May 10)
- favicon.ico handler & meterpreter reverse_tcp encoder problems Kurt Grutzmacher (May 10)
- favicon.ico handler & meterpreter reverse_tcp encoder problems jlbrown1980 at comcast.net (May 10)
- <Possible follow-ups>
- favicon.ico handler & meterpreter reverse_tcp encoder problems jlbrown1980 at comcast.net (May 10)
- favicon.ico handler & meterpreter reverse_tcp encoder problems Kurt Grutzmacher (May 11)
- favicon.ico handler & meterpreter reverse_tcp encoder problems Kurt Grutzmacher (May 09)