Azure Active Directory Seamless Single Sign-On feature allowed single-factor brute-force attacks
against Azure AD without generating sign-in events in the targeted organization’s tenant.


Azure AD Seamless SSO logging bypass

Emilien Socchi

Azure Cognitive Search (ACS) is a full-text search engine service.
A new non-default feature allowed for a network control to bypassed, permitting an attacker to submit search queries to any other tenant's network-isolated ACS instance. However, abusing this required a valid API key 
to access the data plane of the target, along with a number of pieces of information about the target environment (such as the subscription ID and the name of the index to query).


ACSESSED

Ian Duffy

Full administrative access to the Azure Red Hat Enterprise Linux Appliance REST API was publicly exposed.
It allowed malicious actors uploading packages that would be acquired by client virtual machines on their next yum update. 
The vulnerable infrastructure supplies all the packages for all Red Hat Enterprise Linux instances booted from the Azure marketplace.


Public admin access to Azure's Red Hat Update Infrastructure

s1r1us

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.


AI Hub Jupyter Notebook instance CSRF

James Kettle (Portswigger), Arkadiy Tetelman (Chime)

ALBs found vulnerable to HTTP request smuggling (desync attack).


ALB HTTP request smuggling

Marco Balduzzi, Jonas Zaddach, Davide Balzarotti, Engin Kirda, Sergio Loureiro

Researchers, while investigating the security posture of Public AMIs, were
able to undelete files from an official image that was published by Amazon AWS.


AWS published official AMIs with recoverable deleted files

Liv Matan

Azure API Management is an API gateway service meant to help organizations to create, manage, secure,
and monitor APIs across all of their environments. Researchers found three high severity vulnerabilities
in the service, two of which are SSRF (Server Side Request Forgery) vulnerabilities, and the third is a
path traversal bug. The SSRF flaws affected the Azure API Management CORS proxy (which handles schema
retrieval) and hosting proxy (which routes API requests to the correct server). An attacker successful
in exploiting each of these SSRF vulnerabilities could fake requests from these legitimate servers and
thereby gain access to internal Azure services. However, the researchers did not determine the effective
impact of this access level, and it's therefore possible that Azure had security measures in place which
would have blocked further lateral movement. The path-traversal vulnerability allowed for an unrestricted
file upload to the Azure developer portal server. The portal's authenticated mode allows users to upload
static files and images to be displayed within the portal website, but this vulnerability could have allowed
an attacker to upload code instead, and then potentially execute it on the server itself.


API Management SSRF and path traversal vulnerabilities

Lidor Ben Shitrit

By misusing the Apiary web service and taking advantage of Apiary's use of IMDSv1,
a remote attacker is able to retrieve sensitive information from various endpoints
and use it to gain more access and sensitive data of other hosts in the same environment.


Oracle Apiary SSRF

Nick Frichette

The API action ListObservabilityConfigurationsForAccount did not properly validate the 
"AccountId" parameter that was passed to it. As a result, any account ID could be provided 
and the API would return the information for that account. This would leak minor information
about the observability configuration for App Runner in the account.


App Runner cross-tenant observability config info leak

The API action ListVpcConnectorsForAccount did not properly validate the "AccountId" parameter
that was passed to it. As a result, any account ID could be provided and the API would return
the information for that account. This would leak minor information about the VPC 
configuration for App Runner in the account including the subnet ID, security group ID, and the
VPC Connector ARN.


App Runner cross-tenant VPC connectors info leak

Jackson Reid

Asset Key Thief was a Google Cloud 
privilege escalation vulnerability that enabled 
principals with the "Cloud Asset Viewer" role (or other roles 
with the `cloudasset.assets.searchAllResources` permission) on the 
Cloud Asset Inventory API, at the Project, Folder, or Organization level 
to view and exfiltrate any user-managed Service Account 
private key under a project within the same Google Cloud environment that 
had been created or rotated up to a maximum of 12 hours ago. 
Access to Service Account private keys enable the full assumption 
of that Service Account's identity and privileges, which would have given 
attackers with existing access to a Google Cloud environment a persistent and reliable
method of lateral movement and privilege escalation. Google has since fixed this 
vulnerability, but affected customers must rotate their keys manually.


Asset Key Thief

Daniel Grzelak

3rd party vendors can (and sometimes do) incorrectly implement sts:ExternalId in their
AWS role trust policies, leading to confused deputy issues. These misconfigurations could
allow customers to access other customers' data. Although vendors are responsible for
ensuring their own configurations are correct, AWS could theoretically add mitigations
to prevent and detect this issue.


3rd party vendor confused deputy via AssumeRole

Elad Gabay

Any unattached storage volume, or attached storage volumes allowing multi-attachment,
could have been read from or written to as long as an attacker knew their Oracle Cloud Identifier (OCID),
allowing sensitive data to be exfiltrated or even more impactful attacks to be initiated via
executable file manipulation in the target tenant's environment.


AttachMe

Yanir Tsarimi

An exposed endpoint in the Azure Automation Service allowed to steal Azure
API credentials from other customers


AutoWarp

Daniel Thatcher

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.


AWS API Gateway HTTP header smuggling

The AWS AppSync service could be coerced to assume arbitrary roles in
other customers' accounts which trusted the AppSync service. This was
due to insufficient validation of a serviceRoleArn parameter (caused by
a case-sensitivity parsing issue). With this vulnerability, if an adversary
knew the ARN of the role associated with AppSync in the target account,
they could use it invoke arbitrary AWS API calls.


AWS AppSync confused deputy via ServiceRoleArn

Felix Wilhelm

Amazon Elastic Kubernetes Service (EKS) uses IAM to provide authentication to the cluster
through the AWS IAM Authenticator for Kubernetes (aws-iam-authenticator). Multiple issues
were identified in the authenticator that could have allowed exploitation, namely (1) a
lax regular expression used to verify presigned URLs; (2) HTTP client redirect follow
(due to using Golang HTTP client in its default configuration); (3) use of the Golang URL.Query
function (which silently drops parameters that Go considers invalid, rather than raising
an error and rejecting invalid tokens); and (4) no verification that the cluster uses Go
versions newer than 1.12 (as older versions are vulnerable to request smuggling).


Multiple issues in AWS IAM Authenticator for Kubernetes

If attacker controlled data is viewed in Cloudshell it could have led to
code execution. This exact same issue existed in Azure previously.


AWS CloudShell terminal escape

Will Deane

For AWS CodeBuild, when using a custom container image stored in ECR and the 
project service role for the credentials to pull the image, the default IAM 
policy attached to the role to allow pulling the container was over-privileged 
and allowed the CodeBuild container to overwrite its own build image. 
An attacker with the ability to read the container credentials from the meta-data 
service or run commands within the container could thereby overwrite the container to gain 
persistence within the CodeBuild project.


Overprivileged CodeBuild default ECR IAM policy

Spencer Gietzen

The AWS CodeStar service had an undocumented API (codestar:CreateProjectFromTemplate) that allowed
users with broadly-scoped CodeStar permissions to create a CodeStar project. As part of the creation
process, AWS would create a new CodeStarWorker IAM policy & attach it to the user making the call.
This policy granted full access to over 50 AWS services, including iam:AttachRolePolicy, iam:AttachUserPolicy and iam:PutRolePolicy permissions,
which would allow the user to escalate to full administrator access. Following disclosure, AWS removed
the majority of access granted by the CodeStarWorker policy, but this is still a viable escalation path if
there are other misconfigurations in the environment.


IAM privilege escalation via undocumented CodeStar API

Christophe Tafani-Dereeper

AWS applies a rate limit to authentication requests made to the AWS Console
in an effort to prevent brute-force and credential stuffing attacks. However,
a weakness was discovered in the AWS Console authentication flow that allowed
a partial bypass of this rate limit by pausing for 5 seconds every 30 attempts.
This would enable an attacker to continuously attempt more than 280 passwords
per minute (4.6 per second) against IAM users, which could have resulted in
account compromise of users without MFA enabled.


AWS Console rate limit bypass

AWS Control Tower was not properly logging to CloudTrail when API calls
failed due to a lack of permissions. This could have helped an adversary
with existing access to a victim AWS environment avoid detection while
enumerating privileges, since any unsuccessful API calls would not
generate "access denied" log entries.


Partial CloudTrail logging in AWS Control Tower

An AWS employee pushed sensitive data to a public github bucket, including customer information and credentials.
Note: This issue is outside the scope of this database's usual criteria for inclusion,
but has been kept for historic reasons, as it was included in the original CSP Security Mistakes dataset.


AWS uploaded sensitive data to public GitHub bucket

Ben Bridts

AWS Directory Service didn't check the iam:PassRole permissions when using the
EnableRoleAccess action. This could have been used for privilege escalation by an
authenticated user with sufficient permissions (ds:EnableRoleAccess), if the
role had a trust policy that allowed use by Directory Service.


AWS Directory Service not checking iam:PassRole on EnableRoleAccess

Information about this issue is under NDA, but AWS customers can read about it on pages 120-121 of the report,
which is available for download through AWS Artifact.
Note: This issue is outside the scope of this database's usual criteria for inclusion, but has
been kept for historic reasons, as it was included in the original CSP Security Mistakes dataset.


AWS SOC 2 type 2 failure (Fall 2020)

Information about this issue is under NDA, but AWS customers can read about it on page 98 of the report,
which is available for download through AWS Artifact.
Note: This issue is outside the scope of this database's usual criteria for inclusion, but has
been kept for historic reasons, as it was included in the original CSP Security Mistakes dataset.


AWS SOC 2 type 2 failure (Fall 2021)

Through an undocumented API service called 'iamadmin', attackers could invoke any of 13 read-only IAM actions without the activity being being logged to CloudTrail.
These actions included listing group policies (iam:ListGroupPolicies), listing access keys (iam:ListAccessKeys), retrieving information about a role (iam:GetRole), and more.
This could have enabled adversaries to perform enumeration and reconnaissance activity undetected after gaining a foothold in a victim AWS environment.


AWS CloudTrail bypass for specific IAM actions

AWS offers a metadata service accessible to most EC2 Instances via a simple GET request to 169.254.169.254.
If an instance has an SSRF vulnerability, attackers can access the metadata service & exfiltrate the credentials 
of an attached IAM role to gain privileged access to the relevant AWS environment.


AWS IAM role credential exfiltration via EC2 Instance Metadata Service (IMDSv1)

Alex Brasetvik

The AWS Java SDK was vulnerable to XML external entity (XXE) injection related to XML parsers.


AWS Java SDK XXE injection

Two malicious versions were created of packages previously used by AWS.
The packages were officially authored and maintained by AWS before they
were removed by their legitimate author, and once the packages were
removed, their names became available and the two packages were then
populated with malicious code. If AWS-deployed software had any dependencies
on these packages, this would have led to a dependency confusion attack.


AWS package backfill attack

Gafnit Amiga

A vulnerability was discovered in the Aurora PostgreSQL log_fdw extension
for Amazon Relational Database Service (RDS), allowing an attacker to read
files on the EC2 host and obtain credentials for an internal AWS service.


AWS RDS local file read

Riyaz Walikar

The AWS RDS service does not enable secure transport layer security by default, allowing clients to connect insecurely.
Additionally, for the more commonly used MySQL and MariaDB RDS engine types, this setting cannot be enabled at all.


AWS RDS does not enforce SSL/TLS encryption

Ryan Gerstenkorn

An attacker with sufficient privileges in AWS to modify the route table
and some other EC2 privileges, could pretend to be a metadata server and provide
an attacker controlled bootup script to EC2s to move laterally.


Route table modification to imitate metadata service

Jonathan Rault

Using CloudTrail S3 data events, it was possible to determine the AWS account ID of
any existing S3 bucket by calling any S3 API, getting denied, and looking at the value in the resource
key in error message that showed up in CloudTrail.


CloudTrail S3 data events leak bucket Account ID

Due to an exposed development endpoint, it was possible to bypass CloudTrail
logging for both read and write API actions for the Service Catalog service.
This could have enabled adversaries to alter Service Catalog resources undetected
after gaining a foothold in a victim AWS environment.


CloudTrail bypass for AWS Service Catalog

Colin Percival

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.


Signature version 1 (SigV1) is insecure

Osama Elnaggar

AWS WAF using the Core Rules set allowed SQL injection. In AWS WAF only the first 8 KB (8,192 bytes) of the request body are forwarded to AWS WAF for inspection, but AWS Managed rules allowed requests up to 10 KB.
An attacker could send a request larger than 8 KB but smaller than 10 KB, with a malicious payload located after the first 8,192 bytes, and thereby pass the WAFs inspection. 
To fix this issue, AWS reduced the request size limit to 8 KB.


AWS WAF configuration allows SQL injection

An adversary could gain access to IAM credentials in a victim's account, and make an API request to Elastic Beanstalk (even if they didn't have the proper IAM permissions). This request would be displayed in the management console in the Elastic Beanstalk section. Due to improper sanitization, an attacker could insert an XSS payload that would execute in a victim's browser.


Elastic Beanstalk - XSS in Web Console

John Novak

Azure Active Directory B2C service (AD B2C) mistakenly implemented RSA key authentication using the public part of the key pair instead of the private one.
This cryptographic flaw could have allowed an unauthenticated attacker to craft an OAuth refresh token for any AD B2C user account if they knew their public key.
Moreover, every AD B2C user's public key was recoverable through an unrelated vulnerability (though asymmetric cryptography should not rely on public key secrecy regardless).
An attacker could redeem this refresh token for a session token, thereby gaining access to the victim account as if they had logged in through a legitimate login flow.


Azure AD B2C cryptographic flaw allowing account compromise

Chen Cohen

An attacker could gain root privileges on their Azure Cloud Shell container,
escape from the container, and then gain root privileges on the underlying node,
the root cause being an insecure kubelet port (10250), among other cluster misconfigurations.
Once they could access the node filesystem, an attacker could extract kubelet API
credentials which allowed listing all pods and nodes in the cluster, including
those belonging to other tenants. Moreover, an attacker could bypass RBAC policies
in the cluster by deploying a pod with the "NodeSelector" flag, and thereby escalate
their privileges to root on other tenants' containers (the same issue affected
Azure Container Instances).


Azure Cloud Shell and Container Instances breakout

An issue in Azure Cloud Shell could have allowed an attacker to take over
an Azure App Service domain and leverage it to inject and execute
commands in other tenants' terminals if they navigated to the domain while
logged into their account. Using this method, an attacker could query the
Azure IMDS on other tenants' behalf and thereby obtain their access tokens.


Azure Cloud Shell access token theft

If attacker controlled data is viewed in Cloudshell it could have led to
code execution. This exact same issue was later discovered in AWS as well.


Azure Cloud Shell terminal escape

Christian August Holm Hansen

Binary Security discovered and registered two dangling cloudapp.azure.com
subdomains corresponding to subdomains at visualstudio.com. Had these been
discovered and registered by an attacker, this would have been equivalent
to a 1-click vulnerability for Azure DevOps: the attacker could have crafted
a URL referring to the sign-in API for Azure DevOps Services (app.vssps.visualstudio.com)
using one of the two subdomains in the "reply_to" field (since subdomains
of visualstudio.com would be allowed by the API). If clicked on by a target
Azure DevOps user, this would have sent an authentication token to an
attacker-controlled server, thereby allowing account takeover.


Azure Devops account takeover via dangling subdomain takeover

Aviv Sasson, Daniel Prizmant

In Azure Serverless Functions, a new container is generated by the host for every function,
which is then terminated and deleted after several minutes. Palo Alto discovered that an
API call was available to bind one path to another within the container (called "init_server_pkg_mount_BindMount")
that could be called by a low-privileged user but executed with root privileges. This could
enable a malicious tenant to escalate their privileges to root, and then escape their container
by abusing the Linux cgroup v1 “notification on release” feature (a well-known escape to host technique).
This last step was possible because the container had been granted the SYS_ADMIN capability,
did not have an AppArmor profile, and the cgroup v1 virtual filesystem was mounted as
read-writable from within the container (all against container hardening best practice).
However, the underlying HyperV host was single-tenant, thereby limiting the blast radius
of this vulnerability chain. Following disclosure, Azure added additional validation for
bind mount APIs, but the other elements of this attack sequence remain exploitable.


Azure Serverless Functions escape to host

Karl Fosaaen

Undocumented APIs used by the Azure Function Apps Portal could have allowed an attacker with existing
access to a Reader role on a Function App to escalate their privileges and gain write permissions
through arbitrary file reads on Function App containers. For Windows containers, this would only
grant an attacker the ability to extract ASP.NET encryption keys (the impact of which remains unclear),
but for Linux containers it would have allowed an attacker to read environmental variables containing
information that ultimately granted access to Function master keys. This in turn would have allowed
overwriting Function App code and gaining remote code execution within the container.


Azure Function Apps privilege escalation

Undocumented Azure AD APIs could allow access to internal information of any organization
that uses Azure AD. Collected details included licensing information, mailbox information, and
directory synchronization status.


Azure AD information disclosure via undocumented APIs

Josh Magri

Azure Logic Apps use API Connections to authenticate actions to services. Having Contributor access to
an Azure Resource Manager (ARM) API Connection would allow someone to create arbitrary role assignments as the connected user.
This was supposed to be limited to actions at the Resource Group level, but an attacker could escape to the Subscription or Root level with a path traversal payload.
The root cause of this behavior was that such a payload would meet the Swagger API definition,
and it would be resolved by the server, resulting in a request to an unintended scope.


Logic Apps privilege escalation to root

Haakon Holm Gulbrandsrud, Christian August Holm Hansen

Binary Security found two vulnerabilities in the legacy Azure Resource Manager (ARM) REST API.
The first vulnerability allowed an attacker with Reader access to an Azure Function, acting from
a Windows host, to get an admin token that could be exchanged for a master key granting access
to all operations in Kudu (the Functions deployment service). This would allow them to tamper
with the function by deploying malicious code to it. The other vulnerability allowed an attacker
with Reader access to an Azure App Service to read all process environment variables, including
Key Vault references. For Azure Functions, this would result in complete compromise of the app.


Azure App Services takeover via legacy API

Nadav Noy

Legit Security found an RCE vulnerability in Azure Pipelines that could have allowed an
attacker to gain complete control of variables and tasks by exploiting logging commands.
This would have enabled them to execute malicious code in a context of a pipeline workflow,
which would have granted them access to sensitive secrets such as cloud deployment keys,
move laterally in the organization, and potentially initiate supply chain attacks.
To exploit this vulnerability, an attacker would have needed permissions to create
a pull request or push a commit in a repo integrated with Pipelines.


RCE vulnerability in Azure Pipelines

Patrick Hudak

Patrick Hudak demonstrated possible subdomain takeover using the Traffic Manager in Azure.


Subdomain takeover via Azure Traffic Manager

Divyanshu Shukla

Azure Web Application Firewall (WAF) with OWASP 3.2 managed rule set and below was
vulnerable to command injection bypass using globbing patterns (incorporating the
wildcard "?" in command syntax). For example, while attempting access to "/etc/passwd"
would be blocked, a command targeting "/et?/passwo?d" would be allowed.


Azure WAF managed rule set globbing pattern bypass

SSRF vulnerabilities were discovered in four Azure services: unauthenticated SSRF in
Azure Digital Twins Explorer and Azure Functions, and authenticated SSRF in Azure API
Management Service and Azure Machine Learning Service. All four vulnerabilities were
full (non-blind) SSRF. The impact of these vulnerabilities was limited: while they
would have allowed an adversary to scan local ports and find new services, endpoints,
and files; they would not have allowed them to access metadata, connect to internal
services, access unauthorized data, or obtain cross-tenant access.


Multiple SSRF vulnerablities in Azure services

Yuval Avrahami

Azurescape

Roi Nisimi

An information disclosure vulnerability in the Google Cloud Build service could have
allowed an attacker to view sensitive logs if they had gained prior access to a GCP
environment and had permission to create a new Cloud Build instance (cloudbuild.builds.create)
or permission to directly impersonate the Cloud Build default service account (which is highly
privileged by design and therefore considered to be a known privilege escalation vector in GCP).
An attacker could then potentially use this information in order to better facilitate lateral movement,
privilege escalation or a supply chain attack by other means. This issue was due to excessive
permissions granted to the default service account created by Cloud Build, particularly access to
audit logs containing all project permissions (logging.privateLogEntries.list).


Bad.Build

Orca discovered vulnerabilities in Azure Bastion and Azure Container Registry
that could have enabled an attacker to achieve Cross-Site Scripting (XSS) by
using iframe postMessages. The vulnerabilities allowed embedding of endpoints
within remote attacker-controlled servers using the iframe tag, thereby granting
unauthorized access to the victim’s session in the affected service if they
were tricked into navigating to an attacker-controlled website. The root cause
was that certain web pages in the Bastion and Container Registry customer-facing
portals allowed embedding of iframes in remote servers, meaning they were not
using mitigations such as the X-Frame-Options header or the frame-ancestors
directive in a Content Security Policy (CSP), which would have prevented these issues.


XSS in Azure Bastion and Container Registry

In September 22', SOCRadar discovered an insecure public Azure blob storage owned by Microsoft (olyympusv2.blob.core.windows[.]net). This blob storage was used for storing emails and other documents from interactions with their customers (such as contracts and purchase orders). In total, the blob storage contained 2.4TB of data with information concerning thousands of Microsoft customers across dozens of countries, dated between 2017 and August 22'. Following disclosure, Microsoft reconfigured it to be private. According to Microsoft, they found no indication customer accounts or systems were compromised, and directly notified affected customers.


BlueBleed

Tzah Pahima

Read access of host of AWS internal Cloudformation service via XXE SSRF.
The level of access with the compromised IAM role from there is unclear.


BreakingFormation

Ronen Shustin, Shir Tamari

ApsaraDB and AnalyticDB contained several vulnerabilities in their PostgreSQL offerings
which ultimately allowed unauthorized access to other tenants' databases and the ability
to perform a supply-chain attack on both services, which in turn would have allowed remote
code execution (RCE) as well. Both services implemented multi-tenancy through a shared K8s
cluster, but contained several bugs related to tenant isolation which an attacker could
chain together to achieve the above impact. In ApsaraDB, these included privilege escalation
to root in a container, a shared PID namespace enabling container escape, and write permissions
granted to K8s nodes for a private container image registry utilized by both services.
In AnalyticDB, the bugs included file disclosure, command line injection in a privileged
container, and susceptibility to the core_pattern container escape technique.


BrokenSesame

Etienne Champetier

An attacker with 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 and injecting our own SSH key, it
is possible to gain root privilege on the host.


GKE and EKS CAP_NET_RAW metadata service MITM root privilege escalation

Nir Ohfeld, Sagi Tzadik

Azure's Cosmos DB database service was vulnerable to remote account takeover.
Any Azure user could gain full admin access to other customers' Cosmos DB instances without authorization.
The vulnerability had a trivial exploit that doesn't require any previous access to the target environment.


ChaosDB

Peter Collins

Executing Cloud Functions or Cloud Run in any project and in any organization allowed bypassing the GKE Authorized Networks (aka Kubernetes 
control plane firewalls) of a cluster in a different project or organization.


GKE Authorized Networks bypass via Cloud Functions or Cloud Run

Ian Mckay

An attacker with the ability to create CloudFormation stacks could cause
a denial-of-service on some CloudFormation actions within a single AWS account.


CloudFormation denial of service (in a single account)

Aidan Steele

CloudFormation allows the use of Lambda-backed resource providers,
wherein Lambda can be used to write custom provisioning logic to be
executed during CloudFormation stack operations. The aforementioned
Lambda functions were executed in an AWS-managed account (thus
effectively allowing arbitrary code execution in that account),
and were passed a set of credentials ("platformCredentials") for a
role in this account that had several EventBridge permissions.
These were sufficient for an attacker to create new rules in the AWS-managed
account that leaked credentials belonging to other users of resource
providers. For example, creating a rule that matched events with
{"detail-type": ["AWS API Call via CloudTrail"]} exposed records
of other tenants' API calls, which included copies of credentials
for roles in other tenants' accounts.


CloudFormation resource provider credentials leak

Karim El-Melhaoui

An audit of an AWS open-source project identified a great deal of issues, and as a result AWS made the decision to take it down.


CloudFormer review

Shir Tamari, Nir Ohfeld, Sagi Tzadik, Ronen Shustin

In GCP's case, they introduced a modification to the Cloud SQL's PostgreSQL engine allowing the role assigned to the
tenant (cloudsqlsuperuser) to arbitrarily change the ownership of a table to any user
or role in the database. Thus, an attacker could (1) create a new table, (2) create an
index function with a malicious payload, and (3) change the table owner to GCP’s superuser
role (cloudsqladmin). Next, by initiating an ANALYZE command, the malicious function is
executed with GCP’s superuser high privileges. Then, an attacker could gain local privilege
escalation to root using a symlink attack, and finally, having gained CAP_NET_ADMIN and
CAP_NET_RAW capabilities, escape their container via TCP injection of a fake configuration
response from the metadata service containing an attacker-controlled SSH key (this is only
possible due to the fact that communication with GCP's metadata service is unencrypted and unsigned).
A similar bug existed in Azure Database for PostgreSQL, and was part of ExtraReplica's vulnerability chain.


Cloud SQL escape to host

A vulnerability discovered in GCP's Cloud SQL service could be abused
to result in complete control of the database engine and access to the
host OS. An attacker could have listed and accessed files in the host OS,
including any secrets on the machine, as well as gaining access to service
agents. However, it is unclear from the report if this level of access could
have allowed lateral movement within the Cloud SQL service or grant cross-tenant
access to other customers' data. The root cause of this vulnerability is also
unclear, though it allowed a series of privilege escalations, initially granting
the default sqlserver user access to a GCP admin role, and then the sysadmin role,
effectively granting a potential threat actor full access to the SQL server.


Cloud SQL privilege escalation

When customers attach a CodeBuild project to their VPC, CodeBuild’s build container
will apply the same network routing rules as defined in the customer’s VPC Security Group.
However, CodeBuild EC2 hosts retained Internet connectivity via AWS's own VPC, thus allowing
an attacker to bypass any custom VPC rules the customer had set up, and use CodeBuild for
data exfiltration from the targeted environment. AWS later updated the CodeBuild service
to block all outbound network access for newly created CodeBuild projects which contain a
customer-defined VPC configuration.


Codebuild data exfiltration

Opsmorph discovered an improper access control vulnerability in authorization logic common in applications built on AWS. The vulnerability means a user 
with permission to create a new Cognito User Group could fool authorization checks into thinking that the user is in any other existing Cognito User 
Group in the same User Pool, referred to as user group spoofing. 
When API Gateway is secured with a Cognito User Pool Authorizer it concatenates group names from the identity token into a comma separated string, 
and as Cognito also permits commas in the group names, this was an ambiguous representation of the groups a user was in that provided an opportunity 
for injection type attack. AWS have since fixed the Cognito User Pool Authorizer so that it now escapes special characters when parsing the groups claim
of the token.


Cognito User Group spoofing

Lidor Ben Shitrit, Roee Sagi

Cosmos DB notebooks lacked an authentication check, meaning that if an attacker
somehow had prior knowledge of a notebook’s temporary ‘forwardingId’ (a 128bit
cryptographically random GUID assigned to a short-lived workspace that expires
after an hour), they could gain full permissions on the notebook, including
read and write access and the ability to modify the file system of the
container running the notebook. These permissions would suffice for an
attacker to obtain remote code execution (RCE) in the notebook container.
However, this would not allow an attacker to execute notebooks, automatically
save notebooks in the victim’s (optionally) connected GitHub repository, or
access data in the Cosmos DB account. Following disclosure, Cosmos DB notebooks
now require an authorization token in the request header before allowing access.


CosMiss

Megan Marsh

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.


Launching EC2s did not require specifying AMI owner

Ronen Shustin

A Vulnerability in App Service could allow an unprivileged function run by the user to execute code in the 
context of NT AUTHORITY\system, thereby escaping the sandbox. This vulnerability allowed cross-account access 
when using the Free/Shared tier.


Azure App Service RCE

Paul Litvak (Intezer), Wouter ter Maat (Offensi)

A vulnerability in the Azure Linux VM extension mechanism allowed an unprivileged
user to leak any Azure VM extension’s private data. An attacker could have abused
this to gain credentials for the VM itself as well as credentials for extensions
associated with the VM. Paired with the design of the VMAccess extension (an official
Azure extension for managing VM credentials), this could have been used to achieve
privilege escalation, as an unprivileged attacker would have been able to elevate themselves
to a higher privileged user by leaking the VMAccess admin password. Additionally, if the VMAccess
password happened to be shared among other Azure VMs, the attacker would have been able to perform
lateral movement to other machines. The root cause of this vulnerability was that the
certificates endpoint used for decrypting extension credentials did not validate transport
certificates, so an attacker could simply issue their own valid transport certificate.
Moreover, although an iptables rule was in place to prevent unprivileged access to this
endpoint, an attacker could bypass it by directing their requests to the Azure IMDS instead,
which happened to be located on the same machine as the certificates endpoint.


Azure Linux VM extension credential leak

David Yesland

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.


AWS Workspace client RCE

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).


CredManifest (Azure AD keyCredential property information disclosure)

Amazon Elastic Kubernetes Service (EKS) uses IAM to provide authentication to the cluster through the AWS IAM Authenticator for Kubernetes (aws-iam-authenticator).
aws-iam-authenticator can be installed on any Kubernetes cluster, and it is installed by default in any EKS cluster both on AWS cloud and on-premises (Amazon EKS Anywhere).
A security issue was discovered in aws-iam-authenticator where an allow-listed IAM identity may be able to modify their username and escalate privileges.
The bug allowed an attacker to (1) craft a malicious token with any action value, (2) without signing the cluster ID, (3) that would manipulate the AccessKeyID value.
Essentially, in clusters using aws-iam-authenticator, if an {{AccessKeyID}} was mapped to an IAM user with cluster admin privileges, any non-privileged user could have escalated their privileges to cluster admin.


AWS IAM Authenticator for Kubernetes AccessKeyID Validation Bypass

The AWS VPN Client application is affected by an arbitrary file write as SYSTEM,
which can lead to privilege escalation and an information disclosure vulnerability
that allows the user's Net-NTLMv2 hash to be leaked via a UNC path in a VPN configuration file.


Search Results

Tags:

Power Platform Custom Code information disclosure

Evan Grant, Tenable

Bad.Build

Roi Nisimi, Orca Security

nOAuth

Descope

XSS in Azure Bastion and Container Registry

Lidor Ben Shitrit, Orca Sec...

Azure App Services takeover via legacy API

Haakon Holm Gulbrandsrud, C...

AWS Directory Service not checking iam:PassRole on EnableRoleAccess

Ben Bridts, Cloudar