In our previous post, we covered the mechanism of API access Into SOA/cloud Runtime by way of Amazon Web Services' SSM stack - an API linked to an agent running privileged within the customer workload and providing that access to anyone with relevant external IAM rights to connect/execute a command. One would think that if a savvy customer removed the SSM implant running within their instance, then the API's access into the runtime would be terminated by lack of any internal execution hook. While this is accurate in the sense that the SSM-specific killchain is broken, the cloud itself provides another path through the habitrail to reach instance-level control, through the API, without passing through the network stack of the instance at all: EC2 Instance Connect.
AWS' EC2 Instance Connect provides browser^SSH proxy to an interactive stream representing the virtual serial port of an IaaS instance. It is intended as a debug tool which connects someone from the WAN to the "hardware" serial port on the instance, bypassing all NACLs, providing a direct TTY, for everything from servers to virtual appliances and their vendor "access methods." The privilege for access is gated behind IAM, as with everything else, and thankfully the accessor still has to log into the system presuming it requires authentication for access on ttySX; but the pathway around so many common restrictions is there for attackers to use "to get to the next stage." Concurrently, InstanceConnect can be configured within the target system such as to permit SSH access via key-fetch from the IaaS' metadata service which does permit privileged access into the target instance by way of external API, though this is not as functionally universal as the bare "metal" access for serial consoles.
Debug functions are a favorite pathway for hackers/attackers to get a perspective of their target separate from that which the intended user will have and around which defense models stand. By introducing the ability to access serial debug, from the WAN, from any IP (tor exit node); the cloud has effectively given both testers and adversaries a well-lit runway to run down until they get to the next gate.
Making the case for this concern to stakeholders can be somewhat challenging - this class of concern is often termed as a "technical problem" making it easy to deprioritize into dismissal; until the concern can be shown in real-time. Access credentials are leaked all too often, and over-privilege is another quite common concern - leveraging either to show those in charge access to an otherwise inaccessible system can be a real eye-opener and turn the issue into a "business problem" which tends to get faster redress. From there, the "leap" to understanding what the cloud vendor can do with this tech is a little bit easier to make.
To enable such proof of threat model, for everyone, Semper Victus has published an AWS Instance Connect Session type for Metasploit and relevant scanner MetasploitModule to enumerate and connect to available instances in using the set of privileges available from the attacker's position (roles, assigned to systems, can be a huge benefit... to us, on red team, while pwning your stack).
At the time of this publication, the effort is still in PR; but with SSM cleared into master, it's only a short matter of time before everyone installing from packages or master branch will be able to leverage the tools.