While this method here is somewhat noisy on the network it eliminates
a poor user experience when the handler is started but the payload is
not yet running on the target.
When a target is sent a udp packet and it is not rejected push down
an initial "echo syn" command that will respond with output. This
allows framework to be aware that the payload is what is running on
the server port instead of assuming a non-existent target is a valid
session.
This is a repackaging effort for the work i originally pushed in
6035. This segment of the PR provides UDP session handlers for
bind and reverse sessions, a Windows Metasm stager (really the
TCP stager with a small change), and a pair of socat payloads for
testing simple UDP shells. Netcat or any scripting language with
a sockets library is sufficient to use these sessions as they are
stateless and simple.
Testing of this PR requires rex/core #1 and rex/socket #2
The SSL testing which was being done on 6035 is backed out, left
for a later time when we can do DTLS properly.
All meterpreter Clients are created equal, and as such they all
include the PacketDispatcher mixin and call its init methods when
a passive dispatcher is needed. However, since tunneling protocols
have different requirements for implementation, the methods which
provide protocol-specific functionality need to be mixed into the
Client before it attempts to initialize the dispatcher.
Provide a dispatch_ext option in the has passed to the client on
init from the session handler which is an Array containing mixin
references which are sent to :extend calls in the :init_meterpreter
method just prior to calling :initialize_passive_dispatcher.
Each handler implementation can thus push chains of mixins to the
client in order to provide middleware specific to the tunnel. Down
the road, this should permit stacking C2 encapsulations or tunnel
protocols/permutators to create unique session transports on the
fly.
This commit moves much of the platform-specific logic from the
reverse_http handler down into the payloads. This makes the handler
a bit more agnostic of what the payload is (which is a good thing).
There is more to do here though, and things can be improved.
Handling of datastore settings has been changed to make room for the
ability to override the datastore completely when generating the
payloads. If a datastore is given via the `opts` then this is used
instead otherwise it falls back to the settings specified in the usual
datatstore location.
Down the track, we'll have a payload that supports multiple stages, and
the datastore will be generated on the fly, along with the stage itself.
Without this work, there's no other nice way of getting datastore
settings to be contained per-stager.