The dawn of the DNS over HTTPS era is putting business security and SOC teams to the challenge
In one way, the proliferation of domain name service (DNS) attacks throughout the world has helped to raise awareness about a deep problem in the “plumbing” of the internet. The infrastructure behind the DNS suffers from a lack of built-in security that is putting internet users at risk.
Decades of work on the Domain Name System Security Extensions (DNSSEC) specifications have been ongoing in a concerted effort to find a better way of securing the DNS while keeping it flexible enough for upscaling into enterprise, and even larger, networks. DNSSEC uptake, however, has been sluggish in most countries. Perhaps out of impatience for the incremental successes of DNSSEC, some have begun turning to new methods to secure DNS traffic, such as DNS over TLS (DoT), DNSCrypt, DNSCurve and, most recently, DNS over HTTPS (DoH).
Currently, we are witnessing a battle for control over the DNS with a push for securing the DNS over HTTPS. Since, traditionally, DNS requests and replies are sent in plain text, security operations center (SOC) teams overseeing corporate networks are able to monitor the domains being queried and block users from accessing malicious domains. Plain text DNS requests are certainly less private but intelligence from the DNS level has always been a critical data source for supervising the security of a network.
With the introduction of DoH, DNS requests are encrypted via the HTTPS protocol, thus hiding them from the easy oversight of network defenders. Leaving aside other aspects of DoH, such as privacy and centralization of control over the internet, let’s discuss how the security of private and public networks is affected.
Loss of visibility challenges business security
For SOC teams, the negative effect of DoH is that it blindsides them to malware communication that can more easily masquerade as normal HTTPS traffic in the network. As DNS pioneer Dr. Paul Vixie emphasized in an interview with ESET Security Evangelist Tony Anscombe:
As a network operator…I need to see what my users and applications and devices are doing in DNS in order to know which one of them is an intruder, which one of them is malware, which one of them is part of a botnet, which one of them is a poisoned supply chain…I have to be able to see that in order to keep my network secure, and so anybody who comes along with a project like DNS over HTTPS that says ‘Yeah, we want to make it impossible for the network operator to interfere with DNS operations’, they don’t understand my life at all.
Malware often communicates to a command and control (C&C) server via HTTP and HTTPS – identified by the MITRE ATT&CK knowledge base as a standard application layer protocol technique. ESET Research, for example, observed PolyglotDuke – a then newly discovered downloader employed by the Dukes (APT29) in Operation Ghost – fetching C&C URLs from social media services such as Twitter and Reddit, and then contacting those C&C servers to drop the MiniDuke backdoor on victim computers.
As a means of hiding the malicious nature of this communication, the Dukes encoded the C&C URLs by using character sets from different languages, specifically Japanese, Cherokee, and Chinese – hence ESET dubbing this downloader as “PolyglotDuke”.
What if malware could hide its communication behind DoH? In fact, Proofpoint researchers found a new sextortion module update of the PsiXBot malware that uses Google’s DoH service to fetch C&C IP addresses, which allows attackers to hide the DNS query behind HTTPS. The Dukes and other threat actors could potentially expand their toolkits to use DoH, which would obviously help towards hiding C&C communications in the future from the eyes of IT administrators.
DNS encryption, while bringing some good, disables some of your protections. This affects primarily network-based security solutions, underscoring the importance of having a quality, multi-layered endpoint security solution in place.
Gaining visibility into malware communicating via encrypted DNS
SOC teams are well-advised to stay informed about the latest efforts of Mozilla, Google and others to provide DoH. In this way, IT admins can update the software and configurations of network traffic inspection devices to block access to new DoH services as they arise. Google, for example, offers DoH over certain stable addresses that admins can block at the firewall level.
Blocking or disabling known DoH services, however, is only a first step toward detecting malicious uses of encrypted DNS requests in your corporate network. More advanced SOC teams should be using an endpoint detection and response (EDR) tool that enables them to identify and capture malicious-looking DNS query events, among many other types of events, and to investigate connections to malicious C&C servers.
In terms of monitoring DoH traffic from Firefox and Chrome browsers, one way for SOC staff to maintain visibility is by installing custom security certificates on endpoints and routing browser traffic via a proxy. This would enable setting up a network traffic inspection solution that understands DoH, can conduct HTTPS inspection for inline decryption, inspection, logging, etc., and forward any events to an EDR tool for further analysis.
Note that while some browsers do check for pinned certificates, a locally installed security certificate can override the usual checks. Neither Firefox nor Chrome browsers at the time of this writing, however, are checking for pinned certificates.
There are other options for dealing with DoH. Similar to setting up internal DNS servers, enterprises can also set up internal DoH servers that allow for seeing all requests. Alternatively, DoH can simply be turned off, as Mozilla offers for their Firefox browser.
The technical solutions for addressing the security issues of the DoH protocol are varied. Going forward, what is crucial for the success of any SOC team is to learn to appreciate the increased capabilities that this new protocol can lend to malicious actors as well as its cascading effects on network security. In this way, a suitable security policy concerning the use of DoH can be set in place for your business and enforced by your SOC team.
Author: René Holt, PR content writer for ESET
