none
CVE-2020-1472 | Netlogon Elevation of Privilege Vulnerability - Clarification needed RRS feed

  • Question

  • Hi

    With this latest vulnerability, i need some clarification about what exactly is a "Non-Compliant Device".

    In the KB articles definition, A non-compliant device is one that uses a vulnerable Netlogon secure channel connection.

    So that means, lets say you have a Windows machine, that has not been patched correctly, and still uses vulnerable netlogon connection.

    So once the DC is patched for this vulnerability, what will happen to this Windows machine?

    Will it get denied connection and be reported in event ID: 5827/5828?

    Or will it be allowed connection, as it is technically a non-compliant device based on the definition, as it is using vulnerable netlogon connection? And be logged under event ID: 5829?

    The other question i have is for the use of the GPO policy: "Domain controller: Allow vulnerable Netlogon secure channel connections"

    So i understand that this will bypass the enforcement.

    However, if the "Non-Compliant" device is not a windows device, i will assume that the GPO will not work for these devices. So when in enforcement phase, for these such non windows devices that is still using vulnerable netlogon connection, there is no workaround right? Either get vendor to provide a fix or decommission?

    Thanks DM.


    DM

    Wednesday, August 12, 2020 1:29 AM

Answers

  • Reading between the definitions in the glossary, a non-complaint device doesn't use secure RPC when making a netlogon secure channel connection to an Active Directory domain controller. 

    SC connections from windows devices are unlikely to be rejected after installing August 11, 2020 updates as Windows versions for the last decade have supported support secure RPC netlogon connections and the policy in #3 of "Steps 2b" has been enabled for years now.....

    1. Confirm that the device is running a supported versions of Windows.
    2. Ensure the device is fully updated.
    3. Check to ensure that Domain member: Digitally encrypt or sign secure channel data (always) is set to Enabled.

    Treat steps 1 and 2 as easy-to-follow due diligence with #3 as an unlikely culprit given that very few admins change the default. 

    Pay attention to events that indicate that sc connections for Windows devices are being rejected. But the real goal of the audit events added by CVE-2020-1472 is to identify other callers making vulnerable Netlogon secure channel connections. 

    Once you have identified those and addressed them using steps in "Addressing event 5829", you can set FullSecureChannelProtection = 1 in preparation for the next round of CVE-202-1472 updates that will reject those unsure connections by default. 

    • Edited by eventtrac Wednesday, August 12, 2020 4:41 PM
    • Marked as answer by D_M_K Thursday, August 13, 2020 1:43 AM
    Wednesday, August 12, 2020 4:29 PM
  • Recall that this is a DC side fix and defines what connections are allowed or rejected by the DC across release phases: 

    See section "2B' of https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc

    Step 2b:
    Addressing event IDs 5827 and 5828

    For non-Windows devices acting as a DC, these events will be logged in the system event log when using vulnerable Netlogon secure channel connections. If one of these events is logged:

    • Recommended Work with the device manufacturer (OEM) or software vendor to get support for secure RPC with Netlogon secure channel
      1. If the non-compliant DC supports secure RPC with Netlogon secure channel, then enable secure RPC on the DC.
      2. If the non-compliant DC DOES NOT currently support secure RPC, work with the device manufacturer (OEM) or software vendor to get an update that supports secure RPC with Netlogon secure channel.
      3. Retire the non-compliant DC.
    • Vulnerable If a non-compliant DC cannot support secure RPC with Netlogon secure channel before the DCs are in enforcement mode, add the DC using the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy described below.


    For managing the policy, create a security group like "CVE-2020-1472" then add that group to the "Create Vulnerable Connection" list in the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy 

    Add computer accounts hostname to the security group 
    This policy setting should be linked to a container hosting your domain controllers (like default domain controllers GPO ) 

    • Marked as answer by D_M_K Friday, August 14, 2020 11:33 AM
    Thursday, August 13, 2020 8:03 PM

All replies

  • Reading between the definitions in the glossary, a non-complaint device doesn't use secure RPC when making a netlogon secure channel connection to an Active Directory domain controller. 

    SC connections from windows devices are unlikely to be rejected after installing August 11, 2020 updates as Windows versions for the last decade have supported support secure RPC netlogon connections and the policy in #3 of "Steps 2b" has been enabled for years now.....

    1. Confirm that the device is running a supported versions of Windows.
    2. Ensure the device is fully updated.
    3. Check to ensure that Domain member: Digitally encrypt or sign secure channel data (always) is set to Enabled.

    Treat steps 1 and 2 as easy-to-follow due diligence with #3 as an unlikely culprit given that very few admins change the default. 

    Pay attention to events that indicate that sc connections for Windows devices are being rejected. But the real goal of the audit events added by CVE-2020-1472 is to identify other callers making vulnerable Netlogon secure channel connections. 

    Once you have identified those and addressed them using steps in "Addressing event 5829", you can set FullSecureChannelProtection = 1 in preparation for the next round of CVE-202-1472 updates that will reject those unsure connections by default. 

    • Edited by eventtrac Wednesday, August 12, 2020 4:41 PM
    • Marked as answer by D_M_K Thursday, August 13, 2020 1:43 AM
    Wednesday, August 12, 2020 4:29 PM
  • Eventtrac

    Thanks for the reply.

    One quick question on the GPO though, as a fall back option.

    Lets say then all Windows devices will be using SC connection.

    And then we find a third party device (non windows) triggering event id 5829.

    When the DC's are in enforcement phase for this patch, the GPO for the workaround wont make any different for the third party devices and GPO wont apply to them. Hence the only option is to fix it or ditch it i suppose?

    Thanks

    DM


    DM

    Thursday, August 13, 2020 1:47 AM
  • Recall that this is a DC side fix and defines what connections are allowed or rejected by the DC across release phases: 

    See section "2B' of https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc

    Step 2b:
    Addressing event IDs 5827 and 5828

    For non-Windows devices acting as a DC, these events will be logged in the system event log when using vulnerable Netlogon secure channel connections. If one of these events is logged:

    • Recommended Work with the device manufacturer (OEM) or software vendor to get support for secure RPC with Netlogon secure channel
      1. If the non-compliant DC supports secure RPC with Netlogon secure channel, then enable secure RPC on the DC.
      2. If the non-compliant DC DOES NOT currently support secure RPC, work with the device manufacturer (OEM) or software vendor to get an update that supports secure RPC with Netlogon secure channel.
      3. Retire the non-compliant DC.
    • Vulnerable If a non-compliant DC cannot support secure RPC with Netlogon secure channel before the DCs are in enforcement mode, add the DC using the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy described below.


    For managing the policy, create a security group like "CVE-2020-1472" then add that group to the "Create Vulnerable Connection" list in the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy 

    Add computer accounts hostname to the security group 
    This policy setting should be linked to a container hosting your domain controllers (like default domain controllers GPO ) 

    • Marked as answer by D_M_K Friday, August 14, 2020 11:33 AM
    Thursday, August 13, 2020 8:03 PM
    1. Is there a way to test nonsecure Netlogon RPC once we install the Aug 11 update on DC to make sure we are capturing the events?
    2. My understanding Aug 11 update is adding event monitoring only and Feb 2021 update is for enforcement, correct?
    3. Once DC in enforce mode via either Feb 2021 or by enabling FullSecureChannelProtection = 1, is the exception client will be still allowed for non secure RPC net logon that were added in “"Domain controller: Allow vulnerable Netlogon secure channel connections" group policy? I believe so but want to make sure.

    Thanks

    Friday, August 14, 2020 5:07 AM
  • Eventtrac

    Thanks for the clarification. Looks like all or nothing GPO setting if applied to DC.

    DM


    DM


    • Edited by D_M_K Friday, August 14, 2020 11:46 AM update
    Friday, August 14, 2020 11:34 AM