Bypassing Firewalls with DNS Tunnelling (Defence Evasion, Exfiltration and Command & Control)

[Music] hey there i'm andy and in this video we'll be exploring how to attack detect and defend against dns tunneling the typical setup for dns the system that turns human friendly domain names into machine-friendly iap addresses is to configure each network device with the ip address of one or more local dns servers those local dns servers will typically be authoritative for the local domain name but won't necessarily have knowledge of all other dns names so if a client requests a dns lookup for a name which the local server doesn't know the answer it tries to find which server out on the internet is the authoritative server for the requested domain this is achieved in a hierarchical process working from the back of the domain forwards so in this example the local dns server will first ask one of the internet root servers for the authoritative server for the dot-com domain it'll then connect to that server and ask for the authoritative server for example.com it'll then contact that server and ask for the authoritative server for somewhere.example.com it can then ask that server for the ip address of www.somewhere.example.com the result is then passed back to the client that requested it by the local server note that at no time throughout this process was there ever any communication between the client and any other device other than the local dns server that local dns server did all the hard work on behalf of the client also note that dns is a critical service for most networks and as such is typically allowed to pass through many firewalls dns tunneling provides a means of encapsulating malicious payloads within dns requests so that they can take advantage of the relatively free flow of dns traffic especially in cases where almost all other traffic is restricted to see dns tunneling in action imagine the following network where the firewall is configured to only permit dns traffic to pass and only if it originates from the designated local dns server our attacker fires up something like dns cat 2 to start listening on port 53 and responding to dns requests for evilhacker.com the ip address of this attacker is configured as the authoritative server for that domain name on the victim machine the attacker can run the client part of dns cat specifying the target domain of evilhacker.com a connection is established and from here the attacker can perform a variety of commands over this channel such as uploading and downloading files executing programs tunneling tcp sockets and launching an interactive shell we can see from a network capture that the victim machine is making dns requests to its local dns server and these are getting forwarded onto the relevant authoritative server for anything ending in that's the attacker's machine the communication from the victim to the attacker is encoded in the dns names being requested and the communication back from the attacker is encoded in the reply for that dns name the victim's local dns server then dutifully forwards the response back to the victim we can't see anything that makes much sense to our eyes in this packet capture as the data being transferred has to be encoded so that it forms a valid dns name also the dns cat software being used by this attacker uses an encryption layer but this isn't always the case i covered an example of where this happens in one of my videos from the 2018 sans holiday hack one of the bigger challenges in that ctf was investigating some powershell malware where the dropper used dns tunneling to download the malicious payload in that case the payload could be extracted from a packet capture as it was hex encoded but not encrypted this also nicely demonstrates how easy it is for an attacker to code dns tunneling capabilities into their own malware so as not to need to rely on separate apps like dns cat numerous other apps do exist however with some having less of a focus on malicious activity and are more orientated around bypassing captive portals if you've ever used a public wi-fi hotspot you've probably encountered a captive portal that's annoying page that pops up when you connect demand in payment or just trying to hoover up some personal details before letting you access any websites the restriction is typically implemented to stop traffic flowing from the device to the internet but the device can usually reach a dns server on the internal network and this is where dns tunneling comes in once again tools like iodine can be configured on a remote server to listen out for specially crafted dns requests in a similar way to dns cat the client trapped behind the captive portal can then run the client portion of iodine to create a layer 3 vpn transported over dns queries the device can then be configured to route all traffic over this link the end result is a bypass of the captive portal allowing access to internet sites without having to fill any of its demands [Music] we already saw from the network packet capture in the previous section that dns tunneling is fairly conspicuous by the frequency of dns requests clustered together the use of non-human readable domain names and in many cases the long request and response names a security onion sensor has been monitoring this network during the course of the attack and has recorded similar details under the zeke dns section these names again stick out to a human operator in this lab environment but will likely get lost in the background noise in a real deployment unless some custom dashboards are created for the purpose security onion also has a surikata ids instance running which has flagged up a couple of alerts about possible dns tunneling in my testing these alerts were only triggered when using iodine no alerts were raised in response to the use of dns cat although there are paid 4 rule sets available which claim to be able to alert on this too [Music] dns filtering provides a good defensive control against dns tunneling each time a dns server receives a lookup request it is compared to a block list of known malicious domains if the domain is on the block list the ip returned is that of a benign server instead when the client then attempts to communicate with this benign server it returns the message back saying that the requested domain is blocked this obviously depends on a good data set of known good or no and bad domains and thankfully many organizations provide just that opendns now part of the cisco family is one such provider who also wrap up their block lists within their own dns server the captive portal system can be reconfigured to use the opendns servers for all of its lookups and also configured to use those same servers for any dns lookups that any client devices send it with that in place we can check the captive portal is still blocking internet access but this time an attempt to tunnel through with iodine fails and nslookup on the evil hacker.com domain returns this address which is an open dns server not the host which is running the iodine server and if we quickly just disable the captive portal for one moment we can verify that any attempt to navigate to that site gets bounced to a block page so although it depends on using an up-to-date block list dns filtering has the advantage of protecting against a whole bunch of bad stuff related to malicious domains not just dns tunneling that about wraps up this video if you found it useful please do give it a like and consider subscribing if you want more of this sort of content drop a note in the comments if there's anything you think i missed around attacking detecting and defending against dns tunneling or if you have a good idea of what topic i should cover next i'll see you next time

Channel: Attack Detect Defend

Views: 14,966

Keywords:

Id: 49F0co_VrTY

Length: 8min 59sec (539 seconds)

Published: Tue Nov 10 2020