DOH! DNS Over HTTPS Poses Possible Risks to Enterprises

Introduction

David Middlehurst of Trustwave SpiderLabs presented at the first ever conference dedicated to the Mitre ATT&CK framework earlier this week, on October 23, 2018. Mitre hosted the event ATT&CKcon at their offices in McLean, VA. The event saw some of leading security professionals in defensive and offensive realms come together. Mitre's ATT&CK has become a de facto standard used to make sense of adversary Tactics, Techniques and Procedures (TTPs). SpiderLabs leverages ATT&CK within its Red Team and Purple Team offerings.

The importance of a community driven response to some of the most advanced threats was a reoccurring theme at the conference. In this spirit, David who prides himself as one of our red teamers and penetration testers on the offensive side shared some of his research. That research covers a cutting-edge technique whereby trusted endpoints that correspond to a secure Domain Name System (DNS) alternative may be used for malicious purposes for delivery of payloads and command and control.

What is DNS over HTTPS (DoH)?

DNS over HTTPS (DoH) is one proposal on the table for solving some of the pitfalls of the traditional DNS resolution that underpins the Internet. The key issues being addressed in current DNS are the end user privacy implications and the possibility of Man-in-the-Middle (MitM) attacks which mean that a malicious party within the data path of resolution could interfere with the messaging. The DoH solution, described in RFC8484 ( https://tools.ietf.org/html/rfc8484), sees the sending of DNS queries and retrieval of DNS responses take place over HTTPS which provides security for integrity and confidentiality. In this DNS ecosystem DoH providers host a URI endpoint on the Internet that facilitates DNS resolution. An alternate approach to DoH is DNS over TLS (DoT), described in RFC7858 ( https://tools.ietf.org/html/rfc7858), but this approach requires direct outbound connectivity to port TCP 853.

Abuse of DoH

There has been a long history of the abuse of traditional DNS for the purposes of tunnelling data out of a network, for example abusing A and TXT record lookups. DoH brings its own new challenges to the enterprise. Firstly, improving the privacy of underlying DNS queries conducted over this channel could impact security monitoring. Secondly, the DoH providers host HTTPS endpoints which when accessed could look benign when observing outgoing connections.

The SpiderLabs Red Team implemented a Proof of Concept (PoC) command and control mechanism within the popular Adversary Simulation and Red Team Operations Software Cobalt Strike for the purposes of raising awareness of this as a technique as well as help defenders better understand the threat and protect their networks. The PoC which leverages DoH providers, called DoHC2, was shared with the community during David's presentation "Playing Devil's Advocate to Security Initiatives with ATT&CK" at Mitre's ATT&CKcon. The presentation also talked about potential ways in which ATT&CK can help in using knowledge from real-world attacks to improve the resilience of security initiatives by pre-empting ways in which they could be circumvented or abused.

You can watch David's presentation here: https://youtu.be/_HSkva44lFo?t=5155 and access the proof of concept code and slides from the presentation here: https://github.com/SpiderLabs/DoHC2.

The diagram below shows the path of command and control implemented by this PoC. This means that outgoing command and control traffic would only be observable as a series of connections to the DoH provider on the Internet rather than directly to attacker infrastructure.

    Command and Control via DNS over HTTPS (DoH)      
Command and Control via DNS over HTTPS (DoH)

To exacerbate the issue, the research also highlighted that at least one DoH provider ran their resolver endpoint on an IPV4 address that is shared with other services. This means that this technique can also be coupled with another known as "Domain Fronting" whereby a TLS connection is opened to one service but by leveraging the "Host" header in the underlying HTTP traffic (which is encrypted) actually routes the request to the DoH resolver. This can again make life more difficult for defenders.

Other Security Research

Since the presentation given by SpiderLabs at ATT&CKcon there has been an overwhelming response from the Information Security Community. So much so, that two other security consultancies, SensePost and Outflank have now also shared their research in this area in the days that followed. The research which ranges from other implementations of DoH for exfiltration and command and control to payload delivery techniques. On the defensive side, Nick Carr, FireEye has already highlighted in a  tweet some potential historic use of this technique and others such as Steve Miller have been working on possible detections. This community response only demonstrates the importance of the technique and that defenders should consider the risks it poses.

Mitigations

  •  
  • Block or more aggressively monitor traffic to DNS over HTTPS (DoH) endpoints. If wishing to benefit from some of the security benefits that DoH offers, roll out internal DoH, DNS over TLS (DoT) resolvers and/or carry out secure DNS resolution on the outermost DNS servers of the organisation.
  •  
  • Where possible inspect underlying HTTP exchanges for indicators of DoH use where TLS is stripped for inspection within an organisation. i.e. 'application/dns-json', 'application/dns-message' content types.
  •  
  • In the same manner, look for potential indicators of "Domain Fronting" whereby the outgoing TLS connection hostname does not match the underlying HTTP host header.
  •  
  • Apply heuristic based or anomaly-based detections of packet sizes, frequency and volume, time based, pattern of life to outgoing traffic.
  •  
  • Potential other detections being considered by defenders, where TLS stripping is not possible, involve fingerprinting any observable traits in the SSL client behavior using a tool such as JA3.

Trustwave reserves the right to review all comments in the discussion below. Please note that for security and other reasons, we may not approve comments containing links.