Thursday, December 21, 2017

Tunneling your connection over DNS

Tunneling traffic over DNS

Disclaimer: I am not responsible for any misuse of this tool and any malice you decide to commit with it. This article was written to educate security professionals about covert channels used to circumvent traffic filtering/blocking. 

Writing a brief post about how to tunnel traffic over DNS. Nothing fancy, just using a tool to get the job done. DNS tunneling is nothing new. It has been around for a while see https://dankaminsky.com/2004/07/29/51/. 

Why would you want to tunnel your machine's traffic over DNS? 

DNS tunneling can be used for many things but not limited to the following:
  • Covert channel to hide traffic
  • Getting around pay walls(captive portals) at airports or public wifi spots
  • Exfilling data from a corporate environment 
  • Tunneling a protocol which is blocked in your environment (like SSH)
Some downsides of using DNS as a communications channel are the following:
  • Slow and inefficient. DNS traffic has limited bandwidth.
  • UDP is used as the protocol for it's packets
To the first point, transfer limit is stated in RFC2035 https://tools.ietf.org/html/rfc1035#section-4.2.1. If the packets are too big, they will be fragmented (which may tip off a admin/analyst viewing the traffic). 
To the second point, UDP does not guarantee delivery of packet to the recipient like TCP. It is a fire and forget protocol. This means the acknowledging and retransmission of the data which may have been dropped needs to be handled by the application (in this case the tunneling tool). 

Demo and tool test

I wanted to test a tool I recently found which does exactly this (along with the use of other protocols). The tool is called XFLTReaT https://github.com/earthquake/XFLTReaT. 

What it does is 


I recorded a video on setting up the tool, running it and tunneling HTTP traffic between two linux machines. Link to the video is below. Enjoy your tunneling! 



Quick guide to dumping memory and creating a volatility profile

This will just be a quick guide on how to dump memory from a Linux server and create a volatility profile for it. 


Manual method

Creating the kernel module with LiME

Ideally you want to log onto a copy of the victim machine. You want to make sure it is the same distro and kernel version as the victim. This is because then you don't have to stop over potentially deleted files on the disk. 
  1. sudo apt-get install build-essential
  2. git clone https://github.com/504ensicsLabs/LiME
  3. cd LiME/src/
  4. make
  5. scp the .ko file off this machine 
  6. Copy the .ko file to the actual victim machine
  7. Execute insmod lime_module.ko "path=/tmp/images/ram.lime format=lime"

Creating Volatility profile

Same comment as above, you want to run these commands on a server which is an identical copy of the victim. 

  1. sudo apt install zip unzip dwarfdump build-essential
  2. wget http://downloads.volatilityfoundation.org/releases/2.6/volatility-2.6.zip
  3. unzip volatility-2.6.zip
  4. cd volatility-master/tools/linux/
  5. make
  6. sudo zip linux_`uname -r`.zip module.dwarf /boot/System*`uname -r`
  7. scp the zipped file off 
  8. Copy the file to volatility-master/volatility/plugins/overlays/linux/ on your analysis machine

Remote capture with Margarita shotgun:

I recently compared two tools for remote capture, LiMEaide (https://github.com/kd8bny/LiMEaide) and Margarita shotgun (https://github.com/ThreatResponse/margaritashotgun). I would recommend you use Margarita shotgun and not LiMEaide, as LiMeaide stomps all over the disk drive which could overwrite data in unallocated sectors which have been recently cleared up after file deletion. 

How to use Margarita Shotgun on analyst machine:
  1. Install with pip install margaritashotgun
  2. Run margaritashotgun --server [server IP] --username [username] --key [key.pem] --module [lime-module].ko --filename memory_dump.lime
The victim machine simply needs insmod available.