Once Upon a Cloudy AIR I Crossed a Gap Which Wasn't There

A key tenet of security paradigm and function is the concept of segmentation - developers are taught (and sometimes forced) to keep data and execution separate, system accounts separate levels of privilege, networks are segmented by VLANs at layer2, routers at layer3 which can implement access control, firewalls at layer 4 for (sometimes) stateful filtering, and so on...

Service Oriented Architectures are designed with separate control and execution planes for various scaling, stability, and security concerns to be addressed in parallel. Implementation of secure segmentation (providing enforced boundary between elements controlled by one entity and another) would mandate that he APIs governing functions executed by the SOA should be separate from the client workload of the SOA, especially when the SOA is an IaaS cloud running someone's ring0-up system. Indirection such as message queuing are standard for cloud architectures to asynchronously handle workloads in compartmentalized environments - the system is actually designed to avoid direct access to resources. Violation of this design tenet means that the API has access Into the Runtime...

Concurrently, within the workload, privilege levels separate "mere access" from "access sufficient to do (more) damage;" and when the AIR also insists on bypassing the privilege barriers, we get something of a "user friendly, persistent, external, rootkit/implant." Ironically, the same cloud (provider) then charges for the resources to run the implant and most readers today work in organizations which run at least one of these somewhere.

At Semper Victus, we primarily work in our own private clouds - OpenStack and similar environments, which provide their own versions of these "really bad idea backdoors" - NovaSSH being one good example. Controlling and building our clouds, we simply eschew that element from the deployment and keep the serial links of VMs strictly RO for output logging. Public clouds, however, do not necessarily offer that option and require users take some manual effort to disable these mechanisms one at a time.

One such public cloud mechanism is part of Amazon Web Services' SSM subsystem - comprised of an agent resident within many/most of their AMIs and a control plane through their public API which can execute commands or create real-time interactive WebSocket command shells providing passwordless elevation of privilege in most if not all cases. Clients with appropriate assumed roles or IAM credentials (or hijacked intermediate tokens, access to the control plane, etc) can request SSM documents be applied to any number of SSM target agents to do everything from performing audit and qualification, to running commands and returning results, to initiating a WebSocket session which drops the user connecting into a shell run by the account of the SSM agent on-host.

As of January, savvy Metasploit users have been able to use code from a pull request implementing the command/result and WebSocket documents to provide native shells to metasploit for SSM agents. As of this morning, and after months of tireless QA by Spencer Mcintyre and the rest of Rapid7's Metasploit team, every user will have access to this functionality moving forward.

Specifically, the work provides two actual types of Metasploit session in the same section of library code: 1. Using the SSM command document, Metasploit will create a (first true C2) session by polling the control plane API for responses to the issued command and then stitching the command/response pairs into "something that looks like a session." Unfortunately, for forensic integrity reasons, there is a 2k character limitation on output but its handy when nothing else works.

2. Using the SSM session document, Metasploit will acquire an ephemeral session token mapping to a websocket representing its console in a full TTY shell. While Metasploit itself currently does not have full remote-end TTY support, the QA process around this functionality has moved the ball forward a mile in that area to a point where we can see light at the end of the tunnel.

These session types map to Windows and POSIX targets in AWS, with runtime abstractions and cleanup applied to make both them "native as possible" to the way Framework operates Session objects.

This functionality provides pentesters with the tools required to show the impact of this cloud-native technology to the stakeholders responsible for things like qualifying data governance and locality, isolation, and AAA. Defense models predicated on network ingress/egress/gapping restrictions are bypassed by connecting to the target through the SSM API - not through the normal datapath used to commune with assets in the cloud. User-based access control within systems may be bypassed by the privileges those users have within IAM using the SSM account as an EOP pivot. Lastly, and rather importantly: data can be exfiltrated from systems which do not have network access outside of the cloud environment.

This functionality provides the control plane owner with root level access over all of their customer systems, including those which are competing with the vendor's own business interests.

lateral segmentation of resources in multidimensional environments is not enough - to ensure adherence to the access and privilege models of the interior plane, the control plane above it, and resource plane below it, must be properly segmented and maintain any interface at the minimum possible level of privilege if required.