Leave It to The Machine – A case study of the AWSSupportServiceRolePolicy incident analysis

By: Check Point CloudGuard research team (Omer Shliva, Omer Shmuelly and Guy Coldham)

Introduction

Gartner predicts that by 2025, 99% of cloud security issues will be a result of human error when configuring assets and security in the cloud.

Regardless of the security technologies we use, no matter how advanced they are – at the end of the day, human beings are the ones who are constantly making changes to cloud workload configurations. And humans, as we know, are prone to error, so unless the cloud security technologies we use take human error into consideration, cloud environments and assets will forever remain uncompliant within an organization and fall short of industry standards and best practices.

The evolving threat landscape and the increasing sophistication of attacks has demonstrated that bad actors are taking advantage of the lack of visibility in the cloud. They are also capitalizing on the challenges of remaining secure while using pre-configured tools and infrastructure when building cloud applications and environments.

In this post, we will explain why it’s important to transcend human risk management in the cloud by examining a recent cloud vulnerability discovery and detailing the scope of the potential threat. We will define the potential risk when relying upon human monitoring and contrast that with a parallel scenario where CloudGuard is in place and auto-discovers the vulnerability.

To help us understand the contrast between human and AI threat hunting, let’s consider the recent ‘AWSSupportServiceRolePolicy’ permission change security incident. While AWS had good measures in place preventing actual access to customer data in this particular scenario, this may not be the case with other providers or future incidents.

Therefore, it’s best that organizations have additional safeguards in place to ensure that permissions cannot be used to compromise data and assets, accidentally or maliciously.

Incident details:

On December 22, 2021, AWS deployed a new version (v20) of the AWS-managed policy ‘AWSSupportServiceRolePolicy’ that is used by the IAM Role ‘AWSServiceRoleForSupport’. The ‘AWSServiceRoleForSupport’ is a unique and mandatory service linked IAM Role, which trusts the support.amazonaws.com service to assume the role and perform actions on users’ behalf.

Snapshot 1: The ‘AWSSupportServiceRolePolicy’ policy version update

The ‘AWSSupportServiceRolePolicy’ and ‘AWSServiceRoleForSupport’ are used by AWS support teams to gather administrative information about their users’ AWS resources and to provide customer services as technical support. An AWS user cannot attach, detach, modify, or delete this role and policy.

In this new version, AWS added the ‘S3:getObject’ action to the policy, which potentially grants access to anyone who assumes the AWS service role for support.  Note: Within 10 hours, AWS reverted this change and made the previous version (v19) the default version for everyone.

Additional information by AWS on service-linked roles for AWS support can be found here.

In addition, please see the AWS Security Bulletin on the incident.

Companies should have full visibility into all of their cloud environments and assets to ensure data access permissions are not being granted by default, as they can compromise the security posture of their cloud. These kinds of changes to dynamic roles are made on a regular basis and are impossible to manually track. Therefore visualization, posture, and threat intelligence automated tools are needed because they understand the relationships between different assets in the cloud and can alert users accordingly.

Check Point CloudGuard CSPM (Cloud Security Posture Management) and Intelligence solutions provide prevention and threat hunting capabilities for this incident.

CloudGuard CSPM

From the CloudGuard CSPM product perspective, this incident can be prevented via four different domains:

• Logging
• Monitoring
• IAM Management (Limit access using bucket policies)
• Encryption and Key Management (S3 Bucket data encryption)

As best practice, it is recommended to use customer managed keys, instead of AWS managed keys. In this instance, using a customer managed key, prevents AWS services from reading your S3 stored data.

Check Point CloudGuard CSPM has a dedicated ruleset for S3 potential misconfiguration detection: AWS CloudGuard S3 Bucket Security, where customers can assess their Amazon S3 security posture.

Snapshot 2: CloudGuard CSPM ruleset: AWS CloudGuard S3 Bucket Security

The following sections outline all of the incident related CloudGuard CSPM rules, by their domains.

Logging

• AWS.LOG.05 – “Ensure S3 bucket access logging is enabled on the Cloud Trail S3 bucket”

CloudGuard auto-remediation bot_s3_enable_logging

• AWS.LOG.19 – “Ensure that object-level logging is enabled for S3 buckets”

Monitoring

• AWS.MON.22 – “Ensure a log metric filter and alarm exist for STS ‘AssumeRole’ action”

Identity and Access Management

• AWS.IAM.37 – “S3 bucket should not allow get actions from all principals”

CloudGuard auto-remediation bot_s3_limit_access, bot_s3_delete_permissions

• AWS.IAM.40 – “S3 bucket should not allow all actions from all principals”

CloudGuard auto-remediation bot_s3_limit_access, bot_s3_delete_permissions

• AWS.IAM.70 – “Ensure ‘AWSSupportServiceRolePolicy’ policy does not use ‘v20’ policy version”
• AWS.IAM.71 – “Ensure AWS IAM managed policies do not have ‘getObject’ or full S3 action permissions”

Encryption and Key Management

• AWS.CRY.03 – “Ensure that S3 Buckets are encrypted with CMK”

CloudGuard auto-remediation bot_s3_enable_encryption

CloudGuard Intelligence

CloudGuard Intelligence can detect API actions performed by any IAM Role in an AWS environment.

Once Intelligence receives logs from AWS CloudTrail, it will digest and enrich the logs to display them in the CloudGuard portal to be used as an Intrusion Detection System (IDS) and Threat Hunting tool.

Intelligence customers can and are advised to query their Account Activity logs to verify that they have not been impacted by this incident.

Simply, access the CloudGuard portal, go to the Events tab and click Account Activity. In the search bar use the GSL (Governance Specification Language) provided below. Make sure that the time frame includes December 22nd, 2021, and run the query on each of your onboarded AWS environments.

cloudtrail where event.name=’GetObject’ and issuer.name=’AWSServiceRoleForSupport’

Snapshot 3: CloudGuard Intelligence Account Activity GSL search

Using the GSL above, you may create an Intelligence rule that will alert you (using a notification or remediation of your choice) if this scenario occurs again. You may expand upon this rule to include additional alerts for sensitive actions.

If you require any assistance with creating such a rule, please contact Check Point Support for assistance.

Please Note: In order to ingest CloudTrail logs into CloudGuard Intelligence, your AWS environments must be onboarded to the platform, and have Data Events enabled on the Intelligence trail, at the time of the incident.

Remediation and Recommendations

Please find below a summary of our top recommendations associated with this incident:

• Make sure that the CloudGuard CSPM managed-ruleset “AWS CloudGuard S3 Bucket Security” is enabled.
• Using CloudGuard Intelligence, check if the action GetObject was performed by the AWSServiceRoleForSupport IAM Role.
• Where applicable, use strict S3 bucket access policies following the principle of least privilege. Never assign ‘*’ access policies to your resources.
• Ensure that your S3 Buckets are encrypted, preferably with customer managed keys.