How Cloud Service Providers Are Failing At Shared Security Responsibility

| Sep 1, 2023


In this post, I’m going to talk about a commonly discussed idea that cloud service providers (CSPs) are responsible for managing the risks associated with their services, in partnership with their customers. The shared responsibility model is commonly used to describe the fundamentals of who looks after the security of your data and services. As with any outsourcing agreement (which is essentially what an arrangement with a CSP is), there is a joint responsibility for the security and availability of data and workloads in a cloud service that is shared between the cloud provider, and the customer of that service.

However, there have been instances where cloud providers have failed to uphold their responsibilities in the shared responsibility model to keep their customers secure - namely, they have failed to ensure the security of their products and actually adhere to “security by design” and the principle of least privilege.

So why write this post?

When I initially started this post, it was intended to be a breakdown of a talk by the awesome Dr Nestori Syynimaa (aka DrAzureAD, the creator of AAD Internals) at Troopers ‘23 on abusing Azure AD Domain Services to dump NT hashes from cloud synced users.

That talk is embedded below and I recommend that you watch it in full:

My takeaways from that were as follows:

  1. When you use a managed service you would expect it to be properly patched in a timely manner (wasn’t the case here - known vulnerabilities were used to gain access to the domain controllers that Microsoft manage for you as a customer of AADDS).
  2. You’d expect the provider to properly monitor the service not just for uptime, performance etc. but also for any signs of malicious behaviour. In this case it was being monitored but the response time was not always good enough.
  3. If this had happened to you, you’d have had your users passwords dumped and/or your managed domain suspended and therefore applications and services that depend on it would be down, costing you money and also reputational harm.
  4. The password hashes remain in AAD seemingly forever and of course the knowledge is now out there on how to get at them…

Ok but that’s one incident, what’s the big deal?

In short, this isn’t an isolated incident - in fact there have been several high profile vulnerabilities and misconfigurations in recent years that have caused me concern that Microsoft aren’t taking their responsibilities seriously here (more on that later).

It dawned on me that I could perhaps be seen as somewhat biased against Microsoft here - I’ve shared plenty of posts about Microsoft security failings on my socials - though to date that’s probably because it’s the Cloud Service Provider I’ve had the most experience with and also a software manufacturer I’ve used most often throughout my personal and work life.

So, to attempt to remove that bias and look at the big picture here, what follows is a more detailed and hopefully holistic review of the issue.

For this, I’m going to use an excellent source of information on cloud vulnerabilities: The Open Cloud Vulnerability & Security Issue Database

Why use that? Well, I’m going to quote their mission statement on their about page on their website:

Mission Statement
Security bugs in cloud services tend to fall between the cracks, as they don’t fit well into the current shared responsibility model of cloud security. As a result, remediation of cloud security vulnerabilities often requires a joint effort between both the CSP and their customers.

There is currently no universal standard for cloud computing vulnerability enumeration – CSPs rarely issue CVEs for security mistakes discovered in their services, there are no industry conventions for assessing severity of cloud vulnerabilities, no proper notification channels and no unified tracking mechanism – this leads to a great deal of inefficiency and confusion surrounding cloud vulnerability management.

Our goal in this project is to pave the way for a centralized cloud vulnerability database, by cataloging CSP security mistakes and listing the exact steps CSP customers can take to detect or prevent these issues in their own environments.

We believe this project can prove the utility of a cloud vulnerability database, bring more transparency into these issues, and ultimately make the cloud even more secure.

Their full about page gives more details on what they classify as the criteria for inclusion in their database, and their history.

They also share all the vulnerabilities in a public GitHub repository.

Deep Dives

Amazon Web Services (AWS)

Vulnerabilities tagged as affecting AWS

In total, there are 66 vulnerabilities that are tagged with AWS as the affected platform - those rated High or Critical are listed below:

Vulnerability Severity Exploited / Exploitable Period Disclosure Date Published Date
Superglue Critical No / N/A 2021/09/30 2022/01/13
AWS IAM Authenticator for Kubernetes AccessKeyID Validation Bypass High No / Oct 2017 - June 2022 2022/07/11 2022/05/25
AWS Workspace client RCE High No / N/A 2021/09/21 2021/09/21
AWS AppSync confused deputy via ServiceRoleArn High Until 2022/09/06 / No 2022/09/01 2022/11/21
ECR Public vulnerability in undocumented API Critical No / N/A 2022/11/15 2022/12/13
LPE vulnerability in Eltima (3rd-party cloud desktop driver) High No / N/A 2021/05/02 2021/12/07
IAM privilege escalation via undocumented CodeStar API High Ongoing / No 2019/03/19 2019/06/18
AWS RDS local file read High No / N/A 2021/12/09 2022/04/11
CloudFormation resource provider credentials leak High No / N/A 2020/01/21 2020/09/22
AWS SSM agent local privilege escalation High until 2022/04/05 / No 2022/02/28 2022/04/20
Log4Shell Hot Patch Vulnerable to Container Escape and Privilege Escalation High No / N/A 2021/12/14 2022/04/19
Lake Formation data lake admin override High No / N/A 2019/08/15 2019/08/15
BreakingFormation Critical No / N/A 2021/09/09 2022/01/13

Severity Number Of Vulnerabilities
Critical 3
High 10
Medium 19
Low 30
N/A 4

Google Cloud Platform (GCP)

Vulnerabilities tagged as affecting GCP

In total, there are 23 vulnerabilities that are tagged with GCP as the affected platform - those rated High or Critical are listed below:

Vulnerability Severity Exploited / Exploitable Period Disclosure Date Published Date
RCE in Google Cloud Deployment Manager High until 2020/05/20 / No 2020/05/07 2020/05/21
Cloud SQL privilege escalation High No / N/A 2023/02/13 2023/05/24
IAM privilege escalation in multiple GCP services High Ongoing, partially fixed on June 2020 / No 2019/06/03 2020/11/22
SSH key injection in Google Cloud Compute Engine High No / N/A 2022/07/14 2023/01/12

Severity Number Of Vulnerabilities
Critical 0
High 4
Medium 16
Low 3
N/A 0

Microsoft Azure

Vulnerabilities tagged as affecting Azure

In total, there are 46 vulnerabilities that are tagged with Azure as the affected platform - those rated High or Critical are listed below:

Vulnerability Severity Exploited / Exploitable Period Disclosure Date Published Date
OMIGOD Critical No / N/A 2021/09/14 2021/06/01
Synlapse Critical No / N/A 2022/01/04 2022/05/09
Azure NotLegit High Sept 2017 - Dec 2021 / No 2021/12/21 2021/10/07
ChaosDB Critical 2017 - 2021 / No 2021/08/09 2021/08/26
Azurescape Critical N/A / No 2021/09/09 2021/09/09
EmojiDeploy High N/A / No 2022/10/26 2023/01/19
Azure AD B2C cryptographic flaw allowing account compromise Critical Until December 22’ / No 2021/03/01 2023/02/15
Azure on-premises data gateway cross-tenant access Critical N/A / No 2022/09/30 2023/03/30
XSS in Azure Bastion and Container Registry High N/A / No 2023/04/13 2023/06/14
AutoWarp Critical N/A / No 2021/12/06 2022/03/07
CredManifest (Azure AD keyCredential property information disclosure) High N/A / No 2021/10/07 2021/11/17
Power Platform Custom Code information disclosure High N/A / No 2023/03/30 2023/08/04
Azure App Service RCE Critical N/A / Null 2019/10/08 2020/01/30
Azure Open Management Infrastructure (OMI) Elevation of Privilege High N/A / No 2022/06/14 2022/06/14
Azure Function Apps privilege escalation High N/A / No 2022/08/02 2023/03/23
API Management SSRF and path traversal vulnerabilities High N/A / No 2022/12/21 2023/05/04
Azure Cloud Shell and Container Instances breakout High until January 30th, 2020 / No 2020/01/20 2021/02/15
ExtraReplica Critical N/A / No 2022/01/11 2022/04/28
Azure Cloud Shell access token theft High N/A / No 2022/08/20 2022/09/20
RCE vulnerability in Azure Pipelines High N/A / No 2022/09/05 2023/03/30

Severity Number Of Vulnerabilities
Critical 10
High 11
Medium 18
Low 6
N/A 1

What Does It All Mean?

Let’s pull those into one summary table and see what that tells us…

Severity AWS Azure GCP
Critical 3 10 0
High 10 11 4
Medium 19 18 16
Low 30 6 3
N/A 4 1 0


AWS has the most reported vulnerabilities in total at 66, stretching back to 2016.

13 of those are rated Critical (3) or High (10).

3 vulnerabilities referenced cross-tenant access (being able to access data in other customers tenants).


Azure has the next most reported vulnerabilities at 46, stretching back to 2016.

21 of those are rated Critical (10) or High (11).

9 vulnerabilities referenced cross-tenant access (being able to access data in other customers tenants).


GCP has the lowest reported vulnerabilities at 23, stretching back to 2019.

None of those are rated Critical, with 4 being rated as High.

2 vulnerabilities referenced cross-tenant access (being able to access data in other customers tenants).


I only spent a couple of hours analysing this, but just from that, there is certainly a fair inference that Microsoft may indeed be getting legitimate criticism for their security practices even just from an Azure platform perspective, ignoring their Operating Systems and other products (including M365).

As ever, there are many factors to consider - I have focussed on a few particular metrics here:

  1. Number of Critical Vulnerabilities
  2. Number of High Vulnerabilities
  3. Number of Cross-Tenant Access Vulnerabilities

I was particularly concerned with failure to isolate customers data from other customers - especially as this is not a concern for traditional on-premise self-hosted datacenters.

With that said though, there are other key themes of concern that were present for some or all of the top 3 CSPs:

  • Remote Code Execution
  • Privilege Escalation
  • Lateral Movement
  • Container/Sandbox Escape
  • Data Breaches (unsecured storage)
  • Unauthenticated Access

You may or may not agree with my methodology here:

  • You may or may not agree with the use of the Open Cloud Vulnerability & Security Issue Database
  • You may or may not agree with the ratings given by that database
  • You may disagree with my focus on Critical/High rated vulnerabilities (I did this because they have the most impact and have the least ambiguity around the responsibility lying with the CSP rather than the customer or them even being a vulnerability or misconfiguration at all - for example there is at least one rated as Low where the the complaint is that there is no change control around changes to managed IAM policies when in fact the real issue is that the complainant didn’t agree with the changes made)
  • You may not agree that cross-tenant access deserves the focus I have given it here
  • You may (rightly) point out that multiple Low and or Medium rated vulnerabilities can be chained together to achieve a breach that you would rate as High or Critical - however I was never going to perform attack path/attack chain analysis on all of these - but the point stands, and enforces the overall takeaway message. In the AADDS talk I linked to earlier, Nestori had his colleagues compromise the Microsoft managed domain controllers using two (unnamed) CVEs. Though we don’t know the severity of those CVEs individually, you can infer that their combined impact and severity is greater than their individual parts and enabled further compromise of AAD.

Feel free to contact me (email/social networks) or comment below and continue the discussion.

The reason I gave so much weight to this is that it aligns with the original premise - I believe that CSPs are failing to uphold their responsibilities under the Shared Responsibility model, and it seems to clear to me that, at time of writing, Microsoft are the worst offender by that metric.


In conclusion, while cloud computing has many benefits, it is important for both cloud providers and customers to understand their responsibilities when it comes to security.

Cloud providers should be responsible for managing the risks associated with their services and should ensure that their products are designed with security in mind and adhere to the principle of least privilege.

As ever, thanks for reading and feel free to leave comments down below!

If you like what I do and appreciate the time and effort and expense that goes into my content you can always Buy Me a Coffee at

comments powered by Disqus