New Research: The Urgent Threat of Ransomware to S3 Buckets

Overview

AWS S3 buckets are regarded as highly reliable, so have come to be used with great confidence. What most cloud security stakeholders don’t realize is that S3 buckets face a great security risk, from an unexpected source: identities. A compromised identity with a toxic combination of entitlements can easily perform ransomware on an organization’s data.

In recent research, we used the Ermetic analysis engine on a sampling of real environments to uncover toxic 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
• 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 very high potential for ransomware in organizations’ environments. Key findings included:

• Overall, every environment surveyed had identities with a risk factor as well as 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 and identities whose permissions allowed the exposed machines to perform ransomware
• Over 45% of the environments had third-party identities with the ability to perform ransomware by elevating their privileges to admin level (an astounding finding with potentially harmful implications far beyond ransomware that we will explore another time)
• 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

These findings, which focus on “smash and grab” operations involving a single, compromised identity, reveal a grave situation. In targeted campaigns, bad actors may move laterally to compromise multiple identities and use their combined permissions, greatly improving their ability to execute ransomware.

We provide here a brief review of the research and its findings, and outline several steps — to be expanded on in a separate post — that can help improve ransomware protection of your cloud environment. 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 the 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 than the business function required.
• The S3 buckets to which the identities had access were not protected by effective, out-of-the-box AWS features for mitigating the exposure
• 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-life cloud environments to discover all the identities with toxic permissions 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 Ermetic 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 KMS key used to encrypt it
• Denying access to the bucket using a bucket policy
• Denying access to the bucket using a key policy on a 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 implementing 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.

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 — you can read a related discussion in our post on TeamTNT malware. As per recommended best practice, we determined a risk factor to be access keys not rotated in 90 days. We determined an even more severe risk factor to be active access keys not 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 could assume IAM roles 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

The research findings were alarming: the exposure to ransomware is huge — and much greater than we expected.

Note, too, 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. It is likely that an attacker will seek to move laterally, compromising more than one identity and exploiting additional, less-straightforward risk factors to score an attack of much greater scope.

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

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 risk factor being public exposure to the internet. Moreover, the permissions that granted 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 available for third-party use that were allowed to elevate their privileges to admin. This finding is incredible — and pretty horrific for cloud security reasons beyond ransomware. With respect to this study, the finding means that the S3 buckets in the environment were exposed to ransomware.
• In over 95% (!) of environments, we found IAM users that met the above criteria, with the 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 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 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. The high possibility of exposure to even simple ransomware operations is a clear call to action for cloud security stakeholders to take mitigating steps.

Conclusion

Clearly, the situation is serious. Regarded as highly reliable, AWS S3 buckets are often the destination to which data is backed up. However, very little protects the data in S3 buckets from the identities that have permissions to control them. Once compromised, these identities can become the soft underbelly that puts organizations at substantial risk of ransomware exposure, with potentially enormous and costly impact to the business.

The cloud security risk of ransomware is only growing as perpetrators relentlessly pursue new ground to attack. 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 exposure of AWS S3 buckets and mitigating potential risk. These actions include:

• Implementing least privilege as a strategy – By designing and implementing a permissions strategy that allows the minimum entitlements needed for an identity to perform a business function, you dramatically reduce the potential of a malicious actor to be in a position 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 will explore these courses of action further in our next post. We also invite you to register for our upcoming Ransomware prevention webinar.

The post New Research: The Urgent Threat of Ransomware to S3 Buckets appeared first on Ermetic.

*** This is a Security Bloggers Network syndicated blog from Ermetic authored by Lior Zatlavi. Read the original post at: https://ermetic.com/blog/aws/new-research-the-urgent-threat-of-ransomware-to-s3-buckets/