Timeouts are correctly passed through to the client instances from the
handlers. The cilent also passes those values through to the RDI code so
that the binaries are correctly patched.
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.
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.
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.
Simple change to allow users to set a Comm for new server sockets set up
with a handler. I believe this was intended to be possible when the
ReverseListenerComm option was created, but was left out due to an
oversight.
Tested with and without AES, works as advertised. Set an AESPassword,
get encryptification. Score.
Squashed commit of the following:
commit cca6c5c36c
Author: Michael Schierl <schierlm@gmx.de>
Date: Wed Apr 4 00:45:24 2012 +0200
Do not break other architectures
even when using `setg AESPassword`
commit 422d1e341b
Author: Michael Schierl <schierlm@gmx.de>
Date: Tue Apr 3 21:50:42 2012 +0200
binaries
commit 27368b5675
Author: Michael Schierl <schierlm@gmx.de>
Date: Tue Apr 3 21:49:10 2012 +0200
Add AES support to Java stager
This is compatible to the AES mode of the JavaPayload project.
I'm pretty sure the way I did it in the handlers (Rex::Socket::tcp_socket_pair())
is not the supposed way, but it works :-)
Ashley Donaldson