SIGRed: a 17-year-old wormable vulnerability in Windows DNS server

Last Microsoft’s Patch Tuesday addressed a 17-year-old vulnerability impacting Microsoft Windows DNS Server, tracked as CVE-2020-1350 and dubbed “SigRed” by ChekPoint‘s researchers.

The issue received a severity rating of 10.0 on the CVSS scale and affects Windows Server versions 2003 to 2019.


The discovery

The “SigRed” vulnerability was discovered [1] by Check Point researcher Sagi Tzaik, it impacts Microsoft Windows DNS and could be exploited by an unauthenticated, remote attacker to gain domain administrator privileges over targeted servers.

After, the attacker could take full control of Active Directory domain and therefore the entire IT infrastructure.

The vulnerability can be expolited by sending specially-crafted malicious DNS queries to a Windows DNS server. According to CheckPoint report:

SIGRed (CVE-2020-1350) is a wormable, critical vulnerability (CVSS base score of 10.0) in the Windows DNS server that affects Windows Server versions 2003 to 2019, and can be triggered by a malicious DNS response. As the service is running in elevated privileges (SYSTEM), if exploited successfully, an attacker is granted Domain Administrator rights, effectively compromising the entire corporate infrastructure.

Microsoft is not aware of attacks in the wild exploiting the issue, it confirmed that the issue remained hidden for 17 years: for more technical details, please refers to CheckPoint’s research [1].


Fix and workaround

As I said, Microsoft released a fix [2] for this vulnerability in the past Patch Tuesday, but also released a temporary workaround [3] for critical-mission servers that can be implemented without requiring an administrator to restart the server:

To work around this vulnerability, make the following registry change to restrict the size of the largest inbound TCP-based DNS response packet allowed:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

TcpReceivePacketSize

Value = 0xFF00

Note You must restart the DNS Service for the registry change to take effect.

  • The Default (also max) Value = 0xFFFF
  • The Recommended Value = 0xFF00 (255 bytes less than the max)

After the workaround is implemented, a Windows DNS server will be unable to resolve DNS names for its clients when the DNS response from the upstream server is larger than 65280 bytes.

Important information about this workaround

TCP-based DNS response packets that exceed the recommended value will be dropped without error, so it is possible that some queries may not be answered. This could result in an unanticipated failure. A DNS server will only be negatively impacted by this workaround if it receives valid TCP responses that are greater than allowed in the previous mitigation (over 65,280 bytes).

The reduced value is unlikely to affect standard deployments or recursive queries, but a non-standard use-case may be present in a given environment. To determine whether the server implementation will be adversely affected by this workaround, you should enable diagnostic logging and capture a sample set that is representative of your typical business flow. Then, you will need to review the log files to identify the presence of anomalously large TCP response packets


References

  1. SIGRed – Resolving Your Way into Domain Admin: Exploiting a 17 Year-old Bug in Windows DNS Servers – Check Point Research
  2. CVE-2020-1350 | Windows DNS Server Remote Code Execution Vulnerability
  3. Windows DNS Server Remote Code Execution Vulnerability

Related posts

  1. Using .lnk files as zero-touch downloaders
  2. How to monitor battery healt and optimize power consumption on Windows 10 laptops without additional softwares
  3. Windows Forensic Analysis: some thoughts on RDP related Event IDs
  4. Beware! A simple wallpaper image can brick your Android device
  5. Weekly Cybersecurity Roundup #8