Secrets Exposure Via Azure Key Vault Role
Overview
In December 2024, Researchers identified a potential privilege escalation vector in Azure Key Vault. The issue arises from the misconfiguration of the permissions associated with the "Key Vault Contributor" role. While this role is documented to allow management of key vaults without granting data access, it includes the Microsoft.KeyVault/vaults/write permission. This permission enables users to modify access policies, effectively allowing them to grant themselves or others full access to the key vault's data.
What is Azure Key Vault?
Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Access to these resources is managed through two primary models:
Azure Role-Based Access Control (RBAC): Provides fine-grained access management of Azure resources.
Key Vault Access Policies: Offer a separate permissions model specific to Key Vault.
The Key Vault Contributor role is designed to manage key vaults without granting access to the stored data.
What Went Wrong?
Azure Key Vault uses roles to manage permissions. Among these roles is the "Key Vault Contributor," primarily intended for managing key vault resources. In theory, this role does not allow access to sensitive data such as secrets or cryptographic keys.
However, the "Key Vault Contributor" role includes the Microsoft.KeyVault/vaults/write permission. This permission allows changes to the vault’s access policies, enabling users to grant themselves or others the permissions to access sensitive data. This misalignment between intended and actual permissions creates a potential attack vector for privilege escalation, making it critical to understand how it can be exploited.
How Privilege Escalation Happens?
A typical exploitation scenario:
Role Misuse - A user or attacker with the "Key Vault Contributor" role modifies the key vault’s access policies.
Granting Data Access - They add new permissions, such as "Get," "List," or "Decrypt," for themselves or a compromised identity.
Data Exfiltration - With these elevated permissions, they can access secrets, keys, and certificates stored in the vault and exfiltrate data.
Real-World Risks
Data Exposure
An attacker or malicious insider with "Key Vault Contributor" permissions can modify access policies to grant themselves "Get" or "List" permissions. This enables unauthorized access to secrets, keys, or certificates stored within the vault.
Impact
Compromised Credentials: Exposed secrets, such as API keys, database connection strings, and tokens, can lead to unauthorized access to other systems.
Leaked Cryptographic Keys: Attackers gaining access to cryptographic keys can decrypt sensitive data or impersonate systems.
Data Breaches: Public disclosure or exploitation of these secrets can result in major data breaches.
Compromised Cloud Workloads
Many Azure resources rely on Azure Key Vault for secrets and credentials. If an attacker accesses the vault, they can use those credentials to compromise workloads such as virtual machines, applications, or containerized environments.
Impact
Unauthorized Application Access: Secrets used by Azure App Services or Functions can be extracted and used to interact with production systems.
Disruption of Operations: With stolen credentials, attackers can alter configurations or disrupt services, causing operational downtime.
Service Abuse: Using stolen secrets, attackers could rack up significant costs by deploying unauthorized resources under the compromised account.
Persistent Backdoors
An attacker could alter the access policies to create persistent backdoors by granting permissions to additional accounts or service principals under their control.
Impact:
Stealthy Persistence: Attackers could maintain long-term access to the vault and its secrets even after initial detection.
Repeated Data Exfiltration: Persistent access enables attackers to periodically extract updated secrets, ensuring continuous exploitation.
Compromised Recovery Efforts: During incident recovery, attackers can use the backdoor to disrupt remediation efforts or regain access to compromised systems.
Microsoft's Response
Upon disclosure, Microsoft classified this behaviour as "by design" and updated their documentation to clarify the capabilities of the Key Vault Contributor role. The updated guidance emphasizes that this role can modify access policies and recommends using the Azure RBAC permission model to mitigate such risks.
Lessons Learned
To address this vulnerability, organizations should adopt a combination of technical controls and best practices:
Transition to Azure RBAC
Replace traditional access policies with Azure Role-Based Access Control (RBAC). RBAC offers better granularity and is integrated with Azure's logging and monitoring systems.
Restrict Role Assignments
Minimize the use of the "Key Vault Contributor" role and assign it only to users or systems requiring explicit management capabilities.
Use custom roles to enforce stricter separation between management and data access permissions.
Enable Logging and Monitoring
Turn on Azure Monitor logs for key vaults and monitor for unusual changes to access policies.
Set up alerts for unauthorized modifications to access policies or suspicious access attempts.
Review and Audit Access Policies Regularly
Periodically review who has permissions to modify access policies and ensure that they align with the principle of least privilege.
Implement Just-In-Time Access with Azure PIM
Use Privileged Identity Management (PIM) to enforce time-bound access to roles like "Key Vault Contributor," reducing the window for potential misuse.
Conduct Security Assessments
Perform regular vulnerability scans and penetration tests on your Azure environment to identify and address misconfigurations.
Conclusion
The Azure Key Vault privilege escalation incident highlights the importance of robust role design and access control mechanisms. Misconfigured permissions can have far-reaching consequences, including access to Non-Human Identities including API Keys, Tokens, Certificates, Passwords, allowing threat actors to compromise sensitive data and critical systems.
By adopting security best practices, leveraging Azure RBAC, and continuously monitoring access configurations, organizations can mitigate the risks associated with this vulnerability and ensure their Azure environments remain secure.