AWS System Manager And The Dangers of Default Permissions

In September of 2018, Amazon Web Services (AWS) announced the addition of the Session Manager to the AWS Systems Manager. The session manager enables shell or remote desktop level access to your AWS EC2 Windows and Linux instances, along with other benefits. This is a great new feature, but care should be taken when enabling this capability. While the goal for many is immutable infrastructure deployed as code, there are often cases where monolithic legacy systems must still be manually tended to. Additionally, in many situations, debugging problems on a live machine is simply the easiest path forward. This brings up the question of how to securely give access to your cloud computing instances. Some users may choose to accept enhanced risk by opening virtual firewalls to allow internet connectivity to cloud assets. Others will accept the higher management overhead of using a bastion host with tighter controls. Now Session Manager gives a new option for shell access where a local console access is granted within your web browser when logged into the AWS management console. This can both drastically reduce your time to troubleshoot problems as well as increase security since the only point of access is the credentialed AWS console, which should be protected by multi-factor authentication. This single point for console access is managed by the centralized identity and access management (IAM) capabilities of AWS, including logging and auditing of sessions, all without needing to open network ports. In other words, using the new session manager is kind of a no-brainer. But just what are you agreeing to when you enable it?  The following is a real-world example of a permission mix-up that commonly occurs in the wild. You would probably start with the Session Manager Getting Started Guide. After installing prerequisites, by step 2, you’re on to configuring IAM permissions for your instances. You’ll notice the following instructions:

 “On the Attach policy page, select the check box next to AmazonEC2RoleforSSM, and then choose Attach policy.”

If you’ve got an eagle eye and thoroughly read all of the text, you may notice the following note concerning the AmazonEC2RoleforSSM managed policy :

“The policy AmazonEC2RoleforSSM provides wildcard (*) access to Amazon S3 buckets. We recommend that you review this policy and adjust if required.”

If like most people, you just start working on the instructions, then you have just enabled full access to all your S3 resources to each EC2 instance with Session Manager.  The relevant AmazonEC2RoleforSSM s3 privileges granted look like the following:

{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts",
"s3:ListBucket",
"s3:ListBucketMultipartUploads"
],
"Resource": "*"
}

You can see above that the AmazonEC2RoleforSSM pre-defined policy grants nearly all permissions, read and write, to the wildcard s3 resource. Amazon does provide instructions on creating a policy with the minimum needed permissions. The relevant s3 portion of the minimal policy looks like the following:

{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::aws-ssm-us-east-2/*",
"arn:aws:s3:::aws-windows-downloads-us-east-2/*",
"arn:aws:s3:::amazon-ssm-us-east-2/*",
"arn:aws:s3:::amazon-ssm-packages-us-east-2/*",
"arn:aws:s3:::us-east-2-birdwatcher-prod/*",
"arn:aws:s3:::patch-baseline-snapshot-us-east-2/*"
]
}

The minimum-needed permission is actually only read access on a few system manager-specific s3 buckets. This is far more restrictive than the default recommended role shown in the getting started guide. Anyone looking to follow the principle of least privilege will want to create a custom role with the minimal permission version given by Amazon. In the excitement to try new features, important notes on security may be overlooked, and it may be tempting to use the predefined role at any time in the future when you are no longer reading the Getting Started guide. In some cases, pre-defined roles may be adding risk in areas that seem completely disconnected from what you are trying to achieve. Each role used should be periodically checked to ensure that the principle of least privilege is being applied.