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!
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.
sudo zip linux_`uname -r`.zip module.dwarf /boot/System*`uname -r`
scp the zipped file off
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.
This is again a continuation of the write ups for the CTF competition held within the company I work for. This was in the MISC category and worth 300 points.
Questions/Challenge:
There was one file attach to this challenge.
Step 1. Download the file.
User the Google drive link within the challenge to download the file:
Let's if there is anything odd with this file. We will start with the file command to see if it is indeed a png.
file qream.png
We see that it does indeed have a .png magic number at the start of the file.
Now let us see if there are any other magic numbers for any other files hidden in it
binwalk qream.png
We see that a Zlib compressed data was found but according to the PNG specification sheet, this is normal because this is how PNGs store image data: https://www.w3.org/TR/PNG-Compression.html
Well with no leads now, let us just open the image and see what we see.
The image is a QR code.
Scanning it with my phone reveals that it a URL to an imgur.com link:
And opening this link(https://i.imgur.com/NPwU4xM.png) takes us to another QR code. As the challenge states, this seems like it will be quite a rabbit hole to dig into with the flag at the end of it.
Step 4. Automate the solution.
Since we do not know how deep this rabbit hole goes, this is a perfect opportunity to automate this task! Off to python we go!
Below is the code I wrote to first fetch decode a QR code png, then fetch the data as if it were expecting a URL out of it.
The script uses the qrtools library to decode png images and extracts the data value.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Yes, the script is not perfect and I could have spent more time catching the exception, but when you are trying to solve the problem as fast as possible the means do not matter as long as you reach the goal. You can see in the exception that it could not reach the url, well because it isn't a URL, it is the flag.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a continuation to the write ups for the CTF competition held within the company I work for. I am bringing you all another forensics challenge I was able to solve. This one was valued at 400 points. Question/Challenge:
Step 1. Download the file. The link takes you to a google drive hosted file. The file's details are:
Lime of course is a linux memory dumping tool. The content of the .7z is a linux memory dump, as stated by the challenge. Step 3. Acquire Volatility profile. The description of the challenge states that this image was taken from a 16.04 Ubuntu server. Since I will use Volatility as my memory analysis tool, I will need the proper profile for this OS version. After some Googling I landed on this page which has a collection of Ubuntu profiles: https://github.com/volatilityfoundation/profiles/tree/master/Linux/Ubuntu/x64 We will need Ubuntu1604.zip. Save the zip file to the following location:
volatility/plugins/overlays/linux/
Instructions here: https://github.com/volatilityfoundation/volatility/wiki/Linux Verify that the memory profile has been loaded:
python vol.py --info
Profiles
--------
LinuxUbuntu1604x64 - A Profile for Linux Ubuntu1604 x64
You should see something like this if it was loaded properly. Step 4. Investigate the memory image. I used pslist, pstree and psxview to get an idea of what is running:
Yesterday, Friday the 13th of May 2016 I had the privilege to take part in a company wide CTF competition. This was my second time attending one from start to finish (the first being SANS Netwars 2015). My department within my company formed a single team to combine our technologically cyber intelligent minds(just trolling :p). But we did indeed band up to take on these challenges.
There were a few different categories a few including: Trivia, Web, Crypto, Reversing, Forensics, and MISC. Working in IR it took on the challenge of solving the Forensics challenges. Below is the highest point (500) question within the Forensics category. I will then show how I solved this problem.
Question/Challenge:
Step 1. Download the file.
The link directs you to a google drive hosted file.
That file is 1,926,442KB in size. The file name is: FBiOS.7z-113c529c20a080bc36b050e9faf33485b123607005e862d67fbf2ac7a517f3d2
Step 2. Extract the file using your favorite uncompressor.
As the challenge states, the .hdd file is the disk image and the .mem file is the memory image.
Step 3. Explore the HD image.
Before we go digging in the memory file I wanted to get an idea of what we're dealing with by taking a look at the drive image. Why? Because there are a plethora of HD image analysis tools out there, compared with memory analysis tools, that provide a gui based interface and therefor a better visualization of the drive structure.
Since I work out of Windows on my main system, I chose to use Autopsy to analyze the HD image.
I see a .gz file. I extracted and could not find anything of interest there considering it seemed to contain nothing of value.
Also, in that same directory there is a LUKs file. LUKs is a full disk/file container encryption tool on Linux based operating systems. This is the file of interest we need.
Step 4. Extract the LUKs file.
As stated by the challenge, the "HiPhone" was encrypted. We need to figure out how to open this encrypted file to get to our flag. In Autopsy, it is as easy as right clicking and then Extracting files.
So now that we have our encrypted file container, we now need the key. Luckily we have the memory dump. When memory is dumped and an encrypted file container is mounted at the time of the dump, It will contain the raw encryption key.
I will be up front, I do not know where in memory encryption keys are located. I could attempt to explore this image via volatility or some other memory analysis tool but I do not have the skill to do that fast.
I chose to use a tool called bulk_extractor (http://digitalcorpora.org/downloads/bulk_extractor/). The reason being that one of the artifacts that bulk_extractor is able to pull is AES keys from a file.
Run bulk_extractor on the file:
.\bulk_extractor64.exe -o .\FBiOS\ .\FBiOS.mem
Now check your output directory for a file called "aes_keys.txt"
Notice how we have a problem where the keys identified by bulk_extractor are 32 bytes and not 64 as expected by cryptsetup. So lets go back to our aes keys found by bulk extractor.
If we open the mem file in a hex editor and locate our first AES key, we see that it is not 32 bytes but actually 64. So the first two 32 byte keys identified by bulk_extractor are actually one key:
rak@rakkali:~/Desktop$ sudo mount /dev/mapper/iphone /mnt/iphone/
mount: unknown filesystem type 'LVM2_member'
Ugh oh. A new error which is blocking us. Using the guide here: http://pissedoffadmins.com/os/mount-unknown-filesystem-type-lvm2_member.html I learned how to make the devs ACTIVE:
rak@rakkali:~/Desktop$ sudo lvscan
inactive '/dev/FBiOS/root' [1.63 GiB] inherit
inactive '/dev/FBiOS/swap_1' [128.00 MiB] inherit
ACTIVE '/dev/rakkali-vg/root' [18.90 GiB] inherit
ACTIVE '/dev/rakkali-vg/swap_1' [872.00 MiB] inherit
rak@rakkali:~/Desktop$ modprobe dm-mod
rak@rakkali:~/Desktop$ sudo vgchange -ay
2 logical volume(s) in volume group "FBiOS" now active
2 logical volume(s) in volume group "rakkali-vg" now active
Now lets finally attempt mounting one more time:
rak@rakkali:~/Desktop$ sudo mount /dev/FBiOS/root /mnt/iphone/
Were in:
rak@rakkali:~/Desktop$ ls /mnt/iphone/
bin/ home/ lost+found/ proc/ selinux/ usr/
boot/ initrd.img media/ root/ srv/ var/
dev/ lib/ mnt/ run/ sys/ vmlinuz
etc/ lib64/ opt/ sbin/ tmp/
Let's find this flag quick with a good old find command: root@rakkali:/# find . -type f -iname flag*
We now have our flag. root@rakkali:/mnt/iphone/root# cat flag.txt flag{Please_Upgrade_to_FBiOS_10!}
