This allows HandlerSSLCert to be used to pass a SSL certificate into the Meterpreter handler. The datastore has to be passed into handle_connection() for this to work, as SSL needs to be initialized on Session.new. This still doesn't pass the datastore into Meterpreter directly, but allows the Session::Meterpreter code to extract and pass down the :ssl_cert option if it was specified. This also fixes SSL certificate caching by expiring the cached cert from the class variables if the configuration has changed. A final change is to create a new SSL SessionID for each connection versus reusing the SSL context, which is incorrect and may lead to problems in the future (if not already).
As I am using a exploit that does a check on the Server HTTP headers to identify the target I saw an error message that reads like this:
>The target server fingerprint "" does not match "(?-mix:(Jetty|JBoss))", use 'set FingerprintCheck false' to disable this check.
Then, while using a HTTP proxy to analyse the requests I am presented with an error that tells me to set another internal option to override a default behaviour. Although it should be pretty clear to everyone using the metasploit framework, I think it is more convenient if all error messages have the same format/way to present suggestions, in this case, presenting the full command the user needs to introduce in order to carry on with the execution of the exploit.
This fixes a huge number of hard-to-detect runtime bugs
that occur when a default utf-8 string from one of these
libraries is passed into a method expecting ascii-8bit
These are not needed, since you can just config the regular handler now
and pick either.
This resolves the conflict (rm'ed the old modules)
Conflicts:
modules/payloads/stagers/windows/reverse_ipv6_http.rb
modules/payloads/stagers/windows/reverse_ipv6_https.rb
JodaZ reported that the handle_connection() sock.put call can
result in the entire reverse_tcp stager hanging if the client
stops receiving or is on a very slow link. The solution emulates
what ReverseTcpDouble already does, which is stage each connection
in a new thread. However, given that a high number of threads
can be a problem on some operating systems (*ahem* win32) this
option is not enabled by default.
We should look into thread pooling and handle_connection() timeouts
as well as event-based polling of multiple clients as alternatives,
but this option will improve the situation for our existing users.
Even though there are calls to has_read_data(), it doesn't prevent
the put() call from blocking in a dead client or slowaris-like
situation. By moving the inp/out detection into the thread, we
allow the main handler to keep processing connections even if
a single connection hangs.
When running a http/https listener the address:port that was being
shown in the output was that which was passed to the victim as part
of the stager and not the actual listener address:port.
This commit fixes this so that the display is correct.
This commit completes our quest to (optionally) decouple the stage's
callback parameters from the interface/port our handler binds to.
LPORT is now patched into the stage over ReverseListenerBindPort.
This commit removes the now unused bind_address function from
reverse_http.rb. This function returns an array of hosts the handler
should attempt to bind to (e.g., [LHOST value, any])
Other handlers (e.g., reverse_tcp.rb) loop through these values until
they're able to start a server with that bind address.
The HTTP server doesn't work this way. It's setup to try one address
and that's it. It makes sense to have the HTTP server always bind to
0.0.0.0 by default as future modules run by the user may register
resources with the same HTTP server.
This commit returns the HTTP/S handler to its former semantic glory.
By default the HTTP/S handler will bind to :: or 0.0.0.0. If the
user specifies a ReverseListenerBindAddress then, instead, the
server will bind to that address.
The previous commit to change the URL to always reference LHOST
should go with this too. LHOST is always my intent of where the
stage should call home too. ReverseListenerBindAddress would make
sense as my intent as to where I want to bind to. The two options
shouldn't take on each other's meanings.
Redmine #8726 documents a change where the reverse HTTP/S
tries to bind LHOST and if it can not it does a hard stop
If it's expected that users will use ReverseListenerBind-
-Address then this commit addresses #8726 by patching the
HTTP/S stage with the host provided by the user in LHOST.
Currently ReverseListenerBindAddress (if used) is patched
into the stage. This makes for a broken HTTP/S session if
the user sets this option to 0.0.0.0.
With this commit--users can provide any LHOST they like
and set ReverseListenerBindAddress to 0.0.0.0 and things
will work.
This commit does not attempt to bring the HTTP/S handler
back to the old behavior of falling back to 0.0.0.0 when
it can't bind LHOST. I'd welcome the old behavior but I
leave it to you to decide what makes sense. :)
This change updates the proxy handler code, which for some reason was
ommitted in the orginal commits. This now uses the same mechanism as
the new code. It removes `HIDDENHOST` and `HIDDENPORT`, and instead
uses `ReverseListenerBindHost` and `ReverseListenerBindAddress`.
This adds a `ReverseListenerBindPort` advanced setting to the reverse listeners whic
allows for the local bind port to be separated from the `LHOST` setting used in the
payload. This means that listeners can bind to different ports in cases where the
attacker isn't able to listen on the same port that the victim can call out on, but
there are NATs/portforwards/whatever in place that allow the connection to happen.
Aside from codebase-wide changes, nearly all of these tests haven't been
touched since before 2010, and there is no effort to maintain this style
of testing. We've moved on to (correctly) seperating out our tests from
our codebase.
created a new advanced option "HttpUknownRequestResponse" that will be sent back in the HTML body of unknown requests instead of the old static "No site configured at this address" message.
Depending on how a socket was created, #getsockname will return either a
struct sockaddr as a String (the default ruby Socket behavior) or an
Array (the extend'd Rex::Socket::Tcp behavior). Avoid the ambiguity when
generating SSL certificates for meterpreter handlers by always picking a
random hostname.
This is by no means a proper fix for the underlying problem of
Socket#getsockname having ambiguous behavior before and after being
extended with Rex::Socket::Tcp. It does, however, solve the immediate
problem of not being able to create tunneled meterpreter sessions over
http(s) sessions.
[SeeRM #7350]
HD Moore
Pedro Laguna
Tod Beardsley
Joshua Smith
James Lee
scriptjunkie
David Maloney
jvazquez-r7
Niel Nielsen
OJ
Raphael Mudge
Tab Assassin
Alexandre Maloteaux
corelanc0d3r
Rob Fuller
RageLtMan
sinn3r
Sherif Eldeeb
Tod Beardsley