Windows 10: Guidance to mitigate unconstrained delegation vulnerabilities

Brink · Feb 12, 2019

Executive Summary

Active Directory Forest trusts provide a secure way for resources in a forest to trust identities from another forest. This trust is directional; a trusted forest can authenticate its users to the trusting forest without allowing the reverse. 

A feature, Enforcement for forest boundary for Kerberos full delegation, was introduced in Windows Server 2012 that allows an administrator of the trusted forest to configure whether Ticket-Granting Tickets (TGTs) may be delegated to a service in a trusting forest. 

An unsafe default configuration for this feature exists when setting up inbound trusts that lets an attacker in the trusting forest request delegation of a TGT for an identity from the trusted forest. 

This advisory addresses the issue by recommending a new safe default configuration for unconstrained Kerberos delegation across Active Directory forest trusts that supersedes the original unsafe configuration.

Recommended Actions

Customers should review Knowledge Base Article 4490425 and take appropriate action.

The enforcement for forest boundary for Kerberos full delegation will be available as an update for all supported versions of Windows Server starting in the March 2019 Security Update and is currently available for Server 2012 and newer. We recommend that you set the feature on incoming forest trusts.

FAQ

1. What is unconstrained delegation?
Unconstrained delegation is when a service can acquire a copy of your TGT to act on your behalf when authenticating to other services. Unconstrained delegation lets the service authenticate to any other service which can lead to security issues such as elevation of privilege. Unconstrained delegation has been replaced by constrained delegation which limits which services can receive tickets on behalf of a user.

2. What is TGT delegation?
TGT delegation allows a service to acquire a TGT from a domain with an inbound trust. This allows any service within an untrusted forest to acquire a TGT to the trusted forest. A feature was introduced in Windows Server 2012 to disable this capability.

3. Why is TGT delegation enabled by default?
Applications may rely on unconstrained delegation across inbound trusts and disabling delegation may lead to outages.

4. How do I determine if TGT delegation is enabled?
You can check that the flag is set on the trust using PowerShell.

Get-AdTrust -filter {Direction -eq "Inbound" -and TGTDelegation -eq $true}

5. How do I disable TGT delegation?
You can set the EnableTGTDelegation to NO using Netdom. See the KB article for more details.

netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No

6. What is the security risk of leaving TGT delegation enabled?
If an attacker can enable unconstrained delegation of any principal in an untrusted forest and request a service ticket to the trusted forest, they can also request a TGT from the trusted forest. An attacker can then impersonate the user in the trusted forest from within the untrusted forest leading to elevation of privilege.

Security Updates

To determine the support life cycle for your software version or edition, see the Microsoft Support Lifecycle.

Product Platform Article Download Impact Severity Supersedence Windows 10 for 32-bit Systems None None Windows 10 for x64-based Systems None None Windows 10 Version 1607 for 32-bit Systems None None Windows 10 Version 1607 for x64-based Systems None None Windows 10 Version 1703 for 32-bit Systems None None Windows 10 Version 1703 for x64-based Systems None None Windows 10 Version 1709 for 32-bit Systems None None Windows 10 Version 1709 for 64-based Systems None None Windows 10 Version 1709 for ARM64-based Systems None None Windows 10 Version 1803 for 32-bit Systems None None Windows 10 Version 1803 for ARM64-based Systems None None Windows 10 Version 1803 for x64-based Systems None None Windows 10 Version 1809 for 32-bit Systems None None Windows 10 Version 1809 for ARM64-based Systems None None Windows 10 Version 1809 for x64-based Systems None None Windows 7 for 32-bit Systems Service Pack 1 None None Windows 7 for x64-based Systems Service Pack 1 None None Windows 8.1 for 32-bit systems None None Windows 8.1 for x64-based systems None None Windows RT 8.1 None None Windows Server 2008 for 32-bit Systems Service Pack 2 None None Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation) None None Windows Server 2008 for Itanium-Based Systems Service Pack 2 None None Windows Server 2008 for x64-based Systems Service Pack 2 None None Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation) None None Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1 None None Windows Server 2008 R2 for x64-based Systems Service Pack 1 None None Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) None None Windows Server 2012 None None Windows Server 2012 (Server Core installation) None None Windows Server 2012 R2 None None Windows Server 2012 R2 (Server Core installation) None None Windows Server 2016 None None Windows Server 2016 (Server Core installation) None None Windows Server 2019 None None Windows Server 2019 (Server Core installation) None None Windows Server, version 1709 (Server Core Installation) None None Windows Server, version 1803 (Server Core Installation) None None
Mitigations

Microsoft has not identified any mitigating factors for this vulnerability.

Workarounds

Microsoft has not identified any workarounds for this vulnerability.

Acknowledgements

Roberto Rodriguez (@Cyb3rWard0g) of SpecterOps

Will Schroeder (@harmj0y) of SpecterOps

Lee Christensen (@tifkin_) of SpecterOps

See acknowledgements for more information.

Disclaimer

The information provided in the Microsoft Knowledge Base 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

Version Date Description 1.0 02/12/2019 Information published.
Click to expand...

Source: https://portal.msrc.microsoft.com/en...sory/ADV190006

:)

t0yz · Feb 12, 2019

Mitigating the last "L1 terminal fault" vulnerabilities - possible or not?

Hi,

The post here may help explain how to interpret what "hardware is vulnerable to L1 terminal fault" means: https://support.microsoft.com/en-us...-of-get-speculationcontrolsettings-powershell

In short, this line will always report as True if the hardware is believed to be vulnerable to L1 terminal fault, even if the mitigation is enabled. The important part is the line that refers to "L1 terminal fault mitigation is enabled", which in your screenshot
reports as True. This indicates that the mitigation is enabled and that this device is protected from CVE-2018-3620.

Hope that helps,

Matt Miller

Microsoft Security Response Center
Click to expand...

I've read that, thanks.

If what you saying is true, this is a departure from how previous vulnerabilities were described, and just adds confusion. The previous way of doing it made far more sense, you could see if the necessary hardware (microcode) was there and if the mitigation
is enabled&working.

With this formulation, it suggests that the hardware is vulnerable, and that's it. Yes you applied the mitigations, but... hardware is still found to be vulnerable.

The whole reason we apply these mitigations is to patch the vulnerable hardware and achieve a non-vulnerable state. You don't want to see that you're still vulnerable with all mitigations in place.

mamill MSFT · Feb 12, 2019

Mitigating the last "L1 terminal fault" vulnerabilities - possible or not?

Hi,

The post here may help explain how to interpret what "hardware is vulnerable to L1 terminal fault" means: https://support.microsoft.com/en-us...-of-get-speculationcontrolsettings-powershell

In short, this line will always report as True if the hardware is believed to be vulnerable to L1 terminal fault, even if the mitigation is enabled. The important part is the line that refers to "L1 terminal fault mitigation is enabled", which in your screenshot
reports as True. This indicates that the mitigation is enabled and that this device is protected from CVE-2018-3620.

Hope that helps,

Matt Miller

Microsoft Security Response Center

Brink · Feb 12, 2019

Surface Guidance for speculative execution side-channel vulnerability

Surface Guidance to protect against speculative execution side-channel vulnerabilities

Applies to: Surface Pro 4, Surface Book, Surface Studio, Surface Pro (latest), Surface Laptop, Surface Pro with LTE Advanced, Surface Book 2 - 13 inch, Surface Book 2 - 15 inch

Introduction

Since January 2018, the Surface team has been publishing firmware updates for a new class of hardware vulnerabilities that involve speculative execution side channels. The Surface team has not received any information to indicate that these vulnerabilities have been used to attack customers currently, and the team continues to work closely with the Windows team and industry partners to protect customers. To get all available protection, both firmware and Windows system updates are required.

Summary

Vulnerabilities Announced in May 2018
The Surface team has become aware of new speculative execution side-channel attack variants that also affect Surface products. Mitigation of those vulnerabilities requires UEFI updates that use new microcode. For more information about the vulnerabilities and mitigations, see the following security advisories:

Microsoft Security Advisory ADV180012

Microsoft Security Advisory ADV180013

We are working with our partners to provide updates to the following Surface products as soon as we can make sure that the updates meet our quality requirements:

Surface Book 2

Surface Book

Surface Laptop

Surface Studio

Surface Pro 4

Surface Pro 3

Surface Pro Model 1796 and Surface Pro with Advanced LTE Model 1807

References

CVE-2018-3640

CVE-2018-3639

Vulnerabilities Announced in January 2018
The Surface team is aware of the publicly disclosed class of vulnerabilities that involve speculative execution side channels (known as Spectre and Meltdown) that affect many modern processors and operating systems, including Intel, AMD, and ARM. For more information about the vulnerabilities and mitigations, see the following security advisory:

Microsoft Security Advisory ADV180002

For more information about Windows software updates, see the following Knowledge Base articles:

4073757 Protect your Windows devices against Spectre and Meltdown vulnerabilities

4073119 Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities

In addition to installing the January 3 Windows Operating System Security Updates, Surface has released UEFI updates through Windows Update and the Download Center for the following devices:

Surface Book 2 - (Update history)

Surface Book - (Update history)

Surface Laptop - (Update history)

Surface Studio - (Update history)

Surface Pro 4 - (Update history)

Surface Pro 3 - (Update History)

Surface Pro Model 1796 and Surface Pro with Advanced LTE Model 1807- (Update History)

These updates are available for devices that are running Windows 10 Creators Update (build 15063) and later versions.

References

CVE-2017-5753

CVE-2017-5715

CVE-2017-5754

More Information

Note Surface hub has implemented defense-in-depth strategies. For more information, go to the following topic on the Microsoft website:

Differences between Surface Hub and Windows 10 Enterprise

Because of this, we believe that exploits that use these vulnerabilities are significantly reduced on Surface Hub.

The Surface team is focused on making sure that our users have a secure and reliable experience. We will continue to monitor and update devices as required to address these vulnerabilities and keep the device reliable and secure.
Click to expand...

Source: https://support.microsoft.com/en-us/...n-side-channel

See also: Surface devices and the new speculative execution side-channel vulnerabilities (May 2018) Surface

Windows 10: Guidance to mitigate unconstrained delegation vulnerabilities

Guidance to mitigate unconstrained delegation vulnerabilities

Guidance to mitigate unconstrained delegation vulnerabilities

Guidance to mitigate unconstrained delegation vulnerabilities

Guidance to mitigate unconstrained delegation vulnerabilities - Similar Threads - Guidance mitigate unconstrained

Microsoft publishes mitigation instructions for Downfall vulnerability in Windows

About emulating SCSI and Vulnerabilities mitigation fixes

Mitigating the last "L1 terminal fault" vulnerabilities - possible or not?

Surface Guidance for speculative execution side-channel vulnerability

SQL Server Guidance against speculative execution vulnerabilities

Mitigating speculative execution side channel hardware vulnerabilities

Azure Stack Guidance against speculative execution vulnerabilities

Windows Server Guidance against speculative execution vulnerabilities

Windows Client Guidance against speculative execution vulnerabilities

Users found this page by searching for:

DISABLE-TGT-DELEGATION

microsoft kerberos unconstrained delegation security advisory

Addresses an issue that may prevent applications that rely on unconstrained delegation from authenticating after the Kerberos ticket-granting ticket vulnerability in Windows 2008