CVE-2020-1472 | Netlogon Elevation of Privilege Vulnerability

n elevation of privilege vulnerability exists when an attacker establishes a vulnerable Netlogon secure channel connection to a domain controller, using the Netlogon Remote Protocol (MS-NRPC). An attacker who successfully exploited the vulnerability could run a specially crafted application on a device on the network.

To exploit the vulnerability, an unauthenticated attacker would be required to use MS-NRPC to connect to a domain controller to obtain domain administrator access.

Microsoft is addressing the vulnerability in a phased two-part rollout. These updates address the vulnerability by modifying how Netlogon handles the usage of Netlogon secure channels.

For guidelines on how to manage the changes required for this vulnerability and more information on the phased rollout, see How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472.

When the second phase of Windows updates become available in Q1 2021, customers will be notified via a revision to this security vulnerability. If you wish to be notified when these updates are released, we recommend that you register for the security notifications mailer to be alerted of content changes to this advisory. See Microsoft Technical Security Notifications.

ProductPlatformArticleDownloadImpactSeveritySupersedence
Windows Server 2008 R2 for x64-based Systems Service Pack 14571729Monthly RollupElevation of PrivilegeCritical4565524
4571719Security Only
Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)4571729Monthly RollupElevation of PrivilegeCritical4565524
4571719Security Only
Windows Server 20124571736Monthly RollupElevation of PrivilegeCritical4565537
4571702Security Only
Windows Server 2012 (Server Core installation)4571736Monthly RollupElevation of PrivilegeCritical4565537
4571702Security Only
Windows Server 2012 R24571703Monthly RollupElevation of PrivilegeCritical4565541
4571723Security Only
Windows Server 2012 R2 (Server Core installation)4571703Monthly RollupElevation of PrivilegeCritical4565541
4571723Security Only
Windows Server 20164571694Security UpdateElevation of PrivilegeCritical4565511
Windows Server 2016 (Server Core installation)4571694Security UpdateElevation of PrivilegeCritical4565511
Windows Server 20194565349Security UpdateElevation of PrivilegeCritical4558998
Windows Server 2019 (Server Core installation)4565349Security UpdateElevation of PrivilegeCritical4558998
Windows Server, version 1903 (Server Core installation)4565351Security UpdateElevation of PrivilegeCritical4565483
Windows Server, version 1909 (Server Core installation)4565351Security UpdateElevation of PrivilegeCritical4565483
Windows Server, version 2004 (Server Core installation)4566782Security UpdateElevation of PrivilegeCritical4565503

Mitigations

Microsoft has not identified any mitigating factors for this vulnerability.

Workarounds

Microsoft has not identified any workarounds for this vulnerability.

FAQ

Do I need to take further steps to be protected from this vulnerability?

Yes. After installing the security updates released on August 11, 2020, you can deploy Domain Controller (DC) enforcement mode now or wait for the Q1 2021 update. See How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472 for more details.

If I install the updates and take no further action, what will be the impact?

During the initial deployment phase starting with the updates released August 11, 2020, the updates can be installed without added further action, and Windows devices and Domain Controllers (DCs) will be protected from this vulnerability. Organizations will need to monitor for and address potential issues before the Q1 2021 DC enforcement phase or risk devices being denied access. For more information, see How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472.

How does Microsoft plan to address this vulnerability?

Microsoft is addressing this vulnerability in a phased rollout. The initial deployment phase starts with the Windows updates released on August 11, 2020. The updates will enable the Domain Controllers (DCs) to protect Windows devices by default, log events for non-compliant device discovery, and have the option to enable protection for all domain-joined devices with explicit exceptions.

The second phase, planned for a Q1 2021 release, marks the transition into the enforcement phase. The DCs will be placed in enforcement mode, which requires all Windows and non-Windows devices to use secure Remote Procedure Call (RPC) with Netlogon secure channel or to explicitly allow the account by adding an exception for any non-compliant device.

What is a non-compliant device?

A non-compliant device is one that uses a vulnerable Netlogon secure channel connection.

Why is there a staged or phased rollout?

There are many non-Windows device implementations of the Netlogon Remote Protocol (also called MS-NRPC). To ensure that vendors of non-compliant implementations can provide customers with updates, a second release that is planned for Q1 2021 will enforce protection for all domain-joined devices.

Why do I need to follow the guidelines in How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472?

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.

The Latest Microsoft Windows vulnerability makes anyone an admin. Haven’t you updated Domain Controllers?

CVE-2020-1472, as the vulnerability is tracked, carries a critical severity rating from Microsoft as well as a maximum of 10 under the Common Vulnerability Scoring System. Exploits require that an attacker already have a foothold inside a targeted network, either as an unprivileged insider or through the compromise of a connected device.
An “insane” bug with “huge impact”

“This attack has a huge impact,” researchers with Secura wrote in a white paper published on Friday. “It basically allows any attacker on the local network (such as a malicious insider or someone who simply plugged in a device to an on-premise network port) to completely compromise the Windows domain. The attack is completely unauthenticated: the attacker does not need any user credentials.”

Vulnerability Details

The Netlogon protocol

The Netlogon Remote Protocol is an RPC interface available on Windows domain controllers. It is used for various tasks related to the user and machine authentication, most commonly to facilitate users logging in to servers using the NTLM protocol. Other features include the authentication of NTP responses, and notably: letting a computer update its password within the domain. The RPC interface is available over TCP through a dynamic port allocated to buy the domain controller’s ‘portmapper’ service, or through an SMB pipe on port 445. What’s interesting about this protocol is that it does not use the same authentication scheme as other RPC services. Instead, it uses a customized cryptographic protocol to let a client (a domain-joined computer) and server (the domain controller) prove to each other that they both know a shared secret. This shared secret is a hash of the client’s computer account password. The reason for this is that computer accounts did not use to be first-class principles in the Windows NT days, so they could not make use of standard user authentication schemes like NTLM or Kerberos.

Vulnerability DetailsThe Netlogon protocolThe Netlogon Remote Protocol is an RPC interface available on Windows domain controllers. It is used for various task related to user and machine authentication, most commonly to facilitate users logging in to servers using the NTLM protocol. Other features include the authentication of NTP responses, and notably: letting a computer update its password within the domain. The RPC interface is available over TCP through a dynamic port allocated buy the domain controller’s ‘portmapper’ service, or through an SMB pipe on port 445.What’s interesting about this protocol is that it does not use the same authentication scheme as other RPC services. Instead it uses a customized cryptographic protocol to let a client (a domain-joined computer) and server (the domain controller) prove to each other that they both know a shared secret. This shared secret is a hash of the client’s computer account password. The reason for this is that computer accounts did not use to be first-class principles in the Windows NT days, so they could not make use of standard user authentication schemes like NTLM or Kerberos.A Netlogon session is initiated by the client, whereby client and server exchange random 8-byte nonces (called client and server challenges) with each other. They both compute a session key by mixing both challenges with the shared secret using a key derivation function. Then the client uses this session key to compute a client credential. The server recomputes this same credential value and if it matches it is concluded that the client must know the session key, and therefore the client must also know the computer password. During the authentication handshake both parties can negotiate whether they want to seal and sign (encrypt and cryptographically authenticate) subsequent messages, which is essential to protect against network-level attackers. When encryption is disabled, all Netlogon calls that perform an important action must still contain an authenticator value that is also computed using the session key.

Core vulnerability: insecure use of AES-CFB8The cryptographic primitive both the client and server use to generate credential values is implemented in a function called ComputeNetlogonCredential, as defined in the protocol specification. This function takes an 8-byte input and performs a transformation on it with the secret session key that produces an output of equal length. The underlying assumption behind it is that an attacker who does not know the session key will not be able to calculate or guess the correct output matching a certain input, allowing it to be used to prove knowledge of the session key. There are two versions of this function: one based on 2DES and a newer version based on AES. Which one is used depends on flags set by the client during authentication. However, the default configuration of a modern version of Windows Server will reject any attempt to authenticate using the 2DES scheme. Therefore, in most domains only the AES scheme can be used. Interestingly, it is precisely this newer

After exchanging challenges with a NetrServerReqChallenge call, a client then authenticates itself by doing a NetrServerAuthenticate3 call. This call has a parameter called ClientCredential, and it is computed by applying the ComputeNetlogonCredential to the client challenge that was sent in the previous call. Since this challenge can actually be chosen arbitrarily by us, there’s nothing stopping us from setting this challenge to 8 zeroes. This means that for 1 in 256 session keys, the correct ClientCredential will also consist of 8 zeroes!So how do we know our session uses one of these keys? Well, we don’t. But every time we try to authenticate like this the server will still be generating a unique server challenge that will also be a parameter of the session key derivation. This means that the session key will be different (and uniformly distributed) for every authentication attempt. Since computer accounts are not locked after invalid login attempts, we can simply try a bunch of times until we hit such a key and authentication succeeds. The expected average number of tries needed will be 256, which only takes about three seconds in practice.With this method, we can log in as any computer in the domain. This includes backup domain controllers, and even the targeted domain controller itself!

Error 14144:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: PKCS7 while adding certificate to Wireless LAN Controllar (WLC)

While you try to create CSR and once Cisco WLC certificate is generated, try to import the certificate to WLC store, it throws below error.

WARNING: can’t open config file: C:/OpenSSL/openssl.cnf
OpenSSL> pkcs7 -print_certs -in SSLCert.p7b -out SSLCert.pem
unable to load PKCS7 object
14144:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: PKCS7

Solution:-

To fix this issue while you download the certificate from certificate authority server, just select the option Base 64 encoded certificate.

How to Migrate a Response Group from On-premises Skype for Business to MS Teams

Response groups services are been widely used as Interactive Voice Responses or Hunt Groups. In on-premises lync environment it is one of the key voice feature every organization depends on it.

Now due to the popularity and launch of MS Teams. migration becomes very essential to MS teams. So the question arise how you can safely migrate you on-premises RGS environment to MS Teams.

So to start with this, take a look on your RGS configuration in Response Group Configuration web console using the below lync.

https://poolFQDN.domain.com//RgsConfig/

On this link you can also see the difference between Hunt Groups and Interactive Response groups.

Once you have the details and DID, as this RGS may also been used to receive calls from PSTN, you can start creating Call Queues in MS teams as replacement of these RGS.

But before this you need to enable you VOIP Gateway / Session Border Controller (SBC) to be able to route the calls from PSTN to MS Teams in O365. This configuration is done by VOIP gateway expert which may be different than the team migrating users/RGS to MS Teams.

You also need to make sure you migrate the users associated with the RGS some time before you start creating Call Queue in MS Teams.

Now first you need to create Hybrid Application Endpoint in On-premises Lync servers and assign a line URO to this Endpoint using the below commands then wait for the replication to happen.

New-CsHybridApplicationEndpoint -ApplicationID “ApplicationNameInAzure” -DisplayName “Display Name of Call Queue” -SipAddress “sip:mycallqueue@domain.com” -OU “Distinguish Name of the OU to create this Endpoint”

Set-CsHybridApplicationEndpoint -Identity mycallqueue@domain.com -LineURI tel:+123456789

Once you are done with the EndPoint Creation, you can go to MS Teams portal and create Call queue.

Also assign agents and that it all.

Basic Difference between Popular Public Clouds and On-premises Platform

These days there is big craze about the public clouds. Competition is so high that new features are getting added to public clouds everyday. Here is some summary about the difference of the clouds features you can consider before buying it.

The above feature as per the current status and can vary now because there are something been added every day to the cloud platform to keep it in popularity.