-
Notifications
You must be signed in to change notification settings - Fork 673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Meterpreter - portfwd combined with http scanner module hangs #539
Comments
PHP Meterpreter hangs indefinitely
|
Windows meterpreter scans the title correctly:
Then proceeds to write channel closed forever:
|
mettle osx hangs indefinitely similar to php meterpreter:
|
After some sync-up with Alan above, we concluded that this issue can be separated out into the following parts: Python Meterpreter IssueWe do not get the HTTP title as expected python's ordering of the channel close, and writing the http response happen out of order:
This results in the data not being available in time for msfconsole:
solution: We would need to swap the data write, and the data close, to have the expected http response appear. This is the approach taken by the PHP and Mettle Meterpreters - which have a different issue. PHP and Mettle MeterpreterThere is a deadlock for these Meterpreters between the packet handler, closing the channel and socket, and waiting for the The deadlock occurs when msfconsole receives a channel close request from Meterpreter, msfconsole tries to initiate a tcp shutdown request back to Meterpreter. Waiting for the tcp shutdown request, hangs indefinitely as the channel close request is blocking the main dispatch thread - so the incoming tcpshutdown response isn't handled. Thread dump for the blocked msfconsole: Dispatcher thread
HTTP Parser
TCP Client Channel thread
Windows MeterpreterThe windows Meterpreter does not close the channel before msfconsole initiates the tcp shutdown request. However, the shutdown channel handler is never registered - and so the packet is logged to the screen in a loop. This isn't a big issue, everything continues to work as expected - it just burns CPU cycles, and produces verbose logging:
The logging happens in a continuous loop, as the packet isn't handled correctly, so it loops until it is handled. The logging just makes it seem like multiple packets are received from Meterpreter: This functionality has been broken on non-windows Meterpreters for at least 2 years, from at least Metasploit 5.0.101 |
@AlanFoster Is this fixed with #570? Or does that only fix the Python side of this? |
That PR fixed one of the issues described. The latest information is:
|
@AlanFoster Is this perhaps related to the errors I'm still encountering testing rapid7/metasploit-framework#16583 and the scanner module r.e your first point? |
Run an http server on the host:
Open msfconsole:
Run the payload in a separate tab:
Add a route for the newly opened session:
Run the scanner/http/title module:
Current behavior:
Expected behavior:
However if we turn on the packet logging support, either manually within the packet_dispatcher or after this lands: rapid7/metasploit-framework#16135 we can see meterpreter indefinitely writes back to msfconsole:
The RECV packets are received indefinitely, I haven't looked into this behavior further
The text was updated successfully, but these errors were encountered: