Key Vault
Last updated
Last updated
Key vault is Azure's service for storing secrets such as passwords, connection strings, certificates, private keys etc. With the right permissions and access, Azure resources that support managed identities (VM's App service, Functions, containers). can securely retrieve secrets from the key vault.
Objects in a key vault are identified using a Object identifier URL. The base URL is of the format:
The vault-name is globally unique. And the object-type can be "keys", "secrets" or "certificates".
Key Vaults support RBAC and access policies. So for role assignments, a application can have the "Key Vault Secrets User" or "Key Vault Administrator".
Do not use access policies for key vaults from a defense perspective! This is because access policies can be edited by other roles other than the owner of the key vault, such as contributor.
If we can compromise an azure resource whose managed identity can read secrets from a key vault, it may be possible to gain access to more resources. Note that each secret has its own IAM inherited from the key vault.
Roles who can access secrets
We have a App Service that is vulnerable to Jinja2 SSTI. We get a access token from vault.azure.net:
Also, we will need to get a access_token for ARM:
We connect with Az Cli using both tokens:
Next, check if we have at least a reader role on a key vault:
Check if we can read Secrets:
Finally, extract secret as plain text:
Use it to connect to Az Cli:
