CVSS Score: 9.8 

Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C 

Overview 

Microsoft released a patch today for a critical vulnerability (CVE-2020-17051) in the Windows NFSv3 (Network File System) server. NFS is typically used in heterogenous environments of Windows and Unix/Linux for file sharing. The vulnerability can be reproduced to cause an immediate BSOD (Blue Screen of Death) within the nfssvr.sys driver. Interestingly, the November patches from Microsoft also include a remote kernel data read vulnerability in the same nfssvr.sys driver (CVE-2020-17056), which leads to a potential ASLR (address space layout randomization) bypass. The combination of these two vulnerabilities dramatically increases the likelihood of a remote exploit when used on Windows Server to bypass exploit mitigations.  CVE-2020-17051 is the first known vulnerability which has been disclosed within the Windows implementation of the NFSv3 protocol to the best of our knowledge.  

Threat Surface 

The vulnerability is believed to impact all versions of Windows Server when: 

1. An authenticated user has write access to any NFS share. 
2. An NFS share has been configured with anonymous write access (no authentication required) 

A Shodan query reported 38,893 servers with port 2049 exposed to the internet; however, it is unknown what percentage of these servers are actually NFS shares and actually configured with anonymous write access. The network share discovery technique is typically used by an adversary within the discovery phase of the MITRE ATT&CK framework with the objective to gain further privileges. CVE-2020-17051 would give adversaries the ability to spread worm–like within heterogenous Windows and Unix/Linux environments using anonymous write access file shares over NFSv3. 

Mitigation 

Patching is always the first and most effective course of action. If it’s not possible to patch, the best mitigation is to limit Windows NFSv3 server share write access internally and block any external access to vulnerable servers. For those McAfee customers who are unable to deploy the Windows patch, the following Network Security Platform (NSP) signatures will provide a virtual patch against attempted exploitation of this vulnerability. 

NSP Attack ID: 0x40c01200 – NFS Microsoft Windows Network File System Remote Code Execution Vulnerability (CVE-2020-17051) 

The post CVE-2020-17051: Remote kernel heap overflow in NFSv3 Windows Server appeared first on McAfee Blog.

Steve Povolny contributed to this report.

McAfee’s Advanced Threat Research team performs security analysis of products and technologies across nearly every industry vertical. Special interest in the consumer space and Internet of Things (IoT) led to the discovery of an insecure design with the McLear NFC Ring a household access control device. The NFC Ring can be used to interact with NFC-enabled door locks which conform to the ISO/IEC 14443A NFC card type. Once the NFC Ring has been paired with the NFC enabled door lock, the user can access their house by simply placing the NFC Ring within NFC range of the door lock.

McLear originally invented the NFC Ring to replace traditional keys with functional jewelry. The NFC Ring uses near field communication (NFC) for access control, to unlock and control mobile devices, share and transfer information, link people and much more. McLear NFC Ring aims to redefine and modernize access control to bring physical household security through convenience. Their latest ring also supports payment capability with McLear Smart Payment Rings, which were not in scope for this research.

Identity is something which uniquely identifies a person or object; an NFC tag is a perfect example of this. Authentication can be generally classified into three types; something you know, something you have and something you are. A NFC Ring is different from the general NFC access tag devices (something you have) as the Ring sits on your finger, so it is a hybrid authentication type of something you have and something you are. This unique combination, as well as the accessibility of a wearable Ring with NFC capabilities sparked our interest in researching this product as an NFC-enabled access control device. Therefore, the focus of our research was on NFC Ring protection against cloning as opposed to the door lock, since NFC access control tags and door locks have been well-researched.

The research and findings for this flaw were reported to McLear on September 25, 2019. To date, McAfee Advanced Threat Research has not received a response from the vendor.

Duplicating Keys Beyond the Hardware Store

In the era of Internet of Things (IoT), the balance between security and convenience is an important factor to get right during the concept phase of a new product and the bill of materials (BOM) selection. The hardware selection is critical as it often determines the security objectives and requirements that can be fulfilled during design and implementation of the product lifecycle. The NFC Ring uses an NFC capable Integrate Circuit (IC) which can be easily cloned and provides no security other than NFC proximity. The NFC protocol does not provide authentication and relies on its operational proximity as a form of protection. The problem with NFC Tags is that they automatically transmit their UID when in range of NFC device reader without any authentication.

Most consumers today use physical keys to secure access to their household door. The physical key security model requires an attacker to get physical access to the key or break the door or door lock. The NFC Ring, if designed securely, would provide equal or greater security than the physical key security model. However, since the NFC Ring can be easily cloned without having to attain physical access to the Ring, it makes the product’s security model less secure than a consumer having a physical key.

In this blog we discuss cloning of the NFC Ring and secure design recommendations to improve its security to a level equal to or greater than existing physical keys.

NFC Ring Security Model and Identity Theft

All McLear non-payment NFC Rings using NTAG216 ICs are impacted by this design flaw. Testing was performed specifically on the OPN which has an NTAG216 IC. The NFC Ring uses the NTAG 216 NFC enabled Integrated Circuit (IC) to provide secure access control by means of NFC communication.

The NFC protocol provides no security as it’s just a transmission mechanism.  The onus is on product owners to responsibly design and implement a security layer to meet the security objectives, capable of thwarting threats identified during the threat modeling phase at concept commit.

The main threats against an NFC access control tag are physical theft and tag cloning by NFC. At a minimum, a tag should be protected against cloning by NFC; with this research, it would ensure the NFC Ring provides the same level of security as a physical key. Ideal security would also protect against cloning even when the NFC Ring has been physically stolen which would provide greater security than that of a physical key.

The NTAG216 IC provide the following security per the NFC Ring spec:

1. Manufacturer programmed 7-byte UID for each device
2. Pre-programmed capability container with one-time programmable bits
3. Field programmable read-only locking function
4. ECC based originality signature
5. 32-bit password protection to prevent unauthorized memory operations

The NFC Ring security model is built on the “Manufacturer programmed 7-byte UID for each device” as the Identity and Authentication with the access control principle or door lock. This 7-byte UID (unique identifier) can be read by any NFC enabled device reader such as a proxmark3 or mobile phone when within NFC communication range.

The NFC Ring security model can be broken by any NFC device reader when they come within NFC communication range since the static 7-byte UID is automatically transmitted without any authentication. Once the 7-byte UID has been successfully read, a magic NTAG card can be programmed with the UID, which forms a clone of the NFC Ring and allows an attacker to bypass the secure access control without attaining physical access to the NFC Ring.

The NFC Ring is insecure by design as it relies on the static 7-byte UID programmed at manufacture within the NTAG216 for device identity and authentication purposes. The NFC Ring security model relies on NFC proximity and a static identifier which can be cloned.

In addition, we discovered that the UIDs across NFC Rings maybe predictable (this was a very small sample size of three NFC Rings):

• NFC Ring#1 UID 04d0e722993c80
• NFC Ring#2 UID 04d24722993c80
• NFC Ring#3 UID 04991c4a113c80

There is only a 22-byte difference between the UID of NFC Ring#1 and NFC Ring#2 (0x24-0x0e). By social engineering when a victim purchased their NFC Ring, an attacker could purchase a significant sample size of NFC Rings around the same time and possibly brute force their NFC Ring UID.

Social Engineering

Social Engineering consists of a range of techniques which can be used through human interaction for many malicious purposes such as identity theft. In the case of the NFC Ring the goal is to steal the user’s identity and gain access to their home. Reconnaissance can be performed online to gain background information such as what type of technology is being used by the victim for their home access.

One of the most common exchanges of technology today has become the passing of a phone between two untrusted parties to take a picture. The NFC Ring social engineering attack could be as simple as requesting the victim to take a picture with the attacker-supplied phone. The victim-as-helpful-photographer holds the attacker’s phone, which can read NFC tags and could be equipped with a custom Android app to read the NFC Ring UID, all transparent to the victim while they are snapping away. There is no sign to the victim that their NFC Ring is being read by the phone. It is recorded in the system log and cannot be viewed until a USB cable is attached with required software. Once the Ring is compromised, it can be reprogrammed on a standard writable card, which can be used to unlock smart home locks that partner with this product. The victim’s home is breached.

How It’s Done: NFC Ring Cloning

To successfully clone an NFC Tag, one must first identify the Tag type. This can be done by looking up the product specifications in some cases, or verifying by means of an NFC device reader such as a proxmark3.

From the NFC Ring specs we can determine most of the required tag characteristics:

1. IC Model: NTAG216
2. Operating Frequency: 13.56Mhz
3. ISO/IEC: 14443A
4. User writable space: 888 bytes
5. Full specifications

In addition, by communicating with a proxmark3 attackers can physically verify the NFC Tag characteristics and obtain the UID which is required for cloning.

The most straightforward method to stealing the unique identifier of the Ring would be through a mobile phone. The following steps were taken in the below demo:

1. Reading of NFC Ring with proxmark3 and cloning NTAG21x emulator card
2. Setting attacker’s phone to silent to prevent NFC Tag detection sound
3. Running our customized Android app to prevent Android activity popup when NFC Tag detected and read.

Mitigation Secure Design Recommendations

Lock the door. The existing insecure design can be mitigated by using NFC Doorlock password protection in combination with the NFC Ring for two factor authentication.

Authenticate. NFC Ring designers must mandate a secure PKI design with an NFC Tag which contains a crypto module that provides TAG authentication. The NFC Ring secure design must mandate a security layer on top of NFC to access control device manufacturers to ensure secure and trustworthy operation.

Randomize UIDs. In addition, the NFC designers must ensure they are not manufacturing NFC Rings with sequential UIDs which may be predictable with purchase date.

Consumer Awareness

To make customers aware of the security risks associated with products available on the market, product manufacturers should clearly state the level of security which their product provides in comparison with the technology or component they claim to be advancing. Are customers holding the master key to unlock their door, and are there duplicates?

In the case of the NFC Ring, while convenient, it clearly does not provide the same level of security to consumers as a physical key. This decrease in security model from a physical key to a NFC Ring is not due to technology limitations but due to an insecure design.

 

The post The Cloning of The Ring – Who Can Unlock Your Door? appeared first on McAfee Blog.

The Vulnerability

The latest vulnerability in SMBv3 is a “wormable” vulnerability given its potential ability to replicate or spread over network shares using the latest version of the protocol (SMB 3.1.1). As of this writing, Microsoft have just released a patch for CVE-2020-0796 on the morning of March 12^th. The bug was introduced very recently, in the decompression routines for SMBv3 data payloads. The code implementing this was deployed in April 2019 for Version 1903 and November 2019 for version 1909.

The vulnerability occurs during the processing of a malformed compressed message. The header of the message follows this format: (from [MS-SMB2])

• There are two parameters in the header that are of interest: OriginalCompressedSegmentSize and Offset/Length
• The Srv2DecompressData (srv2.sys) function allocates a buffer of size OriginalCompressedSegmentSize + Offset/Length
• This is not checking the signedness of these values, and as the addition is signed an attacker can allocate a buffer smaller than intended
• Data is being decompressed at buffer + offset, using data from packet+0x10+offset
• OriginalCompressedSegmentSize is used as the UncompressedBufferSize parameter passed to SmbCompressionDecompression which is a wrapper for RtlDecompressBufferEx2
• This routine assumes the uncompressed buffer size to be an unsigned long so a negative value gets cast into a large unsigned number
• Because of this, the decompression routine decompresses the buffer and can go well beyond the original size, as it is assuming it has a very large buffer to work with

Here’s an annotated disassembly of the relevant function on the server side:

This flaw can affect both client and server in SMB negotiations in a compressed message sent after the Negotiate Protocol Responses. The server vulnerability is within srv2.sys and the client vulnerability is within mrxsmb.sys which both end up calling the same code in SmbCompressDecompress.

Here’s an annotated disassembly of the relevant function on the client side – unlike the server side the OriginalCompressedSegmentSize is bounds checked but there is no check on offset/length before they are combined and passed to ExAllocatePoolWithtag. We have confirmed the BSOD crash from both client->server AND server-client using this vulnerability.

If a computer allows inbound SMB3 traffic over port 445, by default compression is supported and the client and server will negotiate the “terms” of this compression and then the client will proceed to transfer a compressed payload.

The flaw is present in the SMB Compression Transform Header, prior to any kind of authentication.

We can see the very large OriginalSize used for attacker-controlled data (4294967295 is 0xFFFFFFFF in hex which is also -1 if viewed as a signed long). This is copied into a smaller fixed buffer and results in a classic buffer overflow. Of note is the ProtocolID of \xfcSMB, which must be present and represents the magic bytes used to indicate the message must be decompressed per the spec.

However, it is not just the server-side which is vulnerable to this attack. If a client connects to a malicious SMB server, both sides run the same vulnerable code and a malicious server can respond to client requests in the same way to trigger the overflow on the initiator/client side. In this scenario, the Windows Powershell command referenced here will not be effective in stopping this attack against the SMB client. It will only be useful when implemented on the SMB server/recipient side pre-authentication.

Exposure

As always, this kind of patch should be applied as soon as possible, subject to organizational policy. While there are currently no known exploits in the wild, as you will see, causing a BSOD (blue screen of death), is quite trivial, and remains a highly effective attack method for disruption if an attacker can gain access to an internal network.

More dangerous yet are any systems exposing port 445 to the Internet, as we have seen the damage possible through similar bugs such as WannaCry. As of the time of this writing and just prior to Microsoft releasing its patch, Shodan.io appears to have just over 35,000 Windows computers reporting the vulnerable versions of software as searched by: port:445 os: “Windows” + os: “18362” for example. Many of these will likely be patched quickly now that a fix is out.

Patch Analysis

Looking at the patched version, we can see the code is now using RtlULongAdd to add  OriginalCompressedSegmentSize and the Offset/Length value. There also seem to be an extra test to make sure the size is not bigger than the whole packet plus 0x134.

Looking a little further, we can also see the usage of RtULongSub for computing the size of the compressed buffer while accounting for the offset field.

Finally, we can also notice the usage of WPP tracing code in case an error occurs (tracing was already occurring throughout the driver, but this specific function was not previously instrumented in such a way).

Impact – BSOD vs. RCE

Getting a Blue Screen of Death or BSOD is a straightforward exercise. Pivoting from that to full remote code execution will likely be more challenging, as additional bugs will likely be required to bypass Windows’ latest mitigation techniques, such as Kernel ASLR or KASLR. For this bug, the attacker will have easy primitives for the allocation of data and can control the size of the data used to trigger the overflow. On the flip side, the objects allocated in memory to store the attacker input are freed relatively quickly, making exploitation more difficult.

Product Detection/Mitigation

McAfee has released NSP ID 0x43c0e600 – NETBIOS-SS: Samba Remote Code Execution Vulnerability (CVE-2020-0796) to address exploitation of the vulnerability. We are working on developing additional signatures to complement or replace this coverage.

 

The post SMBGhost – Analysis of CVE-2020-0796 appeared first on McAfee Blog.

While not a new practice, the sheer volume of people required to adhere to social distancing best practices means we now have a mass workforce working remotely. Most enterprises and SMBs can support working remotely today but many IT departments are not equipped to scale to the numbers currently required. In this blog we discuss the threats to enterprises and SMBs through this increased remote workforce and how to mitigate the risk.

Cybercriminals seek opportunities to achieve their goals and will follow the path of least resistance. The initial access vectors enumerated in MITRE ATT&CK typically used by cyber criminals are phishing or exploitation of vulnerabilities to gain access to an organization, and are used to act on their malicious objectives. Now that employees have migrated to their homes to work remotely, cybercriminals will target the insecurities of consumer systems and networks to gain access to corporations. As Raj Samani highlighted in a previous post, targeted ransomware attacks are fueling the increased demand in the underground for compromised corporate networks. If employees access corporate networks from pre-infected unmanaged machines without adequate security measures, it creates a much larger attack surface for cybercriminals. This increases the risk of an organization falling victim to a potential breach and ransomware lockdown.

COVID-19 social distancing restrictions came into effect very rapidly, giving organizations little time to prepare for securely managing their workforce remotely. It is important that organizations continue to do business during this tough time, but they must also do it securely to prevent an attack such as ransomware. To protect organizations in this current climate we must approach this from two perspectives:

1. Know your environment and users
2. Know your business and real threats

To understand the threats of telecommuting at scale, we must understand the technologies typically used by remote workers to execute their work and access the organization.

Know Your Environment and Users

Per figure 1 below, it is important to understand the architecture and technologies being used by your employees within your business environment. This gives you visibility into your potential exposure based on vulnerabilities being actively exploited by threat actors so that you can protect your remote workers and business infrastructure/assets.

 

Know Your Business and Real Threats

Adversary Opportunities

Adversaries need an initial access vector to gain a foothold within an organization. They will typically seek out corporate usernames and passwords using techniques enumerated in MITRE ATT&CK, such as phishing or remote exploitation of software vulnerabilities. The telecommuter technology increases the attack surface significantly and is being exploited/researched as evident below:

• In 2019, vulnerabilities in Palo Alto Networks, Fortinet, Pulse Secure, and Citrix VPN servers were targeted
• Proof-of-concept exploits have been developed for Citrix NetScaler/Application Delivery Controller (ADC), Cisco VPN routers and the Zoho ManageEngine Desktop Central
• Fox-IT discovered bypassing of a VPN two-factor authentication
• Proof-of-Concept exploits have been developed for vulnerabilities in Telecommuter Applications such as Zoom, Confluence and Slack
• There have been vulnerabilities recently disclosed in Android and iOS free VPNs
• RDP vulnerabilities have been disclosed over the last year such as Dejablue, Bluegate and a proof-of-concept exploit in the case of Bluekeep (wormable)

Controls

Minimum technical controls for remote worker machines:

• Secure configuration and strong passwords to prevent router compromise
• Keep all software layers patched, VPNs and telecommuter applications
• Do not reuse passwords across personal and work systems
• Robust endpoint security software

Minimum technical controls for enterprise/SMBs:

• Security hygiene best practices
• MFA/2FA and logging for VPN accounts
• VPN patching
• Secure RDP access
• Segmentation of critical business assets
• Data backups
• User and device identity for employees and 3^rd parties/suppliers

Policies:

• Data loss prevention
• Strong passwords
• SaaS security
• Managed vs unmanaged device access

Training:

• Phishing and social engineering training based on the current climate context – “verify before trusting”
• Keep employees informed of phishing campaigns relative to your environment and business

Conclusion

Strong technical controls are a must to protect telecommuters in the current climate and there is also no substitute for employee phishing and social engineering training as a successful phish can negate technical controls. Even MFA/2FA can be bypassed in some cases, using advanced phishing techniques, so we must all stay vigilant, starting with ourselves to protect our organizations by adopting a “verify before trusting” approach.

The post Transitioning to a Mass Remote Workforce – We Must Verify Before Trusting appeared first on McAfee Blog.

Overview

For the March 2021 Patch Tuesday, Microsoft released a set of seven DNS vulnerabilities. Five of the vulnerabilities are remote code execution (RCE) with critical CVSS (Common Vulnerability Scoring Standard) scores of 9.8, while the remaining two are denial of service (DoS). Microsoft shared detection guidance and proofs of concept with MAPP members for two of the RCE vulnerabilities, CVE-2021-26877 and CVE-2021-26897, which we have confirmed to be within the DNS Dynamic Zone Update activity. Microsoft subsequently confirmed that all seven of the DNS vulnerabilities are within the Dynamic Zone Update activity.

We confirmed from our analysis of CVE-2021-26877 and CVE-2021-26897, in addition to further clarification from Microsoft, that none of the five DNS RCE vulnerabilities are wormable.

RCE vulnerabilities
CVE-2021-26877, CVE-2021-26897 (exploitation more likely)
CVE-2021-26893, CVE-2021-26894, CVE-2021-26895 (exploitation less likely)

DoS vulnerabilities
CVE-2021-26896, CVE-2021-27063 (exploitation less likely)

A critical CVSS score of 9.8 means that an attacker can remotely compromise a DNS server with no authentication or user interaction required. Successful exploitation of these vulnerabilities would lead to RCE on a Primary Authoritative DNS server. While CVSS is a great tool for technical scoring, it needs to be taken in context with your DNS deployment environment to understand your risk which we discuss below.

We highly recommend you urgently patch your Windows DNS servers if you are using Dynamic Updates. If you cannot patch, we recommend you prioritize evaluating your exposure. In addition, we have developed signatures for CVE-2021-26877 and CVE-2021-26897 which are rated as “exploitation more likely” by Microsoft.

DNS Dynamic Updates, Threats and Deployment

Per the NIST “Secure Domain Name System (DNS) Deployment Guide”, DNS threats can be divided into Platform and Transaction Threats. The platform threats can be classed as either DNS Host Platform or DNS Software Threats. Per Table 1 below, Dynamic Update is one of the four DNS Transaction types. The seven DNS vulnerabilities are within the Dynamic Update DNS transaction feature of Windows DNS Software.

Table 1: DNS Transaction Threats and Security Objectives

The DNS Dynamic Zone Update feature allows a client to update its Resource Records (RRs) on a Primary DNS Authoritative Server, such as when it changes its IP address; these clients are typically Certificate Authority (CA) and DHCP servers. The Dynamic Zone Update feature can be deployed on a standalone DNS server or an Active Directory (AD) integrated DNS server. Best practice is to deploy DNS integrated with (AD) so it can avail itself of Microsoft security such as Kerberos and GSS-TSIG.

When creating a Zone on a DNS server there is an option to enable or disable DNS Dynamic Zone Updates. When DNS is deployed as a standalone server, the Dynamic Zone Update feature is disabled by default but can be enabled in secure/nonsecure mode. When DNS is deployed as AD integrated, the Dynamic Zone Update feature is enabled in secure mode by default.

Secure Dynamic Zone Update verifies that all RR updates are digitally signed using GSS-TSIG from a domain-joined machine. In addition, more granular controls can be applied on what principal can perform Dynamic Zone Updates.

Insecure Dynamic Zone Update allows any machine to update RRs without any authentication (not recommended).

Attack Pre-requisites

• AD Integrated DNS Dynamic Updates (default config of secure updates)
  • A DNS server must accept write requests to at least one Zone (typically a primary DNS server only allows Zone RR writes but there are misconfigurations and secondary servers which can negate this)
  • Domain-joined machine
  • Attacker must craft request to DNS server and supply a target Zone in request
• Standalone DNS Server (secure/nonsecure config)
  • A DNS server must accept write requests to at least one Zone (typically a primary DNS server only allows Zone RR writes but there are misconfigurations and secondary servers which can negate this) 
  • Attacker must craft request to DNS server and supply a target Zone in request 

From a Threat Model perspective, we must consider Threat Actor motives, capabilities, and access/opportunity, so you can understand the risk relative to your environment. We are not aware of any exploitation in the wild of these vulnerabilities so we must focus on the access capabilities, i.e., close the door on the threat actor opportunity. Table 2 summarizes DNS Dynamic Update deployment models relative to the opportunity these RCE vulnerabilities present.

Table 2: Threat Actor access relative to deployment models and system impact

The highest risk deployment would be a DNS server in Dynamic Update insecure mode exposed to the internet; this is not best security practice and based on our experience, we do not know of a use case for such deployment.

Deploying AD integrated DNS Dynamic Update in secure mode (default) mitigates the risk of an unauthenticated attacker but still has a high risk of a compromised domain computer or trusted insider being able to achieve RCE.

Vulnerability Analysis

All the vulnerabilities are related to the processing of Dynamic Update packets in dns.exe. The goal of our vulnerability analysis, as always for critical industry vulnerabilities, is to ensure we can generate accurate signatures to protect our customers.

Analysis of CVE-2021-26877

• The vulnerability is triggered when a Zone is updated with a TXT RR that has a “TXT length” greater than “Data length” per Wireshark below:

Figure 1: Wireshark view of exploit packet classifying the DNS packet as malformed

• The vulnerability is in the File_PlaceStringInFileBuffer() function as you can see from WinDbg output below:

Figure 2: WinDbg output of crash while attached to dns.exe

• The vulnerability is an Out of bounds (OOB) read on the heap when the “TXT length” field of DNS Dynamic Zone Update is not validated relative to “Data length”. This could allow an attacker to read up to 255 bytes of memory. Microsoft states this vulnerability can be used to achieve RCE; this would require a further OOB write primitive.
• The memory allocation related to the OOB read is created within the CopyWireRead() function. Relevant pseudo code for this function is below:

• The File_PlaceStringInFileBuffer() function copies data from TXT_data allocated from CopyWireRead() function previously. However, the UpdateRR->TXT length value from Wireshark is not validated and used to copy from *UpdateRR->Data length. Because UpdateRR->TXT length is not validated relative to UpdateRR->Data length it results in a OOB read from heap memory.

Analysis of CVE-2021-26897

• The vulnerability is triggered when many consecutive Signature RRs Dynamic Updates are sent
• The vulnerability is an OOB write on the heap when combining the many consecutive Signature RR Dynamic Updates into base64-encoded strings before writing to the Zone file
• Microsoft states this vulnerability can be used to achieve RCE

Figure 3: Packet containing many consecutive Signature RR dynamic updates. Pay special attention to the length field of the reassembled flow.

Exploitability

Exploiting these vulnerabilities remotely requires both read and write primitives in addition to bypassing Control Flow Guard (CFG) for execution. The DNS protocol has significant remote unauthenticated attack surface to facilitate generating such primitives which has been researched as part of CVE-2020-1350 (SigRed). In addition, per the RR_DispatchFuncForType() function, there are read and write functions as part of its dispatch table.

Figure 4: Path of DNS RR update packet

Figure 5: Dispatch functions for reading and writing

Mitigations

Patching is always the first and most effective course of action. If it’s not possible to patch, the best mitigation is to audit your DNS deployment configuration to limit Dynamic Zone Updates to trusted servers only. For those McAfee customers who are unable to deploy the Windows patch, the following Network Security Platform (NSP) signatures will provide a virtual patch against attempted exploitation of both vulnerabilities, CVE-2021-26877 and CVE-2021-26897.  

NSP Attack ID: 0x4030e700 – DNS: Windows DNS Server Remote Code Execution Vulnerability (CVE-2021-26877)
NSP Attack ID: 0x4030e800 – DNS: Windows DNS Server Remote Code Execution Vulnerability (CVE-2021-26897)

In addition, NIST “Secure Domain Name System (DNS) Deployment Guide” provides best practices for securing DNS deployment such as:

1. DNS Primary Server should restrict clients that can update RRs
2. Secure Dynamic Update using GSS-TSIG
3. Secondary DNS Server Dynamic Update forwarding restrictions using GSS-TSIG
4. Fine-grained Dynamic Update restrictions using GSS-TSIG

The post Seven Windows Wonders – Critical Vulnerabilities in DNS Dynamic Updates appeared first on McAfee Blog.