The Urgent Threat of Ransomware to S3 Buckets Due to Misconfigurations

Learn all about misconfigurations that can lead to S3 ransomware exposure and the mitigation tools you can leverage to prevent it.

Overview

Designed for high durability, AWS S3 buckets, when misconfigured, face a security risk. In the absence of effective mitigation controls enabled by the cloud customer, a compromised identity with a certain combination of entitlements can readily perform ransomware on the organization’s data.

In recent research, we used the Tenable Cloud Security analysis engine on a sampling of real environments to uncover scenarios in which all the following factors were true:

• An identity had a permissions combination that enabled it to perform ransomware.
• Effective mitigation features were not enabled on the S3 buckets to which the identity had access.
• Due to misconfiguration, the identity was exposed to one or more risk factors, such as public exposure to the internet, that could lead to its being compromised.

The study revealed high potential for ransomware in organizations’ environments. Key findings included:

• Overall, in every environment sampled, we found identities which, if compromised, could be used in executing ransomware. These identities were misconfigured with a risk factor and had the ability to perform ransomware on at least 90% of the buckets in an AWS account.
• Over 70% of the environments had machines publicly exposed to the internet that were linked to identities whose permissions allowed the exposed machines to perform ransomware.
• Over 45% of the environments had third-party identities with the ability to elevate their privileges to admin level; such elevation would entitle them to sufficient access to perform ransomware.
• Almost 80% of the environments had IAM users with enabled access keys that had not been used for 180 days or more, and that had the ability to perform ransomware.

Our research focused on “smash and grab” operations involving a single, compromised identity. In targeted campaigns, bad actors may move laterally to compromise multiple identities and use their combined permissions to increase access to resources, greatly improving their ability to execute ransomware.

We provide here a brief review of the research and its findings, and outline steps -- expounded on in a separate post -- that can help protect your cloud environment from ransomware exposure resulting from S3 bucket misconfiguration. We also invite you to read the full report.

Objective

The goal of our research was to find identities that met all the following criteria:

• Had a combination of permissions that enabled a misconfigured identity to perform ransomware on at least 90% of the buckets in a given AWS account. We specified 90% to focus on identities with extremely wide ransomware exposure. We also examined the permissions for excessiveness; i.e. if they allowed more access than the business function required.
• Had access to S3 buckets not protected by effective, out-of-the-box AWS features for mitigating the exposure.
• Due to misconfigurations, had one or more security risk factors that made them vulnerable to being compromised by a malicious actor. We looked for straightforward and preventable risk factors.

Methodology

Our research involved sampling real-world cloud environments to discover all the identities with relevant permission combinations, as well as reviewing the configurations of the potentially exposed S3 buckets and analyzing the security posture of the identities. While such assessments are near-impossible to carry out manually, we were able to automate the process using the Tenable cloud analytics platform to gather and compile the relevant configurations.

Permissions / Mitigations

We started by defining scenarios in which a malicious actor could successfully wage a ransomware campaign. We then translated those scenarios into the combinations of permissions that would make the attack possible, namely:

• Accessing the data and then discarding it using straightforward delete operations
• Accessing the data and then discarding it using lifecycle configuration rules
• Accessing the data and then discarding the (customer-managed) KMS key used to encrypt it
• Escalating privileges to the bucket by putting a bucket policy on it
• Denying access to the bucket using a key policy on a (customer-managed) KMS key used to encrypt the bucket
• Modifying ACLs to escalate privileges and gain access to the bucket

To amplify the existence of risk, for all scenarios we required inclusion of “s3:ListAllMyBuckets” -- which allows listing an account’s buckets -- as this permission makes a potential attack even easier.

We considered three AWS bucket mechanisms that can help mitigate the attack vectors: MFA Delete, Object Locks and Versioning. We also considered identities that are able to escalate their account privileges to the administrator level, such as IAM roles and IAM users, to be a threat to all buckets in an account. For an excellent review on privilege escalation in an AWS environment, see this Rhino Labs post.

The table below summarizes attack scenarios and the permissions combinations necessary to implement them; attack lag time, i.e. the time for an attack to become effective and during which, if the attack is detected, a response can be carried out; and the effectiveness of MFA delete, object locking or bucket versioning as mitigating actions.

For more details on the attack vectors, see the full research report.

(Table updated Oct 14, 2021 taking into account a fail-safe mechanism for removing S3 bucket policies by the root user) 

Identities’ security posture

We reviewed risk factors for identities. This involved looking for scenarios in which an identity that could perform ransomware was also somewhat likely to be compromised. To amplify the existence of risk, we zeroed in on risk factors that were straightforward to exploit and could be easily mitigated.

IAM users

The main risk factors for IAM users are derived from enabled access keys. As per recommended best practice, we determined a risk factor to be access keys that have not been rotated in 90 days. We determined an even more severe risk factor to be active access keys that have not been used in 180 days. We also considered IAM users that had console access without MFA enabled to be at risk.

As a matter of interest, we looked for users that were entirely inactive for 90 days or had credentials that were not used for 90 days; however, we did not consider such situations to be a risk factor.

IAM roles

We determined IAM roles to be at risk if allowed for use by a third party, as this puts the role beyond the organization’s control. We also looked for IAM roles that were inactive for more than 90 days (as per cloud security best practice, such roles should have been disabled); however, we did not consider such situations to be a risk factor.

EC2 Instances

We determined EC2 instances with public exposure to the internet to be a risk factor. This is because a malicious actor is much more likely to exploit an EC2 that is publicly available than one that is not.

EC2 instances gain access to resources in a cloud environment using IAM roles they are allowed to assume. For this reason, we looked for EC2s that had an IAM role enabled that allowed them to perform one of the permissions combinations in the above table and whose network configuration made them publicly available on the internet.

Results

As mentioned, we looked for identities that had the ability -- by means of their permissions, a lack of effective mitigation and, due to misconfiguration, exposure to a risk factor -- to perform ransomware on at least 90% of the S3 buckets in an AWS account of the AWS accounts we sampled.

Note that the findings indicate a malicious actor’s ability to perform a simple “smash and grab” operation: using one compromised identity to immediately perform ransomware. In fact, ransomware campaigns can be much more elaborate. By using lateral movement, an attacker could potentially access more than one identity and leverage other, less-straightforward risk factors to score an attack of even greater scope.

We summarize our findings here:

• Every environment we sampled had at least one AWS account in which an identity -- and often many more than one -- met the above criteria.
• In more than 70% of environments, we found EC2 instances that met the above criteria, with the configured risk factor being public exposure to the internet. Moreover, the permissions configurations granting access to the buckets were excessive. That is, the risk of these identities being compromised could have been significantly reduced without hurting business operations by simply removing the unnecessary permissions.
• In over 45% of environments, we found IAM roles configured for third-party use that were allowed to elevate their privileges to admin level, which would entitle them to sufficient access to perform ransomware on S3 buckets.
• In over 95% of environments, we found IAM users that met the above criteria, with the configured risk factor being access keys that were enabled but unrotated for 90 days.
• In almost 80% of environments, we found IAM users that met the above criteria, with the configured risk factor being access keys enabled but inactive for more than 180 days.
• In almost 60% of environments, we found IAM users that met the above criteria, with the configured risk factor being console access that was enabled but without a requirement to use MFA at login.
• Over 96% of environments had inactive IAM roles and almost 80% of environments had inactive IAM users that met the above criteria.

In short, if the sample we used is any indication, millions of enterprises currently using S3 as reliable data storage are in danger of ransomware attack due to misconfigurations. The high possibility of exposure to even simple ransomware operations is a call to action for cloud security stakeholders to take mitigating steps.

Conclusion

Regarded as highly reliable, AWS S3 buckets are often the destination to which data is backed up. However, S3 buckets, if misconfigured, can be at risk from identities with permission to access them that are themselves misconfigured and consequently compromised. As such, identities can become a soft underbelly that exposes the organization to ransomware risk, with potentially enormous and costly business impact.

With perpetrators of ransomware relentlessly pursuing new attack grounds, it is imperative that individuals responsible for securing cloud infrastructure know how to batten down their ransomware hatch.

We prescribe several strategic courses of action to protect your cloud environment from ransomware by reducing AWS S3 bucket exposure and mitigating misconfiguration risk. These actions include:

• Implementing least privilege as a strategy - By executing a permissions strategy of the minimum entitlements needed for an identity to perform a business function, you greatly reduce the potential of a malicious actor to be able to execute ransomware on buckets.
• Removing risk factors - By applying certain best practices, you can eliminate common misconfigurations that create the vulnerabilities that a ransomware actor can exploit to then compromise an identity and use its entitlements.
• Logging and monitoring - By logging and monitoring sensitive actions using tools such as CloudTrail and CloudWatch, you can identify events that are potential indicators of ransomware in progress and be able to execute a swift response.
• Preventing delete operations - By using effective, out-of-the-box AWS features/configurations for S3 buckets, such as MFA Delete or Object Locks, you can prevent malicious deletions.
• Replicating buckets - By configuring specific sensitive buckets to automatically back up their contents to a different, dedicated bucket, you can improve the data’s security on an ongoing basis.

We explore these courses of action further in a separate post.