search

wiz-sec / open-cvdb

An open project to list all publicly known cloud vulnerabilities and CSP security issues
https://cloudvulndb.org
Creative Commons Attribution 4.0 International
306 stars 61 forks source link

Discussion "From listKeys to Glory" #167

Closed 0xdabbad00 closed 1 year ago

0xdabbad00 commented 1 year ago

We received a question about this blog post being added to cloudvulndb: https://orca.security/resources/blog/azure-shared-key-authorization-exploitation/

I do not believe this fits into our criteria of a cloudvuln, as it does not appear to be a mistake by the cloud provider (note that MSRC did not fix anything). This is a privilege escalation within a specific customer environment. Microsoft Azure Shared Keys provide access by design, although Microsoft recommends they be disabled. This appears similar to how AWS access keys provide access, but AWS recommends alternatives be used.

This key in the specific environment was privileged enough to read and edit Azure functions, which enabled them to get code execution in the context of one of the functions.

It is unclear to me how common these various configurations are that allowed the researchers to escalate their privileges like this, but it ultimately appears to be on the customer side of the shared responsibility model. There is a fuzzy line for when a design choice is problematic enough that it constitutes a cloud vuln for inclusion in this database. For example, we had added AWS's IMDSv1 (see here: https://github.com/wiz-sec/open-cvdb/blob/main/vulnerabilities/aws-imds-credential-exfiltration.yaml). However, we do not have records in this database of AWS access keys or the ability to make an S3 bucket public, which AWS advises against using.

One key criteria for inclusion is "Did the cloud provider fix anything?". It's not always required for inclusion, but is a strong signal that the cloud provider made a mistake.

korniko98 commented 1 year ago

Just adding for future reference that in general these types of issues might be more at home at @Frichetten's hackingthe.cloud, so long as they're generic enough to be usable against more than one environment (@Frichetten please correct me if I'm mistaken).

Frichetten commented 1 year ago

Thank you for the shout-out @korniko98! Indeed, while I am by no means an expert in Azure, based on my understanding of the blog post this would be an excellent addition to Hacking the Cloud. Anything abusable on the customer side of the shared responsibility model is fair game.