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

Amazon Managed Workflows for Apache Airflow (MWAA) and the Task instance details
page in the Google Composer UI were not patched against CVE-2023-29247 (Stored XSS).
This meant that post-authentication, a threat actor could have exploited this
to store their JavaScript payload in the victim's managed Apache Airflow instance
and run JavaScript on behalf of the victim (who could be an admin or another
user with higher permissions than the threat actor, thereby leading to privilege escalation).
With JavaScript, threat actors could have run any operation in the session that the victim
is able to run — edit tasks, read jobs, run jobs, read plugins and configurations, 
list connections, add variables and more.


ApatchMe

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 issues 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

AWS identified an issue in the Amazon WorkSpaces Windows client which resulted in unintentionally logging
connection debugging information to a user's local system. This data could include usernames or passwords
if they contain specific characters: \ (backslash) or " (double quotes). If an attacker gained access to
an Amazon WorkSpaces user's machine, they could then compromise such credentials from the log.


Amazon WorkSpaces Windows client credential logging

Johann Rehberger

An Indirect Prompt Injection attack can cause the LLM to return
markdown tags. This allows an adversary who’s data makes it into
the chat context (e.g via an uploaded file) to achieve data
exfiltration of the victim’s data by rendering hyperlinks.


Amazon Q for Business Data Exfiltration

The AWS Amplify service was found to be misconfiguring IAM roles associated 
with Amplify projects. This misconfiguration caused these roles to be assumable 
by any other AWS account. Both the Amplify Studio and the Amplify CLI 
exhibited this behavior. Any Amplify project created using the Amplify CLI
built between July 3, 2018 and August 8, 2019 had IAM roles that were assumable by
anyone in the world. The same was true if the authentication component was removed
from an Amplify project using the Amplify CLI or Amplify Studio built between
August 2019 and January 2024. AWS mitigated this vulnerability through backend changes to
STS and IAM, and also released a patch for the Amplify CLI to ensure that newly
created roles are properly configured in accordance with these changes.


AWS Amplify IAM role publicly assumable exposure

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

AppFlow had an undocumented service called sandstoneconfigurationservicelambda. 
An undocumented field (awsOwnedManagedAppCredentialsArn) could be used during
connector registration and connector updates. Specifying a victim's Secret ARN
as that field disclosed the clientId and clientSecret, so long as the victim
Secret ARN belonged to a connection profile which is of the type 
OAuth or contains clientId and clientSecret.


AWS AppFlow secrets disclosure

The AppFlow WooCommerce connector allowed specification of a full URL.
The connector included details of response content when the URL
offered an unexpected response. This means you could make arbitrary
GET requests to any URL from the WooCommerce connector, and view the 
response content. The response in the error was truncated to 500 characters.


AWS AppFlow WooCommerce SSRF

Saransh Rana

Credentials can be extracted from AppStream. When used, they obscure
the sourceIP and userName of the initial user. The sourceIP appears 
as appstream.amazonaws.com.


AWS AppStream Cloudtrail Bypass

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

Ofek Itach, Yakir Kadkoda

The AWS Cloud Development Kit (CDK) is a way of deploying infrastructure-as-code. The vulnerability involves AWS CDK’s use of a predictable S3 bucket name format
(cdk-{Qualifier}-assets-{Account-ID}-{Region}), where the default “random” qualifier (hnb659fds) is common and easily guessed. If an AWS customer deletes this bucket and reuses CDK, 
an attacker who claims the bucket can inject malicious CloudFormation templates, potentially gaining admin access. Attackers supposedly only need the AWS account ID to prepare the bucket 
in various regions, exploiting the default naming convention. However, it is important to note that the additional conditions greatly lower the likelihood of exploitation. 
The victim must use the CDK, having deleted the bucket, and then subsequently attempt to deploy with the CDK. Making it so that even if there is a vulnerable account, it could be months, 
if ever for the attack to work.


AWS CDK Bucket Squatting Risk

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

Carlos Polop

An attacker with elevated permissions in CodeBuild could leak 
the configured credentials for Github/Bitbucket. This was possible by 
configuring the http_proxy and https_proxy variables, which would allow 
you to capture the credentials via MITM.


AWS CodeBuild Token Leakage

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

Scott Piper

Even for the AWS-managed ElasticSearch clusters that had not been made public,
their index names could be learned.


AWS ElasticSearch Index Name Leakage

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)

Michael Werner

A principal with the permissions glue:GetConnection and ec2:DescribeSubnets
can retrieve the database password of a connection, since the password is loaded into
the AWS console website when a connection's edit page is requested. The severity of
this issue is low since it requires sufficient prior access.


AWS Glue database password leakage

Aidan Steele

AWS IAM Identity Center exchanges third-party OIDC tokens for
Identity Center-issued tokens. Identity Center relies on the jti
claim in the third-party tokens to prevent replay attacks. 
Identity Center maintained a cache of previously-seen jti values
for a fixed period (24 hours) and didn’t enforce that the third-party
tokens had expiry claims. This meant that a token with a jti claim and
without an exp claim could be replayed after >24 hours had passed. 


AWS IAM Identity Center Expiry

Tag variable names affected whether trust policy conditions were evaluated correctly.
If the request tag referenced a principal tag called MemberRole in the JWT token, and 
the IAM role referenced a resource tag with the same variable name, the condition was
always evaluated as true, regardless of whether the tag's values actually matched. Only
role trust policies that used a variable substitution for both the request tag and the
resource tag in the policy statement resulted in the policy evaluating incorrectly. The 
issue impacted statements within IAM boundary policies and SCP policies that contained 
the same pattern of STS role assumption with tag-based conditions.


AWS IAM Trust Policy Condition Evaluation Bug

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

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

In Azure AI Playground, a Prompt Injection attack could cause an LLM to return markdown tags. 
This would have allowed an adversary whose data makes it into the chat context
(e.g., via an uploaded file) to achieve exfiltration of the victim’s 
data by rendering hyperlinks. However, the severity of this issue is low,
as there were no integrations that could pull remote content. This means
Indirect Prompt Injection was not possible, and it would require the victim to copy
the malicious prompt from elsewhere. A similar issue affected GCP Vertex AI.


Azure AI Playground data exfiltration

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

Nadav Noy

Legit Security found a zero-click vulnerability in Azure Pipelines that allows
an attacker to access secrets and internal information and perform actions in
elevated permissions in the context of a pipeline workflow. This could allow 
attackers to move laterally in the organization and initiate supply chain attacks.
When a pipeline is triggered by a "pipeline resource trigger," it shows in the
platform as "Automatically Triggered For …" Instead of running in fork default
permissions, preventing any access to secrets and sensitive actions, Azure Pipelines
"confuses" the trigger for an internal build allowing access sensitive build secrets.
Exploitability depends on a public GitHub repository that runs Azure pipelines on pull-request,
with default Azure pipeline fork configurations to trigger pipeline run, and Pipeline-Triggers.


Azure Devops Zero-Click CI/CD Vulnerability

Jeti

A client-side desync vulnerability was discovered in Front Door, one of Azure's CDN solutions,
caused by mishandling of the 'Content-Length' header in HTTP requests. Exploiting this vulnerability
would most likely require user interaction through social engineering (such as clicking on a malicious
link), but could allow an attacker to steal session cookies or forge responses to victim requests.


Azure Front Door client-side desync

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

Three privilege escalation and denial-of-service vulnerabilities were discovered in Azure HDinsight, related to their usage of Apache Oozie and Ambari.
The root cause of at least one of these vulnerabilities is a flaw in Apache Oozie itself, leading to regex denial-of-service (ReDoS). The other two vulnerabilities
could allow an authenticated attacker with HDI cluster access to gain cluster administrator privileges and perform any resource service management operation.
The vulnerabilities were patched in the October 2023 security update of Azure HDinsight.


Azure HDInsight privilege escalation and DoS vulnerabilities

Azue Health privilege escalation via SSRF

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

Yakir Kadkoda, Assaf Morag

A Microsoft employee accidentally published credentials via a git commit to a public repository.
These credentials granted privileged access to an internal Azure Container Registry (ACR) used by Azure,
which reportedly held container images utilized by multiple Azure projects, including Azure IoT Edge, Akri,
and Apollo. The privileged access could have allowed an attacker to download private images as well
as upload new images and (most importantly) overwrite existing ones. In theory, an attacker could have
leveraged the latter to implement a supply chain attack against these Azure projects and their users.
However, it is currently unknown precisely which images this ACR contained or how they were used,
so the effective impact of this issue remains undetermined.


Internal Azure Container Registry writable via exposed secret

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

Azure Machine Learning SSRF

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

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

Joshua Murrell

When the ASR service is enabled, it uses an Automation Account with a System-Assigned Managed Identity
to manage Site Recovery extensions on VMs. However, the Runbook (a set of scripts for managing extensions)
executed by the Automation Account had its job output visible to users, and this output mistakenly included
a cleartext Management-scoped Access Token for the System-Assigned Managed Identity, which possesses the
Contributor role over the entire Azure subscription. Therefore, lower-privileged user roles who could access
the Automation Account's job output could see and use this Access Token. This access allowed these users to
impersonate the Managed Identity, thereby elevating their privileges to that of a Contributor for the whole
subscription, including the ability to execute commands on VMs as `NT Authority\\SYSTEM`.


Azure Site Recovery privilege escalation

Patrick Hudak

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


Subdomain takeover via Azure Traffic Manager

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

Cycode discovered a CI/CD misconfiguration in the Bazel repo, which if exploited could have
allowed an attacker to enact a supply chain attack against all Bazel users, which includes
Google themselves and therefore likely GCP as well.


Bazel supply chain vulnerability

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.


Search Results

Tags:

AWS CDK Bucket Squatting Risk

Ofek Itach, Yakir Kadkoda, ...

Missing JWT issuer and signer validation in ALB middleware

Miggo Security

Document AI data exfiltration

Kat Traxler, Vectra AI

CloudImposer

Liv Matan, Tenable

Copilot Studio information disclosure via SSRF

Tenable

Azue Health privilege escalation via SSRF

Tenable