Ransomware is on the rise and there are multiple different techniques to cloud-native ransomware. One theme of ransomware is to hold data hostage where it cannot be properly used and one way to do so is to encrypt or re-encrypt cloud data resources with an encryption key that is controlled by the attacker. To formulate a strategy for defense, understanding the IAM actions related to encryption updates is paramount. Most actions and updates in cloud and AWS are tied to AWS IAM actions.  Additionally, these actions and updates can be prevented by proper IAM strategies with deny policies such as SCPs (Service Control Policies) or Permission Boundaries and then monitored through logging in AWS CloudTrail.

Most cloud ransomware attacks require one of the following:

• Removing data access by re-encrypting or encrypting data.
• Removing data access by deleting data resources.

We'll focus on the first use case: when data is re-encrypted or encrypted. From a non-ransomware perspective, there are additional use cases for needing to change and manage encryption on cloud resources too.

However, these actions are not under the kms service prefix (actions such as kms:PutKeyPolicy or kms:CreateGrant ) but rather under each service prefix such as s3, dynamodb, or secretsmanager for example. Thus, we conducted research on the IAM permissions necessary and how to update encryption settings on AWS resources. We found the following numbers across 65 resources over 45 AWS services:

• 24 resources across 18 services (36.92%) had support for updating encryption via IAM methods.
  • 7 of those 24 resources had atomic IAM actions that only updated encryption such as xray:PutEncryptionConfig and logs:AssociateKMSKey.
  • The other 17 of those 24 resources were non-atomic IAM actions such as dynamoDB:UpdateTable and sns:SetTopicAttributes.
• 41 resources across 27 services (63.08%) could not have encryption updated and would need to be recreated.

This research can be found on our GItHub repository here: https://github.com/FogSecurity/aws-kms-encryption-iam/tree/main

Additional statistics:

• 75% of encryption update methods had no mention of encryption keywords (encryption, kms, etc).
• 8.33% methods were classified as "Permissions Management" while the other 91.67% were classified as "Write".
• There are 7 distinct action verbs across the update permissions that can lead to complexity. (Update, Set, Put, Modify)

Methodology and AWS Service Coverage

Previously, we did research on encryption in AWS and whether AWS resources were encrypted or unencrypted by default. Our research covered popular and important data resources and infrastructure resources.  We started with that resource list and expanded our coverage to 65 resources over 45 AWS services (default encryption coverage of 51 resources over 43 AWS services in our encrypted by default research).

Impact

There are both nefarious and good reasons for needing to change and manage encryption on cloud resources.  These scenarios (and some are examples from people we've had conversations with and interviewed):

Reasons to Update Encryption

• Update to security guardrails that require changes to different encryption keys.
• Switching encryption from types of encryption keys such as to CMKs from AWS Owned or AWS Managed.
• Standard maintenance or update of application and data encryption.
• Data ownership team change.

Misconfiguration

A common cause of cloud security incidents is misconfiguration. Changing the encryption key of cloud resources can lead to accidental loss of access to data if access to the encryption key is not configured correctly or if the encryption key is deleted.

Ransomware

One attack vector and technique of ransomware is to change the encryption key to a key that is managed or controlled by the threat actor. From there, the threat actor can hold the data ransom and block access to data. This is documented by other security firms as well, including Palo Alto Networks here. In this post, we'll focus on how a threat actor can update encryption from a benign key (owned by the data owner) to a key owned by the threat actor (and thus a malicious action of updating encryption).

Categorization of Updating Encryption on Existing Resources in AWS

We created the following taxonomy for encryption updates in AWS:

Resources that must be recreated (No Update)

The following chart covers 41 resources across 27 services and can be found at our GitHub here:

Resources that can be updated

• Atomic IAM Actions for updating encryption.
• Non-Atomic IAM Actions for updating encryption.

Resources that do not support encryption

This is a shorter list and includes String and StringList Parameters in SSM Parameter Store.

Our Findings

75% of encryption update methods had no mention of encryption. Often, these were vague descriptions.

We found that out of the 24 resources, only 6 resource encryption update methods referenced encryption or KMS.  That's only 25% of IAM methods that clearly reference updating encryption on resources. The IAM descriptions provided by AWS were vague.  In order for us to determine how to update encryption, we needed to dig deep into documentation and test IAM actions in AWS.

Example: dynamodb:UpdateTable's description is Grants permission to modify the provisioned throughput settings, global secondary indexes, or DynamoDB Streams settings for a given table and does not mention encryption.

These vague descriptions make it difficult to properly configure permissions and understand potential impact of IAM actions on data security.

Differing Classification of Permissions

2 of those 24 encryption update IAM methods (sns:SetTopicAttributes and xray:PutEncryptionConfig) were classified as Permissions Management, while all others were classified as Write actions.

• 8.33% methods were classified as "Permissions Management" while the other 91.67% were classified as "Write".

This can lead to IAM configuration challenges as some security teams may audit permissions based on access level groupings. AWS provides List, Read, Write, Permissions Management, and Tagging groupings to help with granting least privilege.

Inconsistent Naming

Naming consistency for IAM was inconsistent at least - from the "action" verb to naming. There are 7 distinct "action" verbs in the IAM actions: Update, Set, Modify, Put, Alter, Associate, and Start..

• Examples of IAM actions to update encryption configuration are logs:AssociateKMSKey and xray:PutEncryptionConfig
• Example of IAM actions to update configuration are es:UpdateDomainConfig and sns:SetTopicAttributes.

Conclusion

Cloud Identity and Access Management is complex and there are nuances and inconsistencies with managing encryption and data access. At Fog Security, we help customers secure their cloud data.  We believe by understanding identity and by securing cloud encryption, we can build better data security. If there's interest in further conversations and/or cloud data permission audits, reach out to us at info@fogsecurity.io.

Defense

We suggest the following:

• Practicing Least Privilege with Data Resource Access and Management

While many of the permissions to update data resources may seem necessary for standard operations, we recommend practicing least privilege with encryption keys and data permissions.  Given the lack of atomic KMS actions, blocking encryption updates via advanced IAM policies in AWS such as Service Control Policies (SCPs) may not be a viable option.

• Practice Least Privilege with Encryption Key Management

WIth KMS in AWS, restricting management activities to KMS keys in AWS such as the ability to Schedule Key Deletion (kms:ScheduleKeyDeletion ) or updates to the KMS Key policy all fall under the kms service prefix and should be restricted appropriately. We also recommend ensuring proper access to avoid key lockout.

• Monitoring for KMS and encryption changes

We recommend monitoring for encryption updates and key changes with resources.

Timeline and References

• In 2019, Amazon DynamoDB added support for switching encryption keys.
• AWS Documentation: Managing encrypted tables in DynamoDB
• AWS Documentation: RDS Encryption Limitations

‍