Microsoft Security Advisory 4092731

  • Article

Update to Azure Cloud Services Machine Key Generation Algorithm

Published: May 8, 2018 | Updated June 29, 2018

Version: 1.2

Executive Summary

Microsoft is releasing this security advisory to provide information related to an update in the way the machine keys are generated for Azure Cloud Services. This scenario may affect customers who are using Azure Cloud Services Web Roles. The machine keys on existing deployments have been generated with insufficient entropy and using deprecated cryptographic algorithms.

To address this issue, Microsoft released an update to the algorithm being used to generate machine keys in new Azure Cloud Services Web Role deployments, including the use of cryptographically-strong random number generation. All existing Web Roles will retain their previously generated machine keys unless re-deployed. Given certain detailed information, an attacker may be able to guess machine keys created by the deprecated algorithm. Vulnerable machine keys may, in some circumstances, allow security feature bypass.

This advisory provides guidance for customers to identify whether they are affected by this scenario and what, if any, actions they need to take.

Affected cloud services

Azure deployments that use Web Roles are impacted by this issue. The only exception is if you provided your own machine key in the Web.config in the CS Package. Azure Worker Roles, Virtual Machines, and all other Azure offerings are not affected.

Frequently asked questions

1. How do I know if I am affected?

All Azure Cloud Service Web Roles are impacted by this issue, except if you provided your own machine keys in the Web.config in the CS Package. Azure Cloud Service Worker Roles, Virtual Machines, and all other Azure offerings are not affected.

ASP.NET uses machine keys for several purposes including:

  • Anti-tampering with web form viewstate data
  • Generation and validation of ASP.NET Web Form session cookies
  • Anti-CSRF tokens
  • Encryption using the machinekey.protect and machinekey.unprotect methods.

2. Are there any prerequisites to fixing my affected application?

Yes, if your Web Role was deployed with a retired version of Azure SDK for .Net, it will not use the enhanced Machine Key Generation Algorithm. Please reference https://azure.microsoft.com/en-us/downloads/archive-net-downloads/ for supported versions. To upgrade to a supported version, please click the link on the previously referenced site to download and redeploy your project with a supported SDK version. Once you have validated that your project is deployed with a supported SDK, follow the additional steps in this advisory.

3. How do I fix my affected application?

To generate the new machine keys, you need to redeploy your .cspkg and .cscfg as a new Cloud Service, deploy your workload in the staging slot and perform a swap deployment (VIP Swap), or inject your own machine keys and then perform a simultaneous upgrade. A typical update deployment operation will not be sufficient. The following describes the high level mitigation options and detailed steps are outlined below:

Option 1: Deploy your workload to a new cloud service. Update your CNAME to point traffic to your new cloud service. When zero traffic is going to the old site, you can delete the old cloud service.

Option 2: Deploy your Cloud Service to the staging slot and perform a swap deployment.

Option 3: Generate your own machine keys in Web.config and perform a simultaneous update. This will update all instances at once and therefore will cause application downtime.

We recommend that you use Option 1 to avoid downtime. We also recommend that you perform the mitigation during low utilization periods, because sessions can be disrupted while the machine keys change.

Note: The IP address of your application will change once you obtain the new machine keys with Option 1 and Option 2.

4. I’ve used the machine key to encrypt persistent data using MachineKey.Encode()/MachineKey.Protect(). How do I recover the data?

If the MachineKey was used to encrypt data ( using MachineKey.Encode()/MachineKey.Protect() ) then the old machine key and algorithms defined in the web.config must be used to decrypt the data ( by calling MachineKey.Decode()/MachineKey.Unprotect() respectively ) before performing the mitigation steps. Once the mitigation steps are completed, any calls to MachineKey.Encode()/MachineKey.Protect() and MachineKey.Decode()/MachineKey.Unprotect() will use the updated machine key and algorithms from the web.config.

5. How do I know my application is using the new machine key algorithm?

If you have only one deployment in your cloud service, checking to see the Azure Machine Key certificate on your Certificate tab of your Cloud Service in the Azure Management Portal will suffice. If this certificate is present, your deployment is using the machine key algorithm.

If you have two deployments in your cloud service (production and staging), you will need to remote desktop into your web roles and look at the IIS Configuration. If you see the machine key certificate, you are using the new machine key algorithm. You will need to do this check for one web role in each deployment. If you are not able to connect to the VM, please file a support ticket (instructions in #7) and our support team can help confirm if your deployments are using the new machine key.

Azure Certificates

6. What is the "Microsoft Azure Service Management for MachineKey" certificate?

This is the certificate that is used to encrypt the machine keys together with the enhanced algorithm.

7. Who manages the "Microsoft Azure Service Management for MachineKey" certificate, and what happens when it expires?

Azure manages this certificate. Customers do not need to be concerned about the expiration date of this certificate because it is used once to generate the new machine keys with the new algorithm. The expiration date will not cause any impact.

8. Can the certificate be deleted or removed from the VM?

No, the certificate cannot be removed.

9. If I have questions about the mitigation steps, what can I do?

Please submit a support case under Cloud Services using your standard escalation process. To escalate in the Azure Portal, follow these steps:

  1. Go to Help + Support in the Azure Portal.
  2. Select the Technical issue type.
  3. Select your subscription, and then select the Cloud Services (Web roles/Worker roles) service in Services.
  4. Click Next , choose MachineKey Certificate Update as the problem type and and then fill out the details of the support ticket.

Detailed steps to perform the mitigation

Option 1: Re-deploy your cloud service.

  1. Perform a redeployment via Portal:

    1. Create a new cloud service with your .cspkg and .cscfg. See details here.
    2. Update the CName or A record to point traffic to the new cloud service.
    3. Delete your old cloud service after your traffic is pointing to the new Cloud Service.

  2. Perform a redeployment via PowerShell:

    1. Create a new cloud service with your .cspkg and .cscfg. See details here.

      Example: New-AzureService -ServiceName "yourServiceName" -Label "MyTestService" -Location "South Central US"

    2. Create a new deployment with your .cspkg and .cscfg. See details here.

      Example: New-AzureDeployment -ServiceName "yourServiceName" -Slot "Production" -Package "YourCspkgFile.cspkg" -Configuration "YourConfigFile.cscfg"

    3. Update the CName or A record to point traffic to the new cloud service.

    4. Delete your previous cloud service that does not have updated machine keys after your traffic is pointing to the new Cloud Service. See details here.

      Example: Remove-AzureService -ServiceName "yourOldServiceName"

  3. Perform a redeployment via Rest API:

    1. Create a new cloud service. See details here.

      Example: https://management.core.windows.net/<subscription-id>/services/hostedservices

    2. Create a new deployment by using the create deployment API. If you need to find your .cspkg and .cscfg, you can call Get-Package API).

      Example: https://management.core.windows.net/<subscription-id>/services/hostedservices/<cloudservice-name>/deploymentslots/production

    3. Delete your previous cloud service that does not have updated machine keys after your traffic is pointing to the new Cloud Service. See details here.

      Example: https://management.core.windows.net/<subscription-id>/services/hostedservices/<old-cloudservice-name>

Option 2: Swap Deployment.

Using option 2 requires you to have an empty staging slot. If you have a deployment in the staging slot currently, you can delete it and then follow these steps:

  1. Perform the Swap Deployment via Portal:

    1. Update your Cloud Service deployment by uploading your .cspkg and .cscfg in the staging slot. This will contain the new certificate to generate the machine keys. See details here.

    2. Swap your production and staging slots. See details here.

    3. Delete your staging slot with your previous production deployment. See details here

  2. Perform the Swap Deployment via PowerShell.

    1. Deploy your cspkg and cscfg in the Staging slot. See details here.

      Example: New-AzureDeployment -ServiceName "yourServiceName" -Slot "Staging" -Package "YourCspkgFile.cspkg" -Configuration "YourConfigFile.cscfg"

    2. Swap your production and staging slots. See details here.

      Example: Move-AzureDeployment -ServiceName "yourServiceName"

    3. Delete your staging slot with your previous production deployment.

      Example: Remove-AzureDeployment -ServiceName "yourServiceName" -Slot "Staging"

  3. Perform the Swap Deployment via Rest API:

    1. Create a new deployment in the staging slot using the create deployment API. If you need to find your .cspkg and .cscfg, you can call Get-Package API).

      Example: https://management.core.windows.net/<subscription-id>/services/hostedservices/<cloudservice-name>/deploymentslots/staging

    2. Swap your production and staging slots by using Swap Deployment.

      Example: https://management.core.windows.net/<subscription-id>/services/hostedservices/<cloudservice-name>

    3. Delete your staging slot with your previous production deployment

      Example: https://management.core.windows.net/<subscription-id>/services/hostedservices/<cloudservice-name>/deploymentslots/staging

Option 3: Generate your own machine keys in the Web.config and perform a simultaneous deployment.

  1. Generate new machine key XML element in PowerShell (see Appendix A).

  2. Update your WebConfig with the new machine keys. See instructions.

  3. Repackage your cloud service.

  4. Perform an upgrade-deployment by using the .cscfg file that contain the new machine keys. The mode must be set to simultaneous, or this could cause your application to be in an unhealthy state.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

Revisions

  • V1.0 (May 8, 2018): Advisory published.
  • V1.1 (May 24, 2018): Added FAQ #4 to explain how to recover persistent data after the data is encrypted using MachineKey.Encode()/MachineKey.Protect(). This is an informational change only.
  • V1.2 (June 29, 2018): Changed references of Azure Guest OS to Azure Cloud Services