I did read the text. I suggest you read the article. Microsoft lied and literally called it “expected behaviour”, then silently patched it. Why would they patch expected behaviour?
The exploit discovered and lodged by O’Leary was confirmed independently to exist and function by CERT/CC and they gave it an interim CVE entry. The only reason it was not finalized and publicized is that Microsoft has the right to overrule CVEs as part of the CNA hierarchy rules.
As the researcher said, it’s a privelige escalation bug. So yes, an attacker would need some privilege… But this is still a major vulnerability.
The vulnerability allowed a user with only Backup Contributor (an Azure RBAC role with zero Kubernetes permissions) to trigger this access grant [for the entire Kubernetes cluster].
Azure’s Backup Contributor is a role widely assigned in organizations to their mid and even low-level IT staff. At a Fortune 500 company there may be hundreds of people around the world with that permission to manage their own site’s or office’s backups.
Azure’s Kubernetes Cluster Admin is a much more powerful role. It allows unrestricted access to the entire Kubernetes cluster - including retrieving admin credentials for the cluster via powershell, and accessing or modifying any data on the cluster. How much that could impact a particular environment depends on what services they have containerized into their Kubernetes cluster, but it could be almost anything… web frontend for user logins, a payroll system interface also with logins, etc - attacker would be able to access all that information with some skill. They could also simply install a pod that acts as a backdoor into the whole environemnt and take their time looking through all data to extract what further access they need or want.
That’s why this was assessed by CERT to a CVE rating of 9.9 - critical vulnerability that poses a severe risk.
The bigger issue as I said is not the bug, its Microsoft’s response. Lie, use their power to quash the report, silently patch it, alert nobody. There may be impacted businesses/orgs out there that have been breeched through this vulnerability, and now they will not even know to check their logs, rotate Kubernetes cluster admin password or audit & validate their Kubernetes pods.
I did read the text. I suggest you read the article. Microsoft lied and literally called it “expected behaviour”, then silently patched it. Why would they patch expected behaviour?
The exploit discovered and lodged by O’Leary was confirmed independently to exist and function by CERT/CC and they gave it an interim CVE entry. The only reason it was not finalized and publicized is that Microsoft has the right to overrule CVEs as part of the CNA hierarchy rules.
As the researcher said, it’s a privelige escalation bug. So yes, an attacker would need some privilege… But this is still a major vulnerability.
Azure’s Backup Contributor is a role widely assigned in organizations to their mid and even low-level IT staff. At a Fortune 500 company there may be hundreds of people around the world with that permission to manage their own site’s or office’s backups.
Azure’s Kubernetes Cluster Admin is a much more powerful role. It allows unrestricted access to the entire Kubernetes cluster - including retrieving admin credentials for the cluster via powershell, and accessing or modifying any data on the cluster. How much that could impact a particular environment depends on what services they have containerized into their Kubernetes cluster, but it could be almost anything… web frontend for user logins, a payroll system interface also with logins, etc - attacker would be able to access all that information with some skill. They could also simply install a pod that acts as a backdoor into the whole environemnt and take their time looking through all data to extract what further access they need or want.
That’s why this was assessed by CERT to a CVE rating of 9.9 - critical vulnerability that poses a severe risk.
The bigger issue as I said is not the bug, its Microsoft’s response. Lie, use their power to quash the report, silently patch it, alert nobody. There may be impacted businesses/orgs out there that have been breeched through this vulnerability, and now they will not even know to check their logs, rotate Kubernetes cluster admin password or audit & validate their Kubernetes pods.