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.
AWS EC2 Nitro instances (and possibly others) support serial proxy
over SSH using the Instance Connect API:
https://docs.amazonaws.cn/en_us/AWSEC2/latest/UserGuide/
connect-to-serial-console.html
This process consists of sending an SSH pubkey to the serial proxy
control plane, connecting to a well-known URL with the instance ID
and port number as username, and the SSH private key as credential.
The resulting session is a "fragile" SSH context which does not
tolerate Channel-closing, requiring some special handling in Msf to
safeguard the initial Net::SSH::CommandStream.
Implement a BindAwsInstanceConnect Handler which loads an SSH key
from the local FS or generates a new one on the fly, passes the
pubkey to the InstanceConnect API, and then establishes SSH comms
with the InstanceConnect SSH proxy.
Implement a AwsInstanceConnectBind to handle resulting connetions,
derived from SshCommandShellBind, with an updated #bootstrap which
avoids meddling with the fragile CommandStream/Channel.
Testing:
Got serial console to the ttyS0 login prompt of a Nitro EC2 VM.
Logged in using previously-known credentials.
Verified console operations.
Notes:
Handler keeps firing, same as the SSM session concern.
There is a limit to the number of sessions which an instance can
hold (possibly only one).
* Prevent using post modules with the session
It doesn't work reliably because of winpty and how the output is
mangled.
* Set the limit correctly
* Fix Linux PTY downgrade issues
* Remove filtering
The filtering implementation is incomplete and unnecessary.
Filtering is unnecessary because Linux sessions execute a stub on
session start up that uses a combiantion of stty and a fifo to emulate a
PTY-less session. Windows sessions do not need filtering because they
have been explictly marked as being incompatible with the Post API which
is confused by the extra characters.
The filtering implementation is incomplete because it does not account for
echo fragments that are split across lines. It also does not account for
all of the ANSI escape codes.
* Add module docs for enum_ssm
* Revert "shell_command_token_base get 0th output index"
This reverts commit 3a4cb3560f.
* Correct the order of arguments to #set_term_size
* Fix paths for directory checks
The path C:\ ends with a trailing backslash which will cause bash to
wait for another line if input. This places the shell in an undesirable
state.
* Fix post module tests for Linux
* Remove the command document
This hasn't been tested and it's unclear under what conditions this
would be used.
* Fix Windows SSM sessions
---------
Co-authored-by: Spencer McIntyre <zeroSteiner@gmail.com>
Update the enum_ssm module to use the correct session type with the
appropriate platform. Also set the session information to the same
string which also removes the eye sore that is the shell banner.
With the introduction of SCTP socket support in Rex::Socket via
https://github.com/rapid7/rex-socket/pull/56, Framework can utilize
this protocol for session transports similarly to TCP as it is a
stream-wise transport.
Implement bind and reverse handlers for the new socket type.
Implement example bind and reverse payloads using socat copying
from the initial udp sessions implementation.
Testing:
Rudimentary bind session test against local Libvirt Linux VM
Next steps:
Implement the language-level payloads for the interpreters common
to POSIX environments supporting SCTP.
Implement meterpreter transports for SCTP in Python, PHP, Mettle,
and Java modalities (Windows doesn't support it without carrying
its own usermode protocol library).
Create an AwsSsmCommandShellBind session type to provide intercept
points for shell command interactions and a wrapper class which is
used to register the new session.
Update Msf::Handler::BindAwsSsm with its own #create_session method
utilizing the new session type to provide direct control of session
initialization.
Restore standard handler attributes and thread nomenclature in an
attempt to resolve the repeating session creation when #to_handler
is called on the payloads.
Testing:
Tested in local framework, unfortunately the recurring session
init problem appears to persist. Requesting testing on an upstream
Framework by saner folks.
Update SSM handler code to standardize datastore option names per
@zeroSteiner.
Update payload modules to reflect the OS targets against which they
are to execute.
Implement terminal resizing to WebSocket shell
Reorganize code to ease later extension
Implement peerinfo in channel context from AWS EC2 SSM information
gathered during session validation
Implement echo-filtering for session inputs (hacky, but works)
Testing:
Verified console resizing, color/reset/etc
Verified peerinfo and interaction
Verified common session operations
Notes:
SSM WebSocket sessions time out pretty quickly, implementing
dedicated SSM session types which support suspend/resume to match
backgrounding/foregrounding operations in the console should help
to resolve this. Alternatively, a keep-alive using empty frames
may be implemented in the SsmChannel itself on a separate thread.
Alter WebSocket::Interface::Channel to accept a mask_write flag to
set the Channel behavior for outgoing data (since the on_data_write
handler can only deal with the buffer provided, not how the wsframe
containing it is written to the "wire"). Set the flag to false for
SSM's WebSocket operations.
Extract Rex::Proto::Http::WebSocket::AmazonSsm from the handler to
permit reuse by other framework elements.
Implement SSM-specific UUID handling.
Create sane SsmFrame constructor to permit convenient operations.
Implement Http::WebSocket::AmazonSsm::Inteface::SsmChannel from
Http::WebSocket::Inferface::Channel with message-type handling and
output processing. Acknowledge incoming messages, process incoming
acknowledgements, increment sequence IDs appropriately, and handle
basic logging.
This new session type removes the 2500 char output restriction and
stateless peer cwd.
Testing:
Execution of handler now provides stateful interactive shells
Next steps:
More testing, preferably by other people with upstream framework.
Peerinfo and presentation updates for the session channel
Misc cleanup
Future work:
Implement new SSM session type with support for multi-console,
port-forwarding/socket routing, and custom SSM documents.
Implement FSM handlers for session suspension and resumption in
Http::WebSocket::AmazonSsm::Interface::SsmChannel
Create BinData structure to handle the proprietary format of AWS'
SSM WebSocket protocol. Implement relevant inter-field dependencies
and a virtual payload_valid field to handle the SHA256 digest check
for the current state of r the payload_data field.
Implement user-accessible SSM document definition to permit use of
custom-defined command and session documents (stubbing for session
types such as port-forwarding) which may be of use when dealing
with restrictive IAM.
Restructure handler in preparation for moving the WebSocket code
into Rex::Proto for use by other consumers such as custom payloads
and session types like fully interactive (vs REPL) modalities, or
some form of "cloud-native" MeterSSM.
Testing:
Verified acquisition of SSM WS frame and relevant field ops
Next Steps:
Create WS loop to abstract shell communications
Wrap in Rex*Abstraction bowties for the session handler
Test -> ? -> Profit
Using the implementation in https://github.com/humanmade/ssm, use
the onconnect websocket authenticator as a JSON string written as
a wstext Frame into the established WebSocket. This keeps the sock
open with AWS after returning it from the method, but subsequent
operations will require definition and encoding/decoding of SSM's
proprietary data structures.
Testing:
The initialized WebSocket is kept open and returns wsframes when
requested.
Next steps:
Port the various data structures from the JavaScript library
Implement encoding & decoding for their wire-level formats
Implement state management and data flow handling logic for
the WS SSM protocol.
Port WebSocket initiation routine from Exploit::Remote::HttpClient.
Currently inert since it appears to require a handshake procedure
along with its own type of data frame.
Implement graceful fail-down for session establishment which tries
to initiate a WebSocket session for proper functionality, failing
down to the script-execution style session abstraction if the WS
session does not marshal properly. Use this exception handling to
deal with the WIP WS session state.
Testing:
Gets the same kind of command-abstracted session as before
Interface-extended socket returns garbage from naive #write and
nothing from put_string or put_binary - not going to get anything
out of this thing until we establish the handshake procedure.
Next steps:
Figure out data frame structures for handshake and console IO
Implement handshake on-init, validate state
Implement IO abstraction for the resulting Channel for handoff
to #handle_connection
Amazon Web Services provides conveniently privileged backdoors in
the form of their SSM agents which do not require connectivity with
the target instance, merely valid credentials to AWS' API. Due to
this indirect "connection" paradigm, this mechanism can be used to
control otherwise "air-gapped" targets.
This approach abstracts asynchronous request/response parsing for
SSM requests into an IO channel with which the AWS SSM client is
then wrapped to emulate the expected Stream. The mechanism is rather
raw and could use better error handling, retries on laggy output,
and a threadsafe cursor implementation. It may be possible to start
an actually interactive session using the #start_session method in
the AWS client library, but so far testing has not yielded positive
results.
There is a significant limitation with these sessions not present
in normal stream-wise abstractions: a response limit of 2500 chars.
This limitation can be overcome by utilizing an S3 bucket to store
command output; however, due to the nature of access we seek to
obtain, it would not only add to the logged event loads but retain
the results of our TTPs in a "buffer" accessible to other people.
This functionality can be added down the line in the form of S3
config options in the handler to be passed into the SSM client for
command execution and acquisition of output.
Testing:
Gets sessions, provides command IO, leaves a bunch of log entries
in CloudTrail (something to keep in mind for opsec considerations).
Next steps:
Reorganize our WebSocket code a bit to provide connection and WS
state management inside Rex::Proto::Http::Client which can then be
exposed to the Handler without having to mix-in other namespaces
from Exploit.
Use the #start_session SSM Client method to extract the WS URL
for the relevant channel, and utilize that as the underpinning for
our session comms.
OJ Reeves