OMIGOD – Is AWS next? 

Graham Thompson   ·   Thursday, October 14th, 2021

OMIGOD – Is AWS next? 

This entry comes as a result of two separate things that recently occurred. First, there was the OMIGOD vulnerability that was recently announced. I wrote an entry about that here. Then, the next day, a CCSK training student asked about performing the CCSK Plus labs if SSH is blocked. Apparently, their IT team recommended asking about using Session Manager or Instance Connect. These are two different ways aside from standard SSH to connect to a server in AWS. 

While testing, and OMIGOD still fresh in my memory, it dawned on me. That OMIGOD issue that Microsoft had is a ticking timebomb for AWS customers. Heck, it might be being used right now by insiders and you don’t even know it. That’s right folks, your cloud administrator is the most powerful person in your entire organization if you are using AWS. Here’s why… 

In the Microsoft Azure world, there is an OMI-based agent that gets installed on systems when you select log management services as well as other functionality. Unfortunately for Azure customers, a critical vulnerability was discovered and all hell broke loose. The OMI-based agent extends the metastructure into the applistructure. What do I mean by this? There are 4 tiers of the Cloud Security Alliance (CSA) logical model. The two I want to focus on are as follows: 

Metastructure: Defined on page 19 of the CSA Guidance (v4) as “The glue that ties the technologies and enables management and configuration”. What do they mean by technologies? Essentially, the ability to run your virtual assets in a provider’s physical environment. The metastructure is where you setup and manage your cloud. 

Applistructure: Defined on the same page of the guidance, the applistructure is known as “The applications deployed in the cloud and the underlying application services used to build them”. 

The issue that had everyone screaming at Microsoft Azure was there was a vulnerability in the OMI agent and people weren’t aware of its installation when you enabled a service that crosses the line between the metastructure and the applistructure. The agent allows for the metastructure to gain insights into what’s happening at the applistructure level. 

As far as the separation of roles and responsibilities go in a large company, it’s rather straight-forward, (or at least it should be). Cloud administrators are given the role and responsibility of managing the cloud environment, system administrators are assigned the role of maintaining the servers themselves. In other words, cloud admins are responsible for the metastructure, system administrators are responsible for the applistructure (a.k.a. servers running in the cloud). Of course, in a smaller environment, the administrative roles are likely performed by the same person. 

Yet nobody mentioned AWS does the exact same thing, only it’s worse. 

In the AWS world, there’s a service called Systems Manager. Systems Manager let’s you do all kinds of administrative tasks at the applistructure layer. Here are a few select items your cloud administrator can do at the applistructure layer via the Systems Manager service (explanatory writing is from AWS console pages for each service): 

Compliance Manager:  View compliance data by using the console or programmatic tools to quickly identify non-compliant instances on Amazon EC2 or on-premises servers and virtual machines. 

Patch Manager: Centralized management for patching your fleet of Amazon EC2 Windows and Linux instances or your on-premises servers and virtual machines. 

Run Command: Manage EC2 instances or on-premises servers and VMs in your data center at scale. 

Session Manager: Session Manager is a managed service that provides you with one-click secure access to your instances without the need to open inbound ports and manage bastion hosts. 

So what’s happening here? The lines between the Metastructure (cloud admins) and Applistructure (system admins) has been crossed. Well, what’s the big deal you say? You have to knowingly install the agents to allow this to happen, right? Nope. Surprise! The agent is pre-installed on many default Amazon Machine Images (AMI). Here’s the list of Quick Start AMIs the SSM agent is installed on by default: 

Impacted AMIs

Amazon Linux 

Amazon Linux 2 

Amazon Linux 2 ECS-Optimized Base AMIs 

Ubuntu Server 16.04, 18.04, and 20.04 

macOS 10.14.x (Mojave) 

macOS 10.15.x (Catalina) 

macOS 11.x (BigSur) 

Windows Server 2008-2012 R2 AMIs published in November 2016 or later 

Windows Server 2016 and 2019 

In other words, unless you are running Red Hat Enterprise, SUSE Linux or Debian AMIs, or have manually removed the SSM agents, you have this agent pre-installed. People were outraged that Microsoft would push an agent when a monitoring service was enabled, yet nobody talks about the SSM agent being pre-installed on about 90% of the instances used by companies today. I mean, who is going to validate that the SSM agent isn’t pre-installed by default? Very few I would imagine. 

Ok, so you might be rightfully asking yourself “what’s the potential damage here”? Well, the SSM agent runs as root on Linux or System on Windows instances. In other words, it runs as a God account on either platform. Your Access Control Lists are useless. With God power, the cloud administrator has complete access to everything on all of the server instances within the AWS environment. 

Doesn’t the cloud admin need some form of credential to access the servers? Aside from being able to access the SSM service page, there are no credentials required. You literally click “start session” and you’re in. 

What about the theory of AWS administrators accessing data on servers via this agent? It’s obviously possible, especially since it is their image after all. But, I would assume that Amazon has very strong controls in place to stop this from happening by rogue administrators. 

I wonder…What happens when a new server is launched after SSM is enabled with a single click? There is no role (a.k.a. instance profile) assigned to the new server. But, can the cloud admin change that? You bet! Add the role and bingo, after a few minutes, they now have unfettered access to everything in the server. I’ve included a high-level review of how you can recreate this test on your own later in this entry. 

I think it’s important to reiterate this is default behaviour in AWS. 

How to reduce the threat?

Here are 5 crazy tips you can use in addressing this threat: 

1) Review your need for System Manager Agent 

Do you even need SSM? You don’t need to secure something that doesn’t exist. Is removing, or even just disabling the SSM agent something you can do? Should you upload images that you are 100% in control of creating and testing? 

2) Who has access to SSM? 

Check to see what policies in use that have permission to use System Manager. Specifically, for the session manager service, check who has permission to invoke the ssm:startsession action.  

3) Who has the ability to add or change the IAM role (called instance profiles) assigned to servers? 

In order to use the session manger to access an instance, a role that allows connections must be applied. Power users do not have this level of access.   

4) What is your detection capability of someone using SSM? 

Cloudtrail will capture sessions created using session manager. Is this an item that you are monitoring for with Cloudwatch?  

5) Most importantly, do all users that have the ability to run SSM use MFA to access the management plane? More than ever, it is critical to protect privileged accounts as much as possible. Compromise of an administrative account not only can impact your cloud environment, but can lead to disclosure of all of the information stored on all the servers   

Test Performed: 

Test Steps taken (and a couple of prove it screenshots) 

1) Sign into an account where I’ve never touched the SSM service. 

2) Created a new Ubuntu 20.04 instance from Quick Start AMI (all defaults) 

3) Opened SSM. Clicked Quick Setup. 

4) Create New Configuration 

5) Select Host Management 

6) Keep default settings 

7) Click Create 

8) Go to session manager. Nothing there but link to learn more on using the service. 

9) Go back to ec2. Lo and behold, what do I see? This new server I just built is running with IAM role “AmazonSSMRoleForInstancesQuickSetup”. I didn’t create that role. Had no notice, nothing. 

10) Back to SSM. Open Session Manager. Server instance is now listed. 

11) Select server. Start session. Congrats! You are a God. Well, you’re ssm-user, but that user can switch to root at anytime, as shown in the following screenshot: