On 14 July 2020, cyber security vendor Checkpoint disclosed a high severity remote code execution vulnerability in Windows DNS Server. The vulnerability is 17 years old, affecting systems back to 2003. It affects what are known as SIG queries, queries that are part of the DNS service but are rare in practice.
The vulnerability affects all Windows server operating systems and can be exploited by sending a specially crafted DNS SIG response to a vulnerable server. DNS services are used by most organisations as part of Microsoft based networks, which means this issue is incredibly widespread.
DNS services run on a Windows server with elevated SYSTEM level privileges, meaning that malicious code executed through successful exploitation is run with the highest possible privileges. This allows it carry out any operation on the system.
Windows DNS services are required to operate Windows Active Directory (AD) instances, meaning that any organisation running Windows AD will have vulnerable servers within its network.
These DNS services are often run on Domain Controllers (DCs) in Windows environments – the central component of Windows domain security. In security terms, an attacker being able to remotely run code on a DC with SYSTEM privileges is close to a worst case scenario as it will enable them to access virtually any machine within the corporate network.
The vulnerability is being tracked as CVE-2020-1350. A patch is available as are some software changes that will prevent the attack.
Offensive use cases for exploitation
To exploit this vulnerability an attacker must first register a domain and point it to a DNS server which they control. This DNS server can then be configured to send a malicious DNS response containing the exploit payload whenever the domain is queried. If the malicious response is received by a server running a vulnerable Windows DNS service, the exploit will run and execute the attacker's code.
The attacker can then use this set-up to target a corporate network by forcing a computer within the network to run a DNS query for the attacker's domain. The request will be routed via the network DNS and reach the attacker's DNS server, which will then send the malicious response.
MDR Cyber assesses that there are three primary offensive use cases for exploitation of this vulnerability:
Gaining initial access – An attacker positioned external to a target network forces a machine within the network to query the malicious domain. Depending on how the network is set-up this could potentially be triggered by a user clicking a link to the domain, embedding an image which is remotely hosted on the attacker's domain into a phishing email, or even simply sending an email to the target from the attacker's domain. If the network is configured to route queries via an internal DNS server then the malicious response from the attacker's DNS server will be routed back via this server, thereby delivering the exploit.
The vulnerability could potentially also be exploited within a browser by hosting script on a malicious webpage which executes the query when a target browses to it.
Lateral movement to DC – An attacker who has gained initial access to a computer within target corporate network manually queries the malicious domain using NSLookup or a similar utility. The query is routed via the network DNS, often a DC, which then receives the exploit payload when the attacker's DNS server sends a response.
Autonomous malware propagation – An attacker deploys malware configured to query the malicious domain every time it runs on an infected computer and then use access to the network DC to automatically propagate itself. Stringing together successful exploitation could allow malware to autonomously spread across and between networks. Malware which spreads in this way is known as a "worm".
Threat forecast
Exploitation of this vulnerability had not been reported in the wild at the time of writing and no exploits have been reported as publicly available. However, due to its severity and potential usefulness for an attacker it is probable that threat groups with exploit development capability are actively working on developing a functional exploit and exploitation in the wild is likely in the immediate future.
Access to a DC can help accomplish a wide range of objectives and attackers seeking to maintain long term covert access to a network will often try to achieve this to help them maintain persistence and spread laterally.
DCs are however also targets in short more impactful attacks – ransomware operators often attempt to access DCs to enable them to run ransomware on every computer in a network. Due to this vulnerability's capability to provide immediate access to a network DC it is probable that ransomware operators will deploy exploits for this vulnerability in their operations as soon as they become available.
Mitigation options
- We recommend the following mitigations to help detect and mitigate this issue:
- Microsoft has released both a patch and a workaround to mitigate this vulnerability, details of which are available here. If patching is not possible then the workaround should be applied.
- Organisations should expedite deploying patches and implement the workaround as a temporary stopgap if immediate patching is not viable.
- SIG queries are rare and therefore enhanced monitoring is recommended if patches cannot be applied:
- Monitor Windows Event logs for event IDs 265 and 257. SIG requests will show as a QTYPE of 24. It is also possible to monitor the size of the response, which if over 64Kb may indicate further investigation is needed.
- Cisco Talos has released a Sigma rule to detect exploitation attempts for this vulnerability, which is available here. This rule can be added to firewall and IDS/IPS configuration to detect and/or block exploitation attempts.
- If organisations have access to and are able to query DNS logs in real time, investigate developing and implementing detection rules for anomalous DNS SIG queries and responses.
- Consider blocking SIG queries internally. It is usual to use DNSSEC internally which relies on SIG queries, but caution should be applied when making the change.