Logic for finding connection UUIDs has been pushed into reverse_http so
that it's not part of the Http::Server any more. It's a little bit of a
leaky abstraction, but at least the logic is in the one place now.
Support added and tweaked for including the UUID in an HTTP header or in
a GET param.
Currently don't have support for it in the BODY as as param, not sure if
that's a requirement yet or not.
Same goes for cookies.
NOTE: This change does remove the trailing "/" from URIs registered..
which implies that things might not match. So more to do here.
Connection IDs are stored in the request now, so that they can be
referenced by clients if and when required.
IDs are pulled from various locations in the request.
Interim commit, contains code persists a C2 profile instance for reuse
rather than having many being parsed all the time. Also begins work
handling UUIDs outside of the URI.
Stageless payloads start with an :init_connect which needs special
consideration given that it's just redirected. There's no client
instance at that point, so there's no C2 associated with it, so we have
to just manually wrap the outbound packet so that things work correctly.
* Supporting "wrapping" and "unwrapping" of payloads based on the C2
profile, which means that suffixes and prefixes are used based on what
the configuration indicates.
* Made sure taht the debug_build flag is passed through on HTTP/S
payloads.
* push details of the C2 profile into the meterp client so that required
details can be easily accessed.
Still don't have all the fields implemented, but this at least supports
the notion of having different URIs for GET and POST.
The approach taken, to reduce the impact on how much code has to be
changed, is to extract the UUID for the connection and use that as a
resource identifier. This UUID doesn't have any slashes in it, and hence
will not collide with any URI. This means we can use the UUID as a key
in the same hash as the resource URIs knowing that a direct lookup will
find the right session, even if by some miracle the UUID collides with a
chosen/generated URI. Any URI in the resource list will be prefixed with
a forward slash.
The listener will listen on all URIs that exist for the Meterp
configuration, including LURI setting, and the `uri` values in all three
areas that it might be specified in the C2 profile.
Munged a few commits into this one. But we have basic support for
TLV-based configuration blocks instead of hard-coded block sizes.
Initial support for the MC2 stuff is in as well, but more to come.
The reverse_http/s listeners result in awful errors when
multi/meterpreter is set as the payload. Anyone that hits the endpoint
with an invalid or missing UUID will spam the MSF console with
exceptions.
This patch avoids this issue in cases where the UUID isn't specific. We
avoid setting it as a default, which doesn't make sense anyway.
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.
OJ Reeves