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.

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.