Introduction
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:
- 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).
- 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.
- 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.
- 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
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
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
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).
Overall
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:
- Number of Critical Vulnerabilities
- Number of High Vulnerabilities
- 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.
Summary
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 