July 2020 is an interesting month at the InfoSEC level. In the last month, many security issues have occurred on various platforms, from Bitcoin Scam on Twitter, or F5 BIG-IP devices craziest vulnerability, and many other ransomware attacks on organizations. 
As usual, security issues don’t miss any person, organization, or country, and attacking everything is possible (or not possible) – sometimes when there’s, a motivation then the damage is most offensive as we saw a lot of times.
One of the critical vulnerabilities found in the past week (July 2020) is Microsoft-based DNS servers – SIGRed, and this is a very critical weakness that can be leading to a full domain admin privileges and wormable!

SIGRed (CVE-2020-1350) Vulnerability

SIGRed as known as CVE-2020-1350 is a critical, wormable RCE vulnerability in the Microsoft based DNS Windows Server, that can be triggered by an attacker with malicious DNS response.
It received a CVSS base score of 10, and according to the Check Point researchers who found this 17-year-old flaw, the possibility of exploitation is very high.
Microsoft released a patch near the time of publishing the SIGRed research and conclusion.
The patch for the SIGRed vulnerability (CVE-2020-1350) affects all Windows Server versions from Windows 2003 Server to Windows Server 2019.
The Windows DNS Server is an essential part of the Active Directory Domain Services environment and runs the DNS queries on Windows Server itself.

SIGRed Interesting points

Researchers found a Heap-Based Integer Overflow “dns.exe!SigWireRead” with the function that parses the SIG queries.
SIG “Signature record”, is a DNS record type used in (RFC 2931) and TKEY (RFC 2930), from RFC 3755, RRSIG is designated as a replacement for SIG to use with DNSSEC.
The meaning is by sending a DNS response that contains a large and higher than 64KB SIG record, we can cause a controlled heap-based buffer overflow of roughly 64KB over a small allocated buffer.”
This vulnerability can be exploited remotely through HTTP payload, by “sending it to the target DNS server on port 53 causes the Windows DNS Servers to interpret this payload as if it was a DNS query.”
Microsoft implemented the DNS client, and DNS server in two different modules, and the DNS client and DNS server are implemented in two different modules:
DNS Client – dnsapi.dll is responsible for DNS resolving.
DNS Server – dns.exe is responsible for answering DNS queries on Windows Server, in which the DNS role is installed.
The fact that this vulnerability does not exist in dnsapi.dll, as well as having different naming conventions between the two modules, leads us to believe that Microsoft manages two completely different codebases for the DNS server and the DNS client, and does not synchronize bug patches between them.
Kudos to the Checkpoint Research who found the original vuln and published, for SIGRED’s excellent research and article at the following link SIGRed – Resolving Your Way into Domain Admin: Exploiting a 17-Year-old Bug in Windows DNS Servers

SIGRed more highlight

Additional highlights for the SIGRed vulnerability
Attack Vectors

• The issue in how DNS.EXE parses response of recursive queries
• Endpoint requests lookup of record
• Malicious authoritative DNS Server returns a crafted payload
• Responses that contain “SIG” resource records may trigger the vulnerability as they are parsed by QuerySigWireRead
• Integer overflow flow in a function that parses incoming responses if larger than 64KB: SIG resource record
• Can be triggered through Internet Explorer due to “Connection Reuse” and “Pipelining” features: https://malicus-dns-site:53/

The Wormable Side

• Exploit does not require authentication
• Allows Remote Code Execution
• Execution is with SYSTEM level privilege
• Most systems have a Microsoft-based DNS server configured

Direct Impact

• DNS Server on the Internet Can be queries directly and Access to an internal network
• SYSTEM privileges on Domain Controller Compromise of entire Active Directory
• SYSTEM privileges on nonDomain Controller Ability to respond to DNS queries with attacker responses resulting

For example, security search engine platforms that scanning the internet all over time, providing many results, and a quick search on Shodan providing results for Microsoft Windows DNS server with port 53 opened…

Any PoC yet?
(the next section on the blog-post taking it to a different place)

• Nothing public yet but Check Point has the code
•  Be careful with fake code
• DNS.exe was compiled with Control Flow Guard (CFG) – makes exploitation harder
• Proof of Concept and Weaponized Exploit Code expected any time
• Microsoft rated Exploitability as “1 – Exploitation More Likely”

Incident

• A compromised Domain Controller means your Active Directory is compromised
• More difficult than Incident Handling of other vulnerabilities seen in 2020
• Seek professional assistance – if required

While you were sleeping

CheckPoint’s official PoC has not yet been released, but the network contains dozens of unofficial PoCs, and most of them (if not all) are fake, so it’s not worth checking them.
“While you were sleeping” the internet, as usual, did not stop for a moment and many unofficial SIGRed PoC came out, and one of them was very entertaining because it illustrates that at the right time people downloading everything available and activate it.

So how it looks like when you create a binary, a few bash scripts, a README on the right timing for CVE-2020-1350? this how the Internet thrilled:
The most popular repo was from ZephrFish and the code in question can be found here

People react to this repo…

The code in the repo is loaded with canary tokens and just doing a general trolling

“This is a particularly “amusing” troll because the sort of people who keep up with CVEs and look for proof-of-concept exploits should really know better than to run random code they just got off GitHub without checking what it does. It’s obvious with the most cursory examination of the code in the repo that you shouldn’t run it.”

Kudos to ANDY GILL who once again show that YOU SHOULD NOT RUN CODE BLINDLY!

SIGRed Vulnerability and Microsoft Update

On July 14, 2020, Microsoft released a security update for the issue that is described in SIGRed (CVE-2020-1350) for Windows DNS Server Remote Code Execution Vulnerability and updated again on July 15, 2020.
This advisory describes RCE vulnerability that affects Windows servers that are configured to run the DNS Server role, and it’s strongly recommended to apply the security update ASAP.
A registry-based workaround can be used to help protect an affected Windows server, and it can be implemented without requiring to restart the servers. Because of the volatility of this vulnerability, you can implement the workaround before they apply the security update to enable them to update their systems by using a standard update process.

Patching the SIGRed Vulnerability

The best way to remediate the SIGRed vulnerability is by patching immediately, using the patches released by Microsoft.
Note: No user action is required if you have auto-updates enabled.
The workaround mitigates the risk from SIGRed with 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)
When a 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.

Protect with Azure Sentinel

Azure Sentinel can identify and protect against malicious payloads over DNS and other malicious DNS activities (Direct or indirect activities), including valuable insights into the various stages of the kill chain process.
In a general, DNS attack is on the wild (not SIGRed) and there are many types of DNS attack (common example)

Azure Sentinel can provide various ways to identify, detect, investigate, and respond to SIGRed and other DNS attacks. With SIGred it a bit different because of the way SIGRed working and how its payload of the SIG response.
The current way to protect SIGRed is based on the knowledge we’ve so far from Checkpoin’s research, a specific PoC, and the ways that DNS collecting the traffic.

The LAB Resources

The SIGRed lab includes the following resources:

• Azure Sentinel Workspace
• Azure Sentinel Connector with Security, DNS, and zScaler
• Domain Controller with DNS role and Windows 10 VM’s
• PoC based CVE-2020-1350 (SIGRed) – Windows DNS DoS Exploit – DO NOT TEST ON PROD
• DNS Debug with advanced logging
• Sysmon (installed and registered on event viewer) – will be updated when official PoC will be released
• Azure Network Watcher (optional if Domain Controller or DNS server is based on Azure VM) – – will be updated when official PoC will be released

Configuration Highlights

The following settings and configuration are based on event log only DNS-Client log only and Data Connectors.
First, make sure to Activate the Azure Sentinel Data Connectors for DNS and Security Event
DNS is for DNS Client activities logs for Type 24 and Type 25
Security Event is for SYSTEM activities (as the service is running in elevated privileges)

Azure Sentinel Windows Event Logs – add the following logs name to Azure Sentinel
Microsoft-Windows-DNS-Client/Operational
Microsoft-Windows-Sysmon/Operation

Set DNS Debug logging with all option for send and receive packets

Set Sysmon on Domain Controller with the command: sysmon -i -accepteule

Run SIGRed PoC – Run the unofficial CVE-2020-1350 (SIGRed) – Windows DNS DoS Exploit PoC with the following command: (DO NOT Test on PROD)
python sigred_dos.py sigred.google.com
Note: General Setup information available on PoC page

At this moment you should receive a few events and if you will run nslookup you should see the process running.

Because DNS traffic (specific SIG) using the RFC 2930 (SIG), RFC 2931 (TKEY), and RFC 3755 (RRSIG) we should check for the specific type id: 24 and 25.

Note: List of DNS record types including Type ID and RFC’s

Configure Azure Sentinel Rules

the simplest way to find type id on Azure Sentinel is to run KQL command:

Create Analytics Rule

To create Analytics Rule copy the query above and add it to the rule



Azure Sentinel Tip
Do you want to check if your DC’s and DNS servers are installed with the relevant KB’s? run the following KQL: