This page lists security mistakes by cloud service providers (AWS, GCP, and Azure). These are public mistakes on the cloud providers' side of the shared responsibility model. This may be CVEs or bug bounties for issues in the services they run, but could also be in client software they provide, guidance they have given, failed audit tests in their SOC 2 Type 2, security incidents they have had, and more.
Whether an issue is included or not is hard to define and thus opinionated. For my definition of a mistake, I am generally not including business decisions such as AWS releasing a service before it has Cloudtrail auditing support, or some technical decisions by the cloud providers such as the ease with which an S3 bucket can be made public. Some technical decisions are concerning enough to be listed here though. I'm avoiding GSuite and Office365 issues, or issues that are not specifically cloud issues (ex. Active Directory issues unless it specifically impacts Azure AD). I am not including security incidents at the companies that did not seem to impact the cloud services for customers (ex. when Amazon's Twitch was hacked, it didn't impact AWS customers), or security incidents of their customers (ex. Capital One's breach on AWS).
The purpose of this project is to ensure there is a record of these mistakes. Although I believe using cloud providers is often a much better decision than self-hosting, it's important to hold them accountable by recognizing their security mistakes.
Where possible I also want to ensure customers know what steps they can take to detect or prevent the issues identified. Mitre, which is the organization that manages CVEs, has generally avoided providing CVEs for security issues of the cloud providers under the assumption that all issues can be resolved by the cloud provider and therefore do not need a tracking number. This view is sometimes incorrect, and even when the issue can be resolved by the cloud provider, I still believe it warrants having a record. Similar views are expanded on by Alon Schindel and Shir Tamari from Wiz.io in their post Security industry call to action: we need a cloud vulnerability database.
Field explanations
Name: Name of the vulnerability if available, or a short explanation
Summary: Explanation of the issue
Platform: cloud provider (AWS, GCP, or Azure)
Severity: My opinion of how bad this is, in relation to other issues on this page.
Date: Date this was discovered or published if unknown. The actual date where this impacted customers may have been much earlier, and the date it was published, or fixed may be much later. This is just to give this list some sort of ordering.
Discoverer: Individuals who found the issue and where they worked at the time
Customer action: Whether there is anything a customer could do as follow-up to this issue.
References: Publication of the research and response from the cloud provider if it exists.
Issues
AWS: Penetration testing policy forbids research into services and infrastructure
Summary: AWS's penetration testing policy forbids research into AWS services and AWS infrastructure.
AWS: Resource policy confused deputy issue with services
Summary: Resource policies lacked a way of restricting service access to only your own account, allowing an attacker to leverage a service to potentially access your resources. Originally discovered by Dan Peebles and presented at re:Invent in 2018, this issue did not gain enough attention to be fixed until Shir Tamari and Ami Luttwak from Wiz presented it at Black Hat 2021.
Platform: AWS
Severity: Low
Date: November 28, 2018
Discoverer: Dan Peebles, Bridgewater
Customer action: Update vulnerable IAM policies (add scoping condition)
Summary: AI Hub Jupyter Notebook server lacked a check of the Origin header that led to a CSRF vulnerability. An attacker could have read sensitive data and execute arbitrary actions in customer environments.
AWS: GuardDuty detection bypass via cloudtrail:PutEventSelectors
Summary: GuardDuty detects CloudTrail being disabled, but did not detect if you filtered out all events from CloudTrail, resulting in defenders having no logs to review. Require privileged access in victim account, resulting in limited visibility.
Platform: AWS
Severity: Low
Date: April 23, 2020
Discoverer: Spencer Gietzen, Rhino Security
Customer action: Setup detections independent of GuardDuty
AWS: Lack of internal change controls for IAM managed policies
Summary: Repeated examples of AWS releasing or changing IAM policies they obviously shouldn't have (CheesepuffsServiceRolePolicy, AWSServiceRoleForThorInternalDevPolicy, AWSCodeArtifactReadOnlyAccess.json, AmazonCirrusGammaRoleForInstaller). The worst being the ReadOnlyAccess policy having almost all privileges removed and unexpected ones added.
AWS: Terms and conditions allows sharing customer data
Summary: Use of the AI services on AWS allows customer data to be moved outside of the regions it is used in and potentially shared with third-parties.
AWS: Identification of privileges without being logged by CloudTrail
Summary: An attacker could figure out what privileges they have in a victim account, without being logged in CloudTrail. It took AWS over 273 days to fix this.
Summary: Allows an attacker with privileges in the account to share resources outside of the account even when an org policy restricts this, thus enabling them to backdoor their access.
Summary: Azure forces the install of an agent on Linux VMs, which contained a vuln that would grant root RCE if an attacker could send a web request to them
Platform: Azure
Severity: Critical
Date: September 14, 2021
Discoverer: Nir Ohfeld, Wiz.io
Customer action: N/A, client needed to be auto-updated
Summary: Convincing a victim to click a specially crafted link would allow the attacker to bypass the Identity-Aware Proxy (a core component of BeyondCorp).
Summary: If a user with AWS WorkSpaces 3.0.10-3.1.8 installed visits a page in their web browser with attacker controlled content, the attacker can get zero click RCE under common circumstances.
Azure Active Directory information disclosure vulnerability (CVE-2021-42306)
Summary: Automation Account “Run as” credentials (PFX certificates) were being stored in cleartext, in Azure Active Directory (AAD). These credentials were available to anyone with the ability to read information about App Registrations (typically most AAD users).
Summary: AWS SageMaker Notebook server lacked a check of the Origin header that led to a CSRF vulnerability. An attacker could have read sensitive data and execute arbitrary actions in customer environments.