Major Vulnerability in Microsoft DNS Needs Action

Microsoft announced a major vulnerability on July 14, 2020, in its Domain Name System (DNS) service component of Windows Server. The issue is documented as CVE-2020-1350 and is rated at the highest possible level of 10 out of 10. Descriptions of the security flaw state that it is ‘wormable’, which means it can be automated to conduct widespread and devastating attacks similar to WannaCry or NotPetya.

Background of DNS

Every website on the Internet is served from a web server with an IP address. For example, lodestonesecurity.com has an IP address of 104.18.40.21. DNS allows us to type an easily referenced name instead of using the IP address numbers. Each time we visit a website, our computer performs a DNS lookup behind the scenes. Those lookups can go to one of thousands of DNS servers depending on their configurations. Some of these servers are Windows servers running Microsoft’s DNS services, while others are running one of many other DNS platforms.

Details of the CVE-2020-1350 Vulnerability

The vulnerability referenced in this post affects only the Windows DNS implementation. The identified flaw has been in place for 17 years according to the researchers at Checkpoint that discovered it. As a direct consequence, every Windows Server with active support is affected (2012+), as well as Windows Server 2008, as of this writing. The flaw is also present on Windows Server 2003, but patches are not expected  because extended support for Windows Server 2003 ended in 2015.

This vulnerability is particularly dangerous because it allows for program code to be executed over the network, and it executes the code at the highest possible authority level, referred to as SYSTEM.

The Major Risk

Exploiting this vulnerability requires no interaction from any users. After the findings were published, attackers can (and will) start scanning the Internet for affected servers. It is imperative to quickly determine if any of your Windows Servers with DNS services are exposed to the Internet. These will be the first and easy targets.

The (Slightly) Lesser Risk

Microsoft’s Active Directory (AD) is very tightly integrated with DNS. Generally, the main servers for AD, called Domain Controllers (DC), have the DNS service enabled. They are not typically exposed to the Internet, but that is not a guarantee they are safe. Attackers can enter the network through typical phishing attempts and leverage the Remote Access Tool (RAT), sometimes called a Banking Trojan, to identify and launch an attack at internal DNS servers. Phishing victims are often low privilege accounts on the network, so attackers always seek ways to escalate to higher privilege accounts allowing for larger devastation and higher ransom demands.

The researchers also demonstrated a form of attack that can launch the exploit by getting a user to visit an infected or nefarious website. The website sends JavaScript code to the user’s internet browser to launch an attack on the DNS server without having to deploy a RAT. This attack vector only works if the user is browsing with Microsoft’s Internet Explorer or non-Chromium based Edge browsers. Following is a short video of the browser-based attack demonstration.

Tool Suggestions

The following section highlights the technical recommendations to help identify any DNS servers on a company network. In general, these tools should be run against IP addresses that are well known and with permission to test.

A frequently used tool by Lodestone is Nmap. It allows the scan of a network for a variety of date types, but we recommend to narrow the focus to the DNS service that runs on port 53. Adjust the IP address parameters to appropriate segments for the target environment. Run Nmap with Administrator (sudo) privileges against both the inside and outside of the network.

    nmap -p 53 -sA -sU -Pn  <IP Address>
    nmap -p 53 -sA -sU -Pn <IP Address1 IP Address2 IP Address3 …>
    nmap -p 53 -sA -sU -Pn <IP Address/CIDR>

The last command will return all hosts that are discovered on the network regardless of the port 53 status. The following command will only produce a list of hosts with port 53 open.

    nmap -p 53 <IP Address/CIDR> -oG - | grep “/open” | awk ‘{ print $2 }’

Once all the DNS servers are identified, run this command from the Powershell console for each server to see if they do not have the workaround applied and are vulnerable to CVE-2020-1350. If there is no response then this means the workaround is not applied and you should verify that the patch has been applied. Otherwise, if the returned value is ‘65280’ or some value less than 65,535 then the workaround has been applied and the server is not vulnerable.

     Invoke-Command -ScriptBlock {(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters\" -ErrorAction SilentlyContinue -WarningAction SilentlyContinue).TCPReceivePacketSize}

Check for DNS in Windows Management

Powershell

We recommend to verify if the Windows Server has the DNS service running by using the following PowerShell command:

     Get-WindowsFeature | Where-Object {$_. name -eq "DNS"} | Format-List Name,Installstate

One of the following outputs should be returned.

DNS Server is installed

DNS Server is not installed

 

Graphical User Interface (GUI)

It is possible to also see if the DNS service is installed and running on the Windows Server by opening the Server Manager Console from the Start menu. The image below shows that the DNS service is installed on the server. The following image shows that the DNS service is running.

Server Manager application

 

Server Manager application Services

 

Action Needed

Microsoft has published patches for affected operating systems that are still under the support lifecycle. They also recognize that DNS is run on some of the most critical parts of the infrastructure and sometimes it is impossible to install patches right away.

Systematic Action – Patch

The patch for this vulnerability should show up in the normal Windows Update queues, whether you manage your patches directly on your servers or proxy them through the Windows Server Update Services (WSUS) setup. The patch does require a reboot, so you will have to schedule this during your maintenance policy for critical patches. Ideally, patch this as soon as you can as we expect to see it being used by attackers. Patch numbers are different for each version of Windows Servers and Microsoft detailed them in the CVE-2020-1350 advisory article (https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350). To see if your Windows Server has been patched, enter the following PowerShell command and replace <KB> with your version of Windows Server.

Get-Hotfix | findstr /i "<KB>"

 

Immediate Action – Workaround

Microsoft shared instructions on a workaround that does not require a full reboot of the affected operating system. It does require that you stop and start the DNS service component after applying the fix, but that should be a quick blip of downtime. If you aren’t able to install the available patch within a day or so, we highly recommend implementing this workaround until you are able to schedule that patch install. You can find all the supported operating systems and their corresponding patch numbers here:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350

 

We are sharing a link to Microsoft’s Knowledge Base article KB4569509 because it is always possible that the details of this mitigation might change. In essence, the article instructs you to add a new or update an existing registry value to change the behavior of the DNS service. Follow their instructions here:

https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability

Advice

If you are not comfortable taking this on and do not have the resources to help work through this, please reach out and let us help. We offer a Virtual CISO service to help organizations that don’t already have cybersecurity expertise readily available.

Author

  • James Habben

    James Habben is the Director of Business Development at Lodestone Security. Over his 15 years of cybersecurity experience, James has been involved in some of the largest data breaches in history, providing guidance and leadership through complex challenges. In addition, he helps companies to proactively improve their cybersecurity posture through policy, process, and cross-function data breach simulations. James has spoken at many conferences on new trends and techniques, and enjoys contributing to the cybersecurity community.

  • Joseph (Joe) Ricci is a Consultant at Lodestone Security, where Joe leads penetration tests and risk assessments. He also conducts research on the security integrity of IoT devices and different cloud technologies.