By: Ron Lifinski, Cyber Security Researcher
DNS Tunneling
Most organizations have a firewall that acts as a filter between their sensitive internal networks and the threatening global Internet. DNS tunneling has been around for a while. But it continues to cost companies and has seen hackers invest more time and effort developing tools. A recent study[1] found that DNS attacks in the UK alone have risen 105% in the past year. DNS tunneling is attractive–hackers can get any data in and out of your internal network while bypassing most firewalls. Whether it’s used to command and control (C&C) compromised systems, leak sensitive data outside, or to tunnel inside your closed network, DNS Tunneling poses a substantial risk to your organization. Here’s everything you need to know about the attack, the tools and how to stop it.
Introduction
DNS tunneling has been around since the early 2000s, when NSTX[2] – an easy to use tool has been published to the masses. Since then there was a clear trend – tighter firewall security led to more widespread DNS tunneling. By 2011 it had already been used by malware such as “Morto”[3] and “Feederbot”[4] for C&C, and by the popular malicious payload for point-of-sale systems – “FrameworkPOS”[5] for credit card exfiltration.
Why It’s a Problem
DNS was originally made for name resolution and not for data transfer, so it’s often not seen as a malicious communications and data exfiltration threat. Because DNS is a well-established and trusted protocol, hackers know that organizations rarely analyze DNS packets for malicious activity. DNS has less attention and most organizations focus resources on analyzing web or email traffic where they believe attacks often take place. In reality, diligent endpoint monitoring is required to find and prevent DNS tunneling.
Furthermore, tunneling toolkits have become an industry and are wildly available on the Internet, so hackers don’t really need technical sophistication to implement DNS tunneling attacks.
Common Abuse Cases (and the tools that make them possible)
- Malware command and control (C&C) – Malware can use DNS Tunneling to receive commands from its control servers, and upload data to the internet without opening a single TCP/UDP connection to an external server. Tools like Dnscat2 are made specifically used for C&C purposes.
- Create a “firewall bypassing” tunnel – DNS Tunneling allows an attacker to place himself into the internal network by creating a complete tunnel. Tools like Iodine allow you to create a common network between devices by creating a full IPv4 tunnel.
- Bypass captive portals for paid Wi-Fi – A lot of captive portal systems allow all DNS traffic out, so it’s possible to tunnel IP traffic without paying a fee. Some commercial services even provide a server-side tunnel as a service. Tools like Your-Freedom are made specifically for escaping captive portals.
How It Works
- The attacker acquires a domain, for example, evilsite.com.
- The attacker configures the domain’s name servers to his own DNS server.
- The attacker delegates a subdomain, such as “tun.evilsite.com” and configures his machine as the subdomain’s authoritative DNS server.
- Any DNS request made by the victim to “{data}.tun.evilsite.com” will end up reaching the attacker’s machine.
- The attacker’s machine encodes a response that will get routed back to the victim’s machine.
- A bidirectional data transfer channel is achieved using a DNS tunneling tool.
Common DNS Tunneling Toolkits
To better understand how hackers deploy this technique, let’s examine three of the popular tools that implement DNS Tunneling.
DNScat2
Introduction
Most of the other DNS Tunneling tools focus on tunneling TCP traffic using DNS, but this tool is different. DNScat2[6] is designed to create an encrypted command and control channel over the DNS. It borrows some concepts from Metasploit’s handler and is made with ease of use in mind.
Components
The tool is divided into two components, a client and a server. The client is written in C and the server is in Ruby.
The server is long-lived and can support connections from many clients, which makes it a basic C&C server. It will need to run first, before any of the clients.
After running the server, the client can run. This will open a session with the server that can either traverse the DNS hierarchy, which is the recommended way, or connect directly to the server via raw UDP. Going through the full DNS hierarchy requires an authoritative domain but will bypass most firewalls, since the DNS traffic is exchanged with the default server configured on the machine.
Connecting directly to the server is a useful feature for testing but is a lot more likely to be blocked by a firewall.
Features
- Encryption – All new connections are automatically encrypted. And it even supports two methods for countering man-in-the-middle attacks – passing a pre-shared secret, and verifying a short authentication string.
- Tunnels – Even though the tool is meant for C&C, it supports traditional tunnels that allow you to forward TCP traffic. This allows for SSH and HTTP to be tunneled through the session with ease.
- Sessions – DNScat2 has borrowed the concept of sessions from Metasploit. Each session is opened separately and can be interacted with. This allows the attacker to open as many tunnels with as many clients as he wants. And even to open a command shell in a separate session similarly to Metasploit’s handler.
Problems
- Limited tunneling – Can only tunnel TCP traffic.
- Overly simplified – Sacrifices versatility for ease-of-use.
- Limited to sessions – Session management can get tedious when dealing with too many clients.
- Slow performance – The use of CNAME and MX records makes DNScat2 slow compared to performance-focused tools like Iodine.
Screenshots
List of possible commands in a session
Forwarding the victim’s TCP port 22 through the tunnel
Iodine
Introduction
Iodine[7] lets you tunnel IPv4 data through a DNS server. It creates a network interface on each of the clients and connects them together as if they shared the same network. This feature is unique to Iodine since other DNS tunneling tools focus on tunneling specific ports, and not the entire IPv4 traffic. This allows computers to ping each other, access all UDP/TCP ports and all other protocols that are encapsulated by an IP header.
The tool runs on Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD and Windows and requires a TUN/TAP device. It also comes built-in with Kali Linux.
Components
Iodine comes with as two executable files: iodined (The server), and iodine (the client).
To run the server, you need control over a real domain, and a server with a public IP address to run it on. then delegate a subdomain to the server.
The client is passed one or two arguments, the first is the local relaying DNS server, and the second is the domain by the server. If the first argument is not specified, the system’s current DNS setting will be used as a relay.
Features
- Self-optimizing – The response fragment size is normally auto probed to get maximum bandwidth. And several DNS request types are supported, so the best request type is auto-detected and used.
- High performance – The use of NULL type allows the downstream data to be sent without encoding. Each DNS reply can contain over a kilobyte of compressed payload data.
- Portable – Runs on many different UNIX-like systems as well as on Windows.
- Authentication – While not supporting full encryption, Iodine allows authentication using a simple password. It also keeps track of the authenticated IP Addresses that can access it.
- Creates a network – Iodine is the only tool that creates a full network, and handles setting IP address on interfaces automatically. Up to 16 users can share one server at the same time.
Problems
- IPv4 only tunnel – Iodine can’t tunnel IPv6 traffic inside the tunnel.
- Not encrypted – The tunneled data is not encrypted at all. To avoid this problem, you’d have to use a VPN inside the DNS tunnel or use SSH.
- Driver Requirement –The client can’t run on Windows without a TAP-Windows driver. This makes it impossible to run it silently or include it in malware.
Screenshots
Running the server on the attacker’s “Kali Linux”
Running the client on the victim’s Windows machine
Opening a bind shell on port 666 on the victim’s machine
Connecting to the bind shell via the DNS tunnel
Heyoka
Introduction
Heyoka[8] is an exfiltration tool that uses spoofed DNS requests to create a bidirectional tunnel. The tool is not under active development anymore and according to its authors, is up to 60% faster than other tools by using binary encoding and NULL records. Heyoka also focuses on stealth by sending spoofed DNS traffic from other hosts in the network. This makes detection by a firewall and locating the machine that’s tunneling much harder. With that said, it currently works only on Windows.
Components
Heyoka comes as a single executable that can run in two modes: master and slave. The master acts as a server and will listen on a local port, for example, 2222. The slave acts as a client and will forward one of its ports, for example, 22 through the tunnel and allow the attacker access to it by connecting to 127.0.0.1:2222 on the master machine. In this example, the victim’s SSH port will be exposed through DNS.
Features
- High performance – The tool uses NULL records and binary encoding, which allow for a high throughput of data.
- Native executable – The tool is written in C, which means that it runs natively without the need of interpreters installed on the machine. The client and server aren’t required to have anything pre-installed
- Stealth mechanism – The tool uses unique patterns of data exfiltration. It maps out the network using ARP and spreads the tunnel across the entire network by spoofing DNS traffic. By limiting the spoofed traffic to those IP addresses, and by using the correct IP/MAC address combinations, a few anomalies can be detected.
Problems
- Buggy Alpha – The project has been abandoned and stopped development. So it might work, but it’s extremely buggy and very unstable.
- Windows only – While the developers claim that porting to a Unix-like operating system would not be too difficult, a working version of such code is not readily available yet. Since most attackers prefer using OS distributions like Kali Linux, using Heyoka would require setting up a new machine.
- Not encrypted – Just like Iodine, the tunneled data is not encrypted and can be inspected and modified by a third-party.
- Noisy – While Heyoka attempted to avoid detection by a firewall, it exposed itself to detection at an endpoint level. Heyoka generates an exceptionally high amount of DNS traffic due to the spoofing mechanism. It’s easily detectable on endpoints.
Screenshots
Running the server on the attacker’s Windows machine
Opening a bind shell on the victim’s Windows machine and running the tool
Receiving the connection on the server and interacting with the bind shell
Packet Capture (showing plain text data)
Summary
A firewall is no longer enough to separate an internal network and keep it safe, and DNS tunneling is just one of the creative techniques that cybercriminals use to escape internal networks. For example, Heyoka’s stealth mechanism proves that what’s invisible from the firewall’s perspective, is obviously malicious from the endpoint’s point of view. To combat DNS tunneling, the burden has shifted away from the network to the endpoint. Security professionals and vendors must examine incoming and outgoing traffic at the endpoint to detect and defeat these attacks.
References
[1] HTTPS://WWW.INFOSECURITY-MAGAZINE.COM/NEWS/DNS-ATTACK-COSTS-SOAR-105-IN-UK
[2] HTTP://THOMER.COM/HOWTOS/NSTX.HTML
[3] HTTPS://WWW.SYMANTEC.COM/CONNECT/BLOGS/MORTO-WORM-SETS-DNS-RECORD
[4] HTTPS://CHRISDIETRI.CH/POST/FEEDERBOT-BOTNET-USING-DNS-COMMAND-AND-CONTROL/
[5] HTTPS://WWW.GDATASOFTWARE.COM/BLOG/2014/10/23942-NEW-FRAMEWORKPOS-VARIANT-EXFILTRATES-DATA-VIA-DNS-REQUESTS
[6] HTTPS://GITHUB.COM/IAGOX86/DNSCAT2
[7] HTTPS://GITHUB.COM/YARRICK/IODINE
[8] HTTP://HEYOKA.SOURCEFORGE.NET/
source: https://www.cynet.com/blog/how-do-hackers-use-dns-tunneling-to-own-your-network/