DNS Tunnelling 2023

In this article we will learn about DNS Tunnelling.

What is DNS Tunnelling?

You all know what DNS is and I don’t think you need any more information about it. Our Internet world exists because of DNS technology, and using DNS can cause the Internet to be down for a day or a month or in a certain area. One of the common attacks we heard about in 2012 was Operation Global Blackout, in which the attacker “Anonymous” threatened to take down the entire global Internet. Computer security experts were concerned and used additional layers of protection to secure the network, especially DNS.

Have you ever come across a scenario where you were unable to access a website because it was blocked by a proxy? Then you need to use DNS tunneling concepts to bypass the proxy. Using DNS tunneling, the user will be able to access the website even if the proxy server is blocking the website. Normally, when you think of a proxy server, all HTTP traffic will be received by the proxy server, but no DNS traffic will fall to the proxy server. So using this DNS traffic will allow us to use all blocked websites as well.

So in a DNS tunnel, the data is encapsulated in DNS queries and responses using base32 and base64 encoding, and the DNS domain name lookup system is used to send the data in both directions. So if you can look up domain names on the network, you can tunnel any kind of data you want to a remote system, including the Internet. We use DNS records (NULL/TXT/SRV/MX/CNAME) to encapsulate (downstream) IP traffic.

In the above scenario, users A and B are behind corporate firewall D, and no websites are allowed from users A and B, and only port 53 traffic is allowed from firewall D. Users A and B can use the Internet DNS traffic through DNS tunneling. The DNS server on the left has a caching capability so that when user A tries to access any sites that are already cached, the request does not go to the iterative server.

If any new request is initiated from user A, the DNS server does not find its A record in the DNS server, so it sends it to an external DNS server. The maximum length of a DNS query is 255 characters with a limit of 63 characters per label and is in the form: label3.label2.label1.example.

To tunnel data through DNS, we need control over the external DNS server (in our case the DNS server on the right) and add two records to the external DNS server.

One is an NS record and the other is an A record. An NS (name server) record allows you to delegate a subdomain of your domain to another name server. So if you have a laptop.com domain, you can add an NS record like a.laptop.com NS computer.com, which means any DNS query for laptop.com will be delegated to computer.com and its subdomains. The second is the A record, which contains the mapping of an IP address to a domain name.

Now, if we need to set up a DNS tunnel server, we can install Iodine, DNS tunneling script, DNScapy, etc. So there must be a DNS tunneling client in the final machine. Once the connection is done, we can use the SOCKS proxy for an uninterrupted connection. DNS tunneling is inefficient and the speed is slow. DNS traffic has limited bandwidth for passing data because it only has the ability to pass small pieces of information such as the DNS request and response.

However, botnets can use DNS tunneling to act as a covert channel, and these covert channels are very hard to detect. These can only be identified by looking for any C&C information on DNS in the hidden channel. In all network systems today, DNS is served as is, but protocols such as HTTP, FTP are one of the many methods of traffic analysis and control. Botnets using DNS tunneling therefore have a better scope for malware authors. Here are some DNS tunneling tools:

DNS TUNNELLING TOOLS

OzymanDNS

Dns2tcp

Iodine

Heyoka

DNSCat

NSTX

DNScapy

MagicTunnel, Element53, VPN-over-DNS (Android)

VPN over DNS

With DNS tunneling, requests from clients will be fragmented and sent as separate DNS queries. Similarly, it will be necessary to split the response traffic. DNS uses UDP rather than TCP, so fragmentation and proper assembly must be done on the fake server.

DNS tunnels are commonly used to perform covert file transfers, C&C server traffic, and web browsing. File transfer over DNS is likely to aggressively use DNS traffic due to DNS protocol and encapsulation overhead for tunneling data. C&C server traffic will be minimal as only normal traffic patterns will be observed. Browsing the web using a DNS tunnel is a combination of both of the above.

Security engineers should immediately write signatures to detect such traffic. Some techniques for DNS tunnel detection are flow-based detection and character-based frequency analysis.

Detection

DNS tunneling can be detected by monitoring the size of DNS queries and responses. It is likely that tunneled traffic will have more than 64 characters in DNS.
Another detection mechanism is the use of updated IPS and IDS.
Rules must be configured to monitor a large number of DNS TXTs on a DNS server.
Rules must be configured in the SIEM to trigger when the volume of DNS traffic from a particular source is very high.
Another method is to use the concept of split-horizon DNS, so that internal addresses are handled on a specific server; clients should use a proxy server to connect to the Internet, and the proxy server resolves the external DNS for them. Some proxies also have the ability to check DNS information.
DNSTrap is a tool developed to detect DNS tunneling using an artificial neural network. This tool uses five attributes to train an artificial neural network (ANN) to detect tunnels: domain name, number of packets sent to a specific domain, average length of packets to that domain, average number of distinct characters. in LLD and distance between LLD.
Next-generation firewalls such as Paloalto and Fire Eye have the ability to detect DNS tunneling.

Also Read:Ethical Hacking Interview Questions 2023

References

http://psichron.za.net/downloads/dns_tunneling.txt

http://www.splitbrain.org/blog/2008-11/02-dns_tunneling_made_simple

http://arxiv.org/ftp/arxiv/papers/1004/1004.4358.pdf