BACKGROUND:
New research from Ermetic The Urgent Threat of Ransomware to S3 Buckets. Researchers detail how compromised identities could easily deliver ransomware into the system.
Here’s the overview of the research.
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.
<p>Identities are the source most hacks. Though clearly stated in every security guidance that enterprise should follow, PR.AC-6 from the NIST Cybersecurity Framework – \"The Principle of Least Privilege\" – is often overlooked. </p>
<p>Identity admins are often cajoled, persuaded or forced to add permission to new users, groups and roles – without proper governance. Worse, these privileges are rarely de-escalated, thus they add to the phenomenon of \"privilege groups\" where user and system accounts accumulate too much privilege and so leave an enterprise exposed to an identity attack. </p>
<p>Once an attacker obtains a user credential, they will attempt to navigate the enterprise for valued resources, e.g. lateral movement. The more permissions the user has the more data and resources he can target. Of course, S3 data with its valued store of PII (Personal Identifiable Information) and PHI (Personal HealthCare Information) is always going to be a prime target.</p>
<p>Immediately, enterprises should be conducting the prescribed amount of identity access reviews according to the guidance they are under, and increase the frequency of these reviews to once a month for identities securing secure data. Triggers on identity privilege changes should also be monitored with alerts to the appropriate security and data personnel.</p>
<p>There is a shared responsibility model when an organization embarks to do business on the cloud, and more so with IaaS. Thus it is important to understand who is responsible for what because assumptions can lead to breaches. S3 buckets are known for being durable – readily available – storage and secure by default. Thus S3 buckets are heavily used in a myriad of ways, from applications storing data, including sensitive data, to systems storing logs. Subsequently, S3 buckets are troves that contain enriched data and are highly sought by adversaries.</p>
<p>We know ransomware attacks have been, and will likely continue to be, a top successful weapon for cybercriminals. The focus of these attacks often transpires locally, for example, local storage on computers and media. Knowing that storage is the target of ransomware, S3 is another storage device. And here one should anticipate – it is not a matter of if but when – that our adversaries are scheming to do the same on S3. </p>
<p>Now going back to the shared responsibility model. Here it is vitally important for cloud consumers to understand what their CSP (Cloud Service Providers) are doing to safeguard storage, i.e.: S3 buckets, as well as what measures customers need to implement to collaboratively protect storage in the cloud. Do not assume that security in the cloud is the sole responsibility of CSPs. That assumption will likely lead to a breach.</p>
<p>In my opinion this “research” is a chicken little story. It’s well known that any digital asset exposed to the Internet, improperly configured, is susceptible to a multitude of attacks including ransomware. Have there been security breaches related to AWS S3 buckets? Absolutely. The majority of which resulting from misconfigurations.</p>
<p>There’s a reason why AWS architecture prescribes multiple layers, including web logic (the part the user sees), business or application logic (the part where decisions are made regarding the user request), and data logic (where the information is stored). S3 buckets are separated at the forward edge of the technology stack and are specifically designed to isolate the primary layers.</p>
<p>A well architected AWS environment should not cause business operations to cease due to an attack on a S3 bucket. There are a multitude of controls, alarms, and versioning which can help to recover from an S3 bucket compromise. Not the least of which is having multiple buckets. That’s the whole point behind cloud computing, it’s elastic and resilient.</p>
<p>If you study their report, you will see most of the mitigating controls we’re not in place. In other words, if I leave my house and forget to lock the door, of course it could be broken into. So, I fail to see the validity of the testing.</p>
<p>With regards to their reference to Identity and Access Management (IAM) vulnerabilities, to their own admission, their testing is based upon the assumption medicating controls are not in place. Also, not a valid test.</p>