{"id":11779,"date":"2016-10-05T07:21:27","date_gmt":"2016-10-05T07:21:27","guid":{"rendered":"http:\/\/www.intelligentcio.com\/me\/?p=11779"},"modified":"2016-10-05T07:21:27","modified_gmt":"2016-10-05T07:21:27","slug":"why-dns-shouldnt-be-used-for-data-transport","status":"publish","type":"post","link":"https:\/\/www.intelligentcio.com\/me\/2016\/10\/05\/why-dns-shouldnt-be-used-for-data-transport\/","title":{"rendered":"Why DNS shouldn\u2019t be used for data transport"},"content":{"rendered":"

Malicious DNS tunnelling is a big problem in cyber security. The technique involves the use of the Domain Name System (DNS) protocol to smuggle sensitive corporate or personal information out of a network, and to enable malware command and control communications in and out.<\/span><\/p>\n

Indeed, as the Infoblox Security Assessment Report\u00a0revealed<\/span><\/a>\u00a0recently, two in five enterprise networks showed evidence of DNS tunnelling in the second quarter of 2016.<\/span><\/p>\n

However, all is not necessarily as it seems. Close scrutiny of apparent DNS tunnelling traffic repeatedly reveals an amount of anomalous activity which appears harmful but is, in fact, being sent intentionally by users and services on enterprise networks, and tended not to be malicious in nature.<\/span><\/p>\n

Exploiting the DNS protocol<\/b><\/span><\/p>\n

Typically DNS queries are very small data packets, and their intended purpose is not to transport any data other than that needed to perform name-resolution services. And, although the introduction of authentication mechanisms such as DNSSEC<\/span><\/a>\u00a0and DKIM may have changed the landscape over recent years, their primary intent is also only to serve up information on a domain name, rather than transporting any other data.<\/span><\/p>\n

But, there is sufficient flexibility in the DNS protocol that unrelated data can be inserted into a DNS query and then sent in to or out from a targeted network.<\/span><\/p>\n

DNS signalling, the most basic form of this technique, typically involves using a cryptographic hash function to encode information into query strings or response records. Performance tends to be quite slow though, as the restrictive size of DNS packets mean a large number are required even for a small amount of data.<\/span><\/p>\n

This is taken a step further by DNS tunnelling which, by employing surprisingly basic techniques, uses DNS queries to encode other protocols such as http, ftp or SMTP, over a DNS session.<\/span><\/p>\n

For the sake of simplicity, and given their essential similarity, both of these techniques can be viewed under the header of DNS tunnelling.<\/span><\/p>\n

\u201cLegitimate\u201d DNS tunnelling\u00a0<\/b><\/span><\/p>\n

Within an enterprise, the use of DNS for legitimate communications can often set off false alarms with networking and security teams on the lookout for malicious DNS tunnelling. Most companies that employ this unsanctioned use of DNS tend not to advertise the fact and this can present a challenge to security teams looking for insidious use of the protocol. After all, legitimate and malicious use can look practically identical at first glance.<\/span><\/p>\n

Of course, those using DNS in this way are generally taking creative shortcuts rather than deliberately abusing their organisation\u2019s networks.<\/span><\/p>\n

It all started around twenty years ago, when paywalls in certain hotels and airports blocked direct access to the internet via standard protocols such as HTTP. It was noticed, however, that DNS wasn\u2019t blocked and tools including NSTX, Dnscat and iodine were subsequently released allowing web sessions and email to be tunnelled through a user\u2019s DNS connection. Over the years these tools have evolved to provide full VPN services over DNS, with dozens of examples freely available on GitHub and elsewhere.<\/span><\/p>\n

Not a wise use of the protocol<\/b><\/span><\/p>\n

As well as setting off false alarms and raising concerns around theft-of-service, DNS tunnelling, even as a means of legitimate communication, is not a wise use of an organisation\u2019s DNS protocol. Indeed, using DNS to transport data is misusing the protocol to deliberately circumvent measures put in place by the network operator.<\/span><\/p>\n

It could be used to proxy past workplace productivity filters designed to block Facebook or personal email services, for example, or for something more sinister that could represent a risk to the whole company.<\/span><\/p>\n

However, it appears there are a large number of commercial products which use DNS signalling as a means of providing data transfer services.<\/span><\/p>\n

For example, at around the same time that DNS tunnelling was becoming popular as a technique, some manufacturers of customer presence equipment (CPE) were experiencing issues in sending updates out to their various consumer-grade Wi-Fi routers or cable and DSL modems across consumer and SMB networks.<\/span><\/p>\n

It transpired that there was some inconsistency on the various types of traffic allowed through certain ISPs, and setting up proper connections through NAT-based routers was proving less than straightforward. DNS was seen as being a viable alternative and it wasn\u2019t long before some of the CPE companies were using the protocol to perform software updates and other maintenance tasks with their installed base.<\/span><\/p>\n

Today, most enterprise-grade networks will handle such tasks using proper communications and authentication channels. Internal departments and branch offices can often have cheaper CPE equipment, however, meaning that these signals are being transported over DNS \u2013 even in an enterprise network.<\/span><\/p>\n

Elsewhere, the need for nearly continuous communication with their customers has seen some anti-virus (AV) vendors set up file hash identification routines via DNS. While this is undeniably a quick and effective way of determining whether a suspect file is infected or not, it can potentially open up a network to malicious communications.<\/span><\/p>\n

Circumventing controls<\/b><\/span><\/p>\n

Essentially, the main problem with DNS tunnelling techniques is that they circumvent controls put in place by a network team, opening up security, compliance and operational concerns while, at the same time, overloading the DNS protocol and anomaly detection systems put in place to examine DNS traffic.<\/span><\/p>\n

Businesses are increasingly trying to protect their DNS as its importance becomes clearer, and are beginning to realise how much extraneous DNS traffic is running on their networks.<\/span><\/p>\n

It\u2019s perhaps optimistic to expect the practice to stop completely, but efforts could be made to persuade IT vendors and manufacturers to become less reliant on it, and ultimately make it less difficult to secure this valuable and vulnerable protocol.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Malicious DNS tunnelling is a big problem in cyber security. The technique involves the use of the Domain Name System (DNS) protocol to smuggle sensitive corporate or personal information out of a network, and to enable malware command and control communications in and out. Indeed, as the Infoblox Security Assessment Report\u00a0revealed\u00a0recently, two in five enterprise […]<\/p>\n","protected":false},"author":20,"featured_media":11780,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[137],"tags":[138,2752,177],"class_list":["post-11779","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-cyber-security","tag-dns-tunnelling","tag-infoblox"],"acf":[],"publishpress_future_workflow_manual_trigger":{"enabledWorkflows":[]},"_links":{"self":[{"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/posts\/11779","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/comments?post=11779"}],"version-history":[{"count":0,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/posts\/11779\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/media\/11780"}],"wp:attachment":[{"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/media?parent=11779"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/categories?post=11779"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/tags?post=11779"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}