Skip to content

Latest commit

 

History

History
592 lines (522 loc) · 31.3 KB

README.md

File metadata and controls

592 lines (522 loc) · 31.3 KB
Raw

This repo has been replaced by https://www.cloudvulndb.org/

Please report new security mistakes to https://www.cloudvulndb.org/

Cloud Service Provider security mistakes

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). I'm not including WAF bypasses as WAFs are inherently bypassable.

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.

Concern has been raised that AWS restricts what they allow to be pentested (their guidance and historic guidance) and has no bug bounty which are believed by some to limit the issues that become public with AWS.

Similar work

  • Alon Schindel and Shir Tamari from Wiz.io have been advocating for the desire for a cloud vulnerability database through their blog post, Slack forum (linked from their blog post), and Black Hat talk.
  • Christophe Parisel has described a concept called Piercing Index for classifying the impact of cloud provider vulnerabilities.

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

GCP Default compute account is project Editor

  • Summary: When the compute API is enabled on a GCP Project, the default compute account is created. This account gets the primitive role Editor assigned by default, which allows for a wide variety of privilege excalation and resource abuse in the project. Especially, all new VMs created inherit this permissions by default. This issue is arguably a technical decision by GCP, but the documents advise customers to undo this.
  • Platform: GCP
  • Severity: Medium
  • Date: Since the creation of GCP
  • Customer action: Remove these permissions, it can be done via an organization policy
  • References:

AWS: Signature version 1 (SigV1) is insecure

  • Summary: When making authenticated API requests to AWS, the requests must be signed with your AWS access key. The initial signing algorithm, SigV1, was vulnerable to collisions. A person-in-the-middle attack would be able to modify signed requests via specially constructed collisions.
  • Platform: AWS
  • Severity: Medium
  • Date: until December 18th, 2008
  • Discoverer: Colin Percival
  • Customer action: N/A, SigV1 is deprecated at this point
  • References:

AWS: AWS published official AMIs with recoverable deleted files

  • Summary: Researchers, while investigating the security posture of Public AMIs, were able to undelete files from an official image that was published by Amazon AWS.
  • Platform: AWS
  • Severity: Low
  • Date: June, 2011
  • Discoverer: Marco Balduzzi, Jonas Zaddach, Davide Balzarotti, Engin Kirda, Sergio Loureiro
  • Customer action: Follow best practices when sharing Public AMIs
  • References:

AWS: AssumeRole vendor issues with confused deputy

AWS: Bypasses in IAM policies and over-privileged

AWS: Launching EC2s did not require specifying AMI owner: CVE-2018-15869

  • Summary: Attackers had put malicious AMIs in the marketplace to abuse the CLI's way of selecting what AMI to use. Although the concept of planting malicious AMIs had existed for a while (ex. in the 2009 presentation "Clobbering the clouds" by Nicholas Arvanitis, Marco Slaviero, and Haroon Meer) it had not been used specifically to target this issue with the CLI.
  • Platform: AWS
  • Severity: Medium
  • Date: August 13, 2018
  • Discoverer: Megan Marsh (https://github.com/SwampDragons)
  • Customer action: Update CLI and other tools that create EC2s
  • References:

AWS: Resource policy confused deputy issue with services

Azure: Cloudshell terminal escape

  • Summary: If attacker controlled data is viewed in Cloudshell it could have led to code execution.
  • Platform: Azure
  • Severity: Medium
  • Date: January 9, 2019
  • Discoverer: Felix Wilhelm, Google
  • Customer action: N/A
  • References:

AWS: VPC Hosted Zones unauditable

AWS: ALB HTTP request smuggling

AWS: AWS employee posts confidential AWS data, including possibly customer access keys and other customer information

GCP: AI Hub Jupyter Notebook instance CSRF

AWS: GuardDuty detection bypass via cloudtrail:PutEventSelectors

GCP and AWS: GKE CAP_NET_RAW metadata service MITM root privilege escalation

  • Summary: An attacker gaining access to a hostNetwork=true container with CAP_NET_RAW capability can listen to all the traffic going through the host and inject arbitrary traffic, allowing to tamper with most unencrypted traffic (HTTP, DNS, DHCP, ...), and disrupt encrypted traffic. In GKE the host queries the metadata service at http://169.254.169.254 to get information, including the authorized ssh keys. By manipulating the metadata service responses, injecting our own ssh key, it is possible to gain root privilege on the host.
  • Platform: Azure
  • Severity: Medium
  • Date: June 15, 2020
  • Discoverer: Etienne Champetier
  • Customer action: N/A
  • References:

AWS: XSS on EC2 web console

AWS: S3 Crypto SDK vulns: CVE-2020-8912 and CVE-2020-8911

AWS: Terms and conditions allows sharing customer data

AWS: Execution in CloudFormation service account

AWS: CloudFormation denial of service (in a single account)

AWS: Identification of privileges without being logged by CloudTrail

AWS: Timing attack with Lambda and CloudWatch Synthetics

AWS: CloudFormer review

GCP: DHCP abuse for code exec

  • Summary: Under certain conditions (which I don't entirely understand), an attacker can flood DHCP packets to the victim VM, allowing it to impersonate the Metadata server, and grant themself SSH access.
  • Platform: GCP
  • Severity: Medium
  • Date: September 26, 2020
  • Discoverer: Imre Rad
  • Customer action: N/A
  • References:

AWS: Encryption SDK issues

AWS: S3 bucket tagging not restricted

GCP: Exfiltrate data via the logs of GCP Org policy

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.
  • Platform: AWS
  • Severity: Low
  • Date: October 15, 2020
  • Customer action: N/A
  • References:

AWS: Route table modification to imitate metadata service

AWS: Fall 2020, SOC 2 Type 2 failure

AWS: Cloudshell terminal escape

GCP: Org policies bypass

AWS: XSS in web console

AWS: Lightsail object storage access keys logged

Azure: ChaosDB

Azure: Azurescape

  • Summary: Cross-account container escape
  • Platform: Azure
  • Severity: Critical
  • Date: September 9, 2021
  • Discoverer: Yuval Avrahami, Palo Alto
  • Customer action: "revoking any privileged credentials that were deployed to the platform before Aug. 31, 2021, and checking their access logs for irregularities."
  • References:

AWS: BreakingFormation

Azure: Log analytics role privesc

Azure: OMIGOD

GCP IAP bypass

  • 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).
  • Platform: GCP
  • Severity: Medium
  • Date: September 17, 2021
  • Discoverer: Unknown
  • Customer action: N/A
  • References:

AWS Workspace client RCE - CVE-2021-38112

  • 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.
  • Platform: AWS
  • Severity: High
  • Date: September 21, 2021
  • Discoverer: David Yesland, Rhino security
  • Customer action: Update client to 3.1.9 or higher
  • References:

AWS: SuperGlue

Azure Active Directory information disclosure vulnerability (CVE-2021-42306)

AWS API Gateway HTTP header smuggling

  • Summary: A flaw in AWS API Gateway enabled hiding HTTP request headers. Tampering with HTTP requests visibility enabled bypassing IP restrictions, cache poisoning and request smuggling.
  • Platform: AWS
  • Severity: Low
  • Date: November 10, 2021
  • Discoverer: Daniel Thatcher, intruder.io
  • Customer action: N/A
  • References:

AWS Fall 2021, SOC 2 Type 2 failure

AWS SageMaker Jupyter Notebook instance CSRF

  • 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. This issue is identical to GCP's issue from a year earlier.
  • Platform: AWS
  • Severity: Medium
  • Date: December 2, 2021
  • Discoverer: Gafnit Amiga, Lightspin
  • Customer action: N/A
  • References:

Azure: AutoWarp

  • Summary: An exposed endpoint in the Azure Automation Service allowed to steal Azure API credentials from other customers
  • Platform: Azure
  • Severity: Critical
  • Date: December 6, 2021
  • Discoverer: Yanir Tsarimi, Orca
  • Customer action: N/A. As a general practice, use the least-privilege principle, including on managed identities assigned to automation accounts. While this would not have prevented the leakage of API credentials, it would have reduced the blast radius.
  • References:

AWS RDS local file read

AWS: Log4Shell Hot Patch Vulnerable to Container Escape and Privilege Escalation

Azure NotLegit: App Service vulnerability exposed source code repositories

AWS: Overprivileged AWS Support IAM Role Policy

Azure: Synlapse: CVE-2022-29972

Azure ExtraReplica: Cross-account database vulnerability in Azure PostgreSQL

AWS: CVE-2022-25165: Privilege Escalation to SYSTEM in AWS VPN Client