CVE-2020-1350 Windows DNS Server Remote Code Execution (SigRed)

A remote code execution vulnerability codenamed “SigRed” exists in Windows Domain Name System servers when they fail to properly handle requests. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the Local System Account. Windows servers that are configured as DNS servers are at risk from this vulnerability.

To exploit the vulnerability, an unauthenticated attacker could send malicious requests to a Windows DNS server.

The update addresses the vulnerability by modifying how Windows DNS servers handle requests.

Recent assessments:

gwillcox-r7 at July 14, 2020 6:11pm UTC reported:

Important Update: This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: <https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF&gt;

Update: Checkpoint has since released their blog post at <https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/&gt; with much more details on this vulnerability than when I originally wrote this. I’ll update a few statements here but readers are encouraged to read the paper for more details.

On July 14th, 2020, Microsoft released CVE-2020-1350, a critical DNS server remote code execution vulnerability that can result in Domain compromise and which is listed as a 10.0 CVE rating. Microsoft also described this vulnerability as wormable and recommended the following mitigation:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters 
  DWORD = TcpReceivePacketSize 
  Value = 0xFF00

This is rather odd to me. 0xFF00 looks like a potential mitigation against a integer overflow, as its possible the vulnerability stems from any packets being over 0xFFFF causing an integer overflow in memory, resulting in the allocation of a very small amount of memory to hold a very large buffer. At the very least, the fact that the recommended mitigation forcibly controls the max size of the packet that can be received suggests that this is a buffer overflow of some sort. Given the dynamic nature of DNS and the fact that it has to handle multiple requests at once, my guess is that its a heap buffer overflow.

Now that CheckPoint’s blog post is public one can confirm that this is in fact a integer overflow leading to a heap buffer overflow within the SigWireRead function of dns.exe, the server component of Microsoft’s DNS implementation. When the DNS server receives a SIG query response, that, when decompressed, incremented by 0x14, and added to the result of an earlier Name_PacketNameToCountNameEx call, is greater than 0xFFFF, will result in integer overflow, resulting in the following RR_AllocateEx call allocating too small of a heap buffer for the resource record, and a heap buffer overflow occurring when memcpy is called to copy the SIG query response into the overly small heap buffer that RR_AllocateEx allocated.

A very important point to note here is that whilst there is a RCE potential here by smuggling DNS requests over HTTP, it seems that CheckPoint has noted that only some browsers, notably Microsoft Edge and Internet Explorer, actually support sending HTTP requests to port 53, so whilst their video at <https://youtu.be/PUlMmhD5it8&gt; is certainly pretty cool, its important to note that with Google Chrome taking up over 65% of the browser market share according to <https://gs.statcounter.com/browser-market-share&gt; as of July 2020, and IE and Edge accounting for a combined total of roughly 4% of all browsers, its pretty unlikely that most organizations will be affected by the HTTP smuggling attack vector unless users are forced to use IE/Edge in their networks for some reason (such as support for legacy apps).

Edit: @cblack-r7 Also pointed out to me that looking at <https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability&gt; they mention this line “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.” He noticed that the terminology “upstream server” could mean that the malicious overly large DNS response has to come from an upstream resolver, which could complicate this vulnerability a little bit. This is also something that**@busterb**’s assessment seems to reflect concern about and is something that the CheckPoint blog doesn’t really address from what I’ve seen (though feel free to correct me if I am wrong here)

It should be noted that this vulnerability only affects Microsoft’s DNS implementation, however it goes way back all the way to Windows Server 2008. I wouldn’t be surprised if this also potentially affected Windows Server 2003 as well though, given how these types of vulns tend to be rather systemic, but I could be wrong there.

Another important point to note is that on Windows the DNS service runs as SYSTEM, so this will essentially be a remote SYSTEM level exploit for any attackers, which is pretty powerful. Unfortunately there is a limitation that if this is a remote RCE on the heap, the attacker will most likely have to deal with a lot of the new heap related mitigations introduced starting with Windows 8 and which were greatly improved with Windows 10. So this likely means that Windows Server 2008 and Windows Server 2008 R2 will be easy to develop an exploit for, but more recent servers like Windows Server 2019 may see a noticeable lag in exploit development time whilst exploit developers work their way around these mitigations. This can be seen in past heap overflow exploits where the Windows 7/Windows Server 2008 exploit came out very quickly but in some cases it took several months or even a year for the Windows 10/Server 2019 exploit to come out.

It should be noted that whilst this vulnerability has not been used in active attacks according to Microsoft, I’d safely place money on seeing this vulnerability get weaponized very quickly.

busterb at July 14, 2020 9:20pm UTC reported:

Important Update: This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: <https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF&gt;

Update: Checkpoint has since released their blog post at <https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/&gt; with much more details on this vulnerability than when I originally wrote this. I’ll update a few statements here but readers are encouraged to read the paper for more details.

On July 14th, 2020, Microsoft released CVE-2020-1350, a critical DNS server remote code execution vulnerability that can result in Domain compromise and which is listed as a 10.0 CVE rating. Microsoft also described this vulnerability as wormable and recommended the following mitigation:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters 
  DWORD = TcpReceivePacketSize 
  Value = 0xFF00

This is rather odd to me. 0xFF00 looks like a potential mitigation against a integer overflow, as its possible the vulnerability stems from any packets being over 0xFFFF causing an integer overflow in memory, resulting in the allocation of a very small amount of memory to hold a very large buffer. At the very least, the fact that the recommended mitigation forcibly controls the max size of the packet that can be received suggests that this is a buffer overflow of some sort. Given the dynamic nature of DNS and the fact that it has to handle multiple requests at once, my guess is that its a heap buffer overflow.

Now that CheckPoint’s blog post is public one can confirm that this is in fact a integer overflow leading to a heap buffer overflow within the SigWireRead function of dns.exe, the server component of Microsoft’s DNS implementation. When the DNS server receives a SIG query response, that, when decompressed, incremented by 0x14, and added to the result of an earlier Name_PacketNameToCountNameEx call, is greater than 0xFFFF, will result in integer overflow, resulting in the following RR_AllocateEx call allocating too small of a heap buffer for the resource record, and a heap buffer overflow occurring when memcpy is called to copy the SIG query response into the overly small heap buffer that RR_AllocateEx allocated.

A very important point to note here is that whilst there is a RCE potential here by smuggling DNS requests over HTTP, it seems that CheckPoint has noted that only some browsers, notably Microsoft Edge and Internet Explorer, actually support sending HTTP requests to port 53, so whilst their video at <https://youtu.be/PUlMmhD5it8&gt; is certainly pretty cool, its important to note that with Google Chrome taking up over 65% of the browser market share according to <https://gs.statcounter.com/browser-market-share&gt; as of July 2020, and IE and Edge accounting for a combined total of roughly 4% of all browsers, its pretty unlikely that most organizations will be affected by the HTTP smuggling attack vector unless users are forced to use IE/Edge in their networks for some reason (such as support for legacy apps).

Edit: @cblack-r7 Also pointed out to me that looking at <https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability&gt; they mention this line “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.” He noticed that the terminology “upstream server” could mean that the malicious overly large DNS response has to come from an upstream resolver, which could complicate this vulnerability a little bit. This is also something that**@busterb**’s assessment seems to reflect concern about and is something that the CheckPoint blog doesn’t really address from what I’ve seen (though feel free to correct me if I am wrong here)

It should be noted that this vulnerability only affects Microsoft’s DNS implementation, however it goes way back all the way to Windows Server 2008. I wouldn’t be surprised if this also potentially affected Windows Server 2003 as well though, given how these types of vulns tend to be rather systemic, but I could be wrong there.

Another important point to note is that on Windows the DNS service runs as SYSTEM, so this will essentially be a remote SYSTEM level exploit for any attackers, which is pretty powerful. Unfortunately there is a limitation that if this is a remote RCE on the heap, the attacker will most likely have to deal with a lot of the new heap related mitigations introduced starting with Windows 8 and which were greatly improved with Windows 10. So this likely means that Windows Server 2008 and Windows Server 2008 R2 will be easy to develop an exploit for, but more recent servers like Windows Server 2019 may see a noticeable lag in exploit development time whilst exploit developers work their way around these mitigations. This can be seen in past heap overflow exploits where the Windows 7/Windows Server 2008 exploit came out very quickly but in some cases it took several months or even a year for the Windows 10/Server 2019 exploit to come out.

It should be noted that whilst this vulnerability has not been used in active attacks according to Microsoft, I’d safely place money on seeing this vulnerability get weaponized very quickly.

ccondon-r7 at July 28, 2020 8:24pm UTC reported:

Important Update: This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: <https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF&gt;

Update: Checkpoint has since released their blog post at <https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/&gt; with much more details on this vulnerability than when I originally wrote this. I’ll update a few statements here but readers are encouraged to read the paper for more details.

On July 14th, 2020, Microsoft released CVE-2020-1350, a critical DNS server remote code execution vulnerability that can result in Domain compromise and which is listed as a 10.0 CVE rating. Microsoft also described this vulnerability as wormable and recommended the following mitigation:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters 
  DWORD = TcpReceivePacketSize 
  Value = 0xFF00

This is rather odd to me. 0xFF00 looks like a potential mitigation against a integer overflow, as its possible the vulnerability stems from any packets being over 0xFFFF causing an integer overflow in memory, resulting in the allocation of a very small amount of memory to hold a very large buffer. At the very least, the fact that the recommended mitigation forcibly controls the max size of the packet that can be received suggests that this is a buffer overflow of some sort. Given the dynamic nature of DNS and the fact that it has to handle multiple requests at once, my guess is that its a heap buffer overflow.

Now that CheckPoint’s blog post is public one can confirm that this is in fact a integer overflow leading to a heap buffer overflow within the SigWireRead function of dns.exe, the server component of Microsoft’s DNS implementation. When the DNS server receives a SIG query response, that, when decompressed, incremented by 0x14, and added to the result of an earlier Name_PacketNameToCountNameEx call, is greater than 0xFFFF, will result in integer overflow, resulting in the following RR_AllocateEx call allocating too small of a heap buffer for the resource record, and a heap buffer overflow occurring when memcpy is called to copy the SIG query response into the overly small heap buffer that RR_AllocateEx allocated.

A very important point to note here is that whilst there is a RCE potential here by smuggling DNS requests over HTTP, it seems that CheckPoint has noted that only some browsers, notably Microsoft Edge and Internet Explorer, actually support sending HTTP requests to port 53, so whilst their video at <https://youtu.be/PUlMmhD5it8&gt; is certainly pretty cool, its important to note that with Google Chrome taking up over 65% of the browser market share according to <https://gs.statcounter.com/browser-market-share&gt; as of July 2020, and IE and Edge accounting for a combined total of roughly 4% of all browsers, its pretty unlikely that most organizations will be affected by the HTTP smuggling attack vector unless users are forced to use IE/Edge in their networks for some reason (such as support for legacy apps).

Edit: @cblack-r7 Also pointed out to me that looking at <https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability&gt; they mention this line “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.” He noticed that the terminology “upstream server” could mean that the malicious overly large DNS response has to come from an upstream resolver, which could complicate this vulnerability a little bit. This is also something that**@busterb**’s assessment seems to reflect concern about and is something that the CheckPoint blog doesn’t really address from what I’ve seen (though feel free to correct me if I am wrong here)

It should be noted that this vulnerability only affects Microsoft’s DNS implementation, however it goes way back all the way to Windows Server 2008. I wouldn’t be surprised if this also potentially affected Windows Server 2003 as well though, given how these types of vulns tend to be rather systemic, but I could be wrong there.

Another important point to note is that on Windows the DNS service runs as SYSTEM, so this will essentially be a remote SYSTEM level exploit for any attackers, which is pretty powerful. Unfortunately there is a limitation that if this is a remote RCE on the heap, the attacker will most likely have to deal with a lot of the new heap related mitigations introduced starting with Windows 8 and which were greatly improved with Windows 10. So this likely means that Windows Server 2008 and Windows Server 2008 R2 will be easy to develop an exploit for, but more recent servers like Windows Server 2019 may see a noticeable lag in exploit development time whilst exploit developers work their way around these mitigations. This can be seen in past heap overflow exploits where the Windows 7/Windows Server 2008 exploit came out very quickly but in some cases it took several months or even a year for the Windows 10/Server 2019 exploit to come out.

It should be noted that whilst this vulnerability has not been used in active attacks according to Microsoft, I’d safely place money on seeing this vulnerability get weaponized very quickly.

Assessed Attacker Value: 5
Assessed Attacker Value: 5Assessed Attacker Value: 4