Microsoft Patches Azure Active Directory Private Key Data Vulnerability

Microsoft Patches Azure Active Directory Private Key Data Vulnerability

Microsoft recently made changes to Azure Active Directory (Azure AD) to mitigate an issue where private key data stored in an Azure AD application or service principal could be read in clear text. Some Azure services were incorrectly storing private key data in Azure AD in the keyCredentials property when creating applications for customers.

Microsoft has been investigating the issue and didn’t find evidence of malicious activity.

What is the Azure AD keyCredentials property?

The keyCredentials property in Azure AD is meant for storing a certificate with public key data for use in application authentication. Microsoft says that certificates with private key data could have also been stored in the keyCredentials property.

Public keys are designed for ‘public’ consumption and it’s normal that read access should be given. But private keys should always be safeguarded.

To mitigate the keyCrednentials property issue in Azure AD, Microsoft says:

Microsoft Azure services affected by this issue have mitigated by preventing storage of clear text private key information in the keyCredentials property, and Azure AD has mitigated by preventing reading of clear text private key data that was previously added by any user or service in the UI or APIs.

Microsoft Azure products and services affected by the Azure AD keyCredentials property vulnerability

In the table below, you’ll find a summary of the affected Azure products and services, including links to Microsoft’s official remediation guidance.

Table 1 – Products and services affected by the private key data vulnerability

Product or service Mitigation Impact and remediation
Azure Automation Update deployed to service to mitigate clear text in private key data.

 

Run As accounts that were created or renewed after October 15th 2021 aren’t impacted.

Run As created with an Azure Automation self-signed certificate, between October 15th 2020 and October 15th 2021, and that have not been renewed are affected.

 

Customers using their own certificates might also be affected.

 

If you need to mitigate this issue with Run As accounts, check out Microsoft’s Azure Automation RunAs account remediation guidance.

Azure Migrate Update deployed to stop private key data in clear text being uploaded to Azure AD applications. Azure Migrate appliances registered before November 2nd 2021 and/or appliances registered after November 2nd 2021, where auto-update was disabled, might be affected.

 

Check Microsoft’s Azure Migrate application credential assessment and remediation guidance on GitHub.

Azure Site Recovery (ASR) Update deployed to prevent private key data being uploaded to Azure AD applications.

 

Azure Site Recovery customers using the preview experience “VMware to Azure Disaster Recovery” after November 1st 2021 are not impacted.

If you have deployed and registered the preview version of VMware to Azure DR experience with ASR before November 1st 2021, you might be affected.

Read Microsoft’s Azure Site Recovery application credential rotation guide on GitHub if you need to remediate this issue.

Azure AD applications and Service Principals with private key data in clear text. Private key data can longer be read. The change was made October 30th 2021. Follow Microsoft’s Credential health assessment and update procedures for Azure Automation, Azure Migrate, Azure Site Recovery and Azure AD applications on GitHub if you need to remediate this issue.

Additional audit and investigation

Microsoft recommends organizations audit and investigate applications for unexpected use. Here is a summary of Microsoft’s advice to mitigate the keyCredentials property vulnerability:

  1. Audit permissions granted to impacted identities.
  2. Investigate unexpected use of credentials for application or service principals where the credential was rotated.
  3. Check sign-in logs, Azure AD audit logs, and Microsoft 365 audit logs for odd activity, like sign-ins from unexpected IP addresses or IP address ranges.
  4. Use Azure Sentinel to surface malicious activity.

Microsoft acknowledges NetSPI’s Karl Fosaaen, who reported the vulnerability. And Allscripts, who worked with the Microsoft Security Response Center (MSRC).

Related articles