Описание
Microsoft Guidance for cleaning up orphaned keys generated on vulnerable TPMs and used for Windows Hello for Business
Microsoft is aware of an issue in Windows Hello for Business (WHfB) with public keys that persist after a device is removed from Active Directory, if the AD exists. After a user sets up Windows Hello for Business (WHfB), the WHfB public key is written to the on-premises Active Directory. The WHfB keys are tied to a user and a device that has been added to Azure AD, and if the device is removed, the corresponding WHfB key is considered orphaned. However, these orphaned keys are not deleted even when the device it was created on is no longer present. Any authentication to Azure AD using such an orphaned WHfB key will be rejected. However, some of these orphaned keys could lead to the following security issue in Active Directory 2016 or 2019, in either hybrid or on-premises environments.
An authenticated attacker could obtain orphaned keys created on TPMs that were affected by CVE-2017-15361 (ROCA), discussed in Microsoft Security Advisory ADV170012 to compute their WHfB private key from the orphaned public keys. The attacker could then impersonate the user by using the stolen private key to authenticate as the user within the domain using Public Key Cryptography for Initial Authentication (PKINIT).
This attack is possible even if firmware and software updates have been applied to TPMs that were affected by CVE-2017-15361 because the corresponding public keys might still exist in Active Directory.
This advisory provides guidance for cleaning up any orphaned public keys that were generated with an unpatched TPM (before firmware updates discussed in ADV170012 were applied). Follow this guidance to identify and remove orphaned WHfB keys.
This particular issue with orphaned public keys can be present when WHfB is set up in the following configurations:
- WHfB is deployed on Active Directory 2016 or 2019, either in hybrid mode or on-premises only.
- Currently have or have had in the past, WHfB keys generated on TPMs that were affected by CVE-2017-15361.
Important: Azure Active Directory (Azure AD) and Active Directory Federation Services (AD FS) are not affected by this issue. However, we strongly recommend that you follow the Recommended Actions section of ADV170012, and apply any firmware updates supplied by your TPM OEM, to avoid any exposure to Azure AD and AD FS. See Step #4 of the Recommended Actions for a list of OEMs and links to information for their updates.
Меры по смягчению последствий
Follow these steps to mitigate the issue with orphaned WHfB keys in your environment:
- Ensure your TPMs affected by CVE-2017-15361 are patched. See Microsoft Security Advisory ADV170012 for details.
- Install the WHfBTools Windows PowerShell module. See WHfBTools.
Use the WHfBTools PowerShell scripts to identify and remove keys, which will differ depending on whether your environment is a hybrid environment or an on-premises only environment. See Using WHfBTools PowerShell module for cleaning up orphaned Windows Hello for Business Keys for instructions for complete instructions.
- Query your environment for orphaned WHfB keys and for keys affected by CVE-2017-15361 (ROCA).
- You can then do one of the following, using the appropriate PowerShell script:
- Delete orphaned WHfB keys.
- Delete keys affected by CVE-2017-15361. Important Be aware that if you delete ROCA vulnerable WHfB keys that are not orphaned yet, it will cause disruption to your users. You should ensure that these keys are orphaned before removing them from the directory.
- Delete both orphaned keys and keys affected by CVE-2017-15361.
The scripts you will use to identify and remove keys differ depending on whether your environment is a hybrid environment or an on-premises only environment. See Using WHfBTools PowerShell module for cleaning up orphaned Windows Hello for Business Keys for instructions.
Hybrid environment:
A hybrid environment consists of Active Directory 2016 or 2019, with synchronization to Azure AD with or without AD FS.
Note
- If you haven’t updated your TPM first, simply deleting these keys from the directory is not sufficient to mitigate the issue. Setting up WHfB again will re-create keys that are affected by CVE-2017-15361.
- Deleting keys in Azure AD will automatically remove them in Active Directory as part of the synchronization process between Active Directory and Azure AD. If you are in a hybrid environment deleting the keys from only Active Directory is not sufficient as they will be re-written from Azure AD as a part of the synchronization process.
On-premises only environment:
An on-premises only environment consists of Active Directory 2016 or 2019, both with AD FS.
Note
If you haven’t updated your TPM first, deleting these keys from the directory is not sufficient to mitigate the issue. Setting up WHfB again will re-create keys that are affected by CVE-2017-15361.
FAQ
1. What systems are at risk?
Individual machines or servers are not affected by this WHfB issue. Affected environments are defined in the Mitigations section of this advisory.
2. Has this issue been publicly disclosed?
Yes, this issue has been disclosed.
3. Have there been any active attacks detected?
No. When this security advisory was issued, Microsoft had not received any information to indicate that this issue had been publicly used to attack customers.
4. How do I know if my TPMs are affected by CVE-2017-15361? How do I fix them?
Please refer to Microsoft Security Advisory ADV170012 for more details on CVE-2017-15361. You must follow the guidance in ADV170012 and update your TPMs before applying the mitigations for identifying and removing the orphaned public keys.
5. I have updated all of my TPMs that were affected by CVE-2017-15361 with firmware provided by the OEM. Are my systems still affected?
Yes. Orphaned WHFB keys previously generated from those TPMs could still be stored in Active Directory.
6. My TPMs are not affected by CVE-2017-15361, but I do not enforce a policy to use TPMs for WHfB. Am I still affected?
In the absence of a hardware-required policy, WHFB will prefer using the TPM for storing the private key. If you do not have any TPMs that are affected by CVE-2017-15361, then you are not impacted. However, we recommend removing any orphaned keys in your directory by following the steps discussed in the Mitigations section of this advisory.
7. I am running pre-2016 versions of Active Directory. Do I also need to remove these orphaned keys?
While you are not affected by this WHFB issue, we strongly recommend removing these orphaned keys as a security hygiene measure.
8. I regularly audit and clean up stale devices in my environment. How did I end up with orphaned keys?
When a user provisions a WHFB credential, the public key is stored in the msDS-KeyCredentialLink attribute of the user object in Azure AD and on-premises Active Directory. If the device that was used to create the key is removed from Azure AD and Active Directory, the WHFB public key created for the user on that device is not automatically removed from the user object and it becomes an orphaned key.
9. I have deployed WHFB certificate trust in my environment and use certificates for authentication. Am I affected? Do I need to remove orphaned keys?
Yes. You are still affected by this issue if you have deployed certificate trust and have 2016 or 2019 DCs in your environment. These DC versions still support key-based authentication even if you have deployed end user certificates for authentication.
Возможность эксплуатации
Publicly Disclosed
Exploited