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. 

CTF challenge - Qream writeup

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:

The file details are:

 Name: qream.7z-6e530127545031e65f8d66a408fe72fc98c7297f3b161fe3c6397e513e06eada  
 Size: 819 bytes  
 SHA256: 6e530127545031e65f8d66a408fe72fc98c7297f3b161fe3c6397e513e06eada  

Step 2. Extract contents.
Inside the .7z file we have one folder:

And inside that folder, one file:

Step 3. Assess the png file:

 Name: qream.png  
 Size: 638 bytes  
 SHA256: fd170f31c761404634420c0a903d097723ec13d8110c0f7ada0fea48031d6d4b  

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.

The results of the script are below:

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.

flag{QR_Rules_Everything_Around_Me_QREAM}

Forensics CTF challenge - RAMDisk writeup

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: 

 Name: flagflag_crew.7z-89b4071371d484987c8a0431636128b46e8ee99a9185d50fa74f34df9ff40ae7   
 Size: 55.5 MB (58,230,361 bytes)
 SHA256: 89b4071371d484987c8a0431636128b46e8ee99a9185d50fa74f34df9ff40ae7  

Step 2. Extract contents.
Inside the .7z file is one file:

 Name: lime.dump   
 Size: 0.99 GB (1,073,207,392 bytes)
 SHA256: 2ee1ad807663d951bd8f3f3dff88d2321ae343e3e6c26c5f8cf90d261e30cef2  

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:

 python vol.py --profile=LinuxUbuntu1604x64 -f ../lime.dump linux_pslist  
 python vol.py --profile=LinuxUbuntu1604x64 -f ../lime.dump linux_pstree  
 python vol.py --profile=LinuxUbuntu1604x64 -f ../lime.dump linux_psxview  

I will then take a look at the bash history since I saw that NC was running on the system:

 python vol.py --profile=LinuxUbuntu1604x64 -f ../lime.dump linux_bash  

Interesting.. Netcat is writing to flagflag.7z on the Ramdisk.

Let's see what is mounted on the system:

 python vol.py --profile=LinuxUbuntu1604x64 -f ../lime.dump linux_mount   

We see that the location of the ramdisk is at /home/user/ramfs

Step 5. Investigate the "flagflag.7z" file.

Let's see if this file is open currently:

 python vol.py --profile=LinuxUbuntu1604x64 -f ../lime.dump linux_lsof  

We now have the location of the flagflag file.

We have two options here:

Option 1: Is there a way to dump the entire ramfs from memory to disk?

No time to research and do that!

Option 2: Just carve the entire memory image for .7z files.

This one is much quicker to do and no research involved.

Step 6. Carve the file

We will use a tool called scalpel to carve for magic numbers of files. In our case we want the .7z files.

To specify byte signature, we need to edit the config file:

 nano scalpel.conf   

Edit it so that it contains the following entry to only find .7z files:

    7z  y   2147483648   \x37\x7a\xbc\xaf\x27\x1c  

Make a directory for the output:

 mkdir scalpel_output  

Run scalpel on the memory dump:

 scalpel -b -c ./scalpel.conf -o scalpel_output/ ../lime.dump   

Extract one of the .7z files

 cd scalpel_output/  
 cd 7z-0-0/  
 ls -alh  
 7za e 00000000.7z   

cat out the contents of the flag:

 ls  
 cat flagflag.txt   
 flag{Memory_Forensics_is_hard_Let's_go_shopping}  

We now have our flag.

Pictures for the above commands below:

Forensics CTF challenge - FBiOS writeup

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. 

I chose to use WinRAR.

Inside this 7z file are two additional files:

FBiOS.hdd (2,097,152 KB - 13ba50ee448148c2f17043a660ec5d4a1c4005d3c15fffaca8c143bd0aeb75fb) 

FBiOS.mem (444,205 KB - 276bd3b863e3f0f9f655dd5ffaa81c0f4bc9cade02680b9a430984fec2ac4c73). 

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. 

File details: 

f0000000.luks (1,845,248 KB - afc38778d8ff53e257a3eb145288549eeee9435be589b93073af67bf75e78eae)

Step 5. Locating the encryption key

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"

You should see something like: 

# BANNER FILE NOT PROVIDED (-b option)

# BULK_EXTRACTOR-Version: 1.5.2 ($Rev: 10844 $)

# Feature-Recorder: aes_keys

# Filename: .\FBiOS.mem

# Feature-File-Version: 1.1

209284240 2c c4 4f 83 34 67 8d d3 bf 90 a2 62 73 48 f0 7b 06 ff e6 ed 31 81 4a 19 2d 09 52 ed 3b c8 2f a6 AES256

210258064 08 fe 3b 64 62 08 a2 e2 55 e0 fd d1 ae a8 8a 7e 2a ae 80 3d 16 e9 0e bc 97 7b 14 60 2d 09 84 de AES256

433757396 03 50 5d bf 82 cd 0f 48 2b 45 08 1b b8 45 8d 4c 7d 2e 16 c0 32 d5 9a fc 56 ec d4 8c 05 60 94 92 AES256

Safe these hex values to a new binary file in HxD. We now have the keys to decrypt the LUKs file. 

Step 6. Open the LUKs file.

Attach the LUKS file to a loopback device: 

rak@rakkali:~/Desktop$ sudo losetup /dev/loop/1 f0000000.luks 

Open the luks file with cryptsetup luksOpen:

rak@rakkali:~/Desktop$ sudo cryptsetup luksOpen --master-key-file key1.key /dev/loop1 iphone

Cannot read 64 bytes from keyfile key1.key.

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:

Combine the two keys:

rak@rakkali:~/Desktop$ cat key1.key key2.key > 1_2.key

Lets try the luksOpen again:

rak@rakkali:~/Desktop$ sudo cryptsetup luksOpen --master-key-file 1_2.key /dev/loop1 iphone

Success. 

Now we must mount the encrypted file container:

rak@rakkali:~/Desktop$ sudo mkdir /mnt/iphone

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!}

Hello, world!

Hello, world!