Wednesday, December 24, 2008

Guide to Encrypted Dynamic Covert Channels

Creating and Using New Covert Channels
--Skip to end list for just a walkthrough on what to do--

+++State of Things+++

Covert channels in TCP/IP communications are dying from the public and security field's eye. When I talk about covert channels, several security professionals/researchers ask me what it is or say something along the lines of, "Like Stegonagraphy?". Publicly available, mass used, and not fully understood by implementer(s) intrusion detection systems (and their rulesets) and stateful firewalls could be why little is known anymore about this subject. With great tools that setup an encrypted tunnel (cryptcat, VPN software, etc.) publicly available and rather simple to use, the publics eye will be on these for a while. Which means that I can have my fun with my new covert channel without much risk!

+++Covert Channels of the Past+++

First off, let's talk about the past. Covert channels have been rather restrictive in their implementation (as far as the documentation on the channels and their uses goes). This because the communication was happening somewhere inside of a packet or multiple packets. This brought much more attention to checking for legitimate network communications. Active warden systems and/or network stabilizers was the software being researched and released to prevent these covert channels from happening. Basically, the new software looked at the packets and tried to find irregularities (heuristic and blacklist) in the network traffic (think stateful firewalls). Then it would take action depending on the software and/or configuration settings.


This post should explain how to create your own special encrypted covert channel with a tshark filter, hping, and your brain (knowledge of TCP/IP communication would be greatly beneficial).

+++Down to the Good Stuff+++

So, my first step was to find a way to create a covert channel that's encrypted. This idea came to me after reading an article on port knocking. Port knocking is where you have a port that you want to connect to, but it's closed. This port opens when a certain amount of ports (UDP/TCP Open/Closed) are "knocked on" (connected, single packet sent to, whatever you want to count for a "knock" in your implementation). So, say I want access to port 22, SSH, but it's closed. I would run my program to connect to this port. What this program would do is send a SYN packet to TCP 7342, UDP 2738, UDP 3829, and TCP 80 thus opening port 22 for my ip for a certain length of time.

Now, what would happen if we did a simple algorithm to turn the port numbers into words? Say we hit TCP 2837 and TCP 2837="A". We have 65535*2 (TCP and UDP) possibilites open to us for a simple charset of our choosing. Or, say you want to use both source and destination port numbers, than we would have 131070*2. Example simple encryption algorithm:
Take the length of the word, multiply it by the amount of words in our sentance, then multiply each character by it's ASCII equivalent. If the number goes above 65535, turn negative and start at -1. Each negative number are UDP ports, each positive are TCP.
->This creates a unique encryption, unless you steal my too simplistic idea or use someone else's encryption, that anyone can setup and modify easily.

Alright, so we have TCP 503, TCP 17532, TCP 1934, TCP 10374, UDP 59 and it spells out "hello". Now, we want to send it to another person on the network (original idea for why this method was thought of by me). We don't want to give away our originating ip addresses, so we will be using hping3. Hping3 takes advantage of the insecurities dealing with the TCP/IP stack. With it we have the ability to create and send packets on the network (with a spoofed source address if wanted).
Network Architecture: - Shitty Router - Client using internet - Me - Person I want to talk to - Client using internet - VoIP server - Client using internet - Web server - Client using internet - Client using internet - Client using internet - Client using internet

First attempt:
hping command: hping3 -I wlan1 -V -S -a -p 503 -c 1 --sign "secretkey"
->interface wlan1, be verbose, Syn packet, destination:, source:, TCP 503 = "h", stop after 1 packet, sign packet with text "secretkey"
tshark command: tshark -i wlan1 -n -R "tcp contains secretkey"
->interface wlan1, don't run DNS on port number, addresses, etc., only show tcp packets that contain the text "secretkey"

Pretty simple, huh? It should be easy to modify as long as you RTFM. This is a failed attempt, and I'll tell you why. First, our packet is pretty broken and might not look like legitimate traffic in the eyes of the network's security. Also we placed text into the packet and that might trigger an alarm or create a fingerprint to easily track the rest of the packets. Not that it matters because the talk is encrypted with whatever algorithm you created, but we want as much stealth as possible without tripping any alarms.

Second attempt:
hping command: hping3 -I wlan1 -V -S -a -p 503 -c 1 -t 60 --tcp-timestamp
->This time we used a ttl (time to live) and set it to 60, instead of the default 64 that hping puts out. I also included a tcp timestamp to make the packet look more like a normal packet.
tshark command: tshark -i wlan1 -n -R "ip.ttl == 60"

Great, so now we created a system where only the information we want to recieve will show up on our sniffer and it's easy to modify. Learn TCP/IP and filters to make yours more unique. There are, unfortunately, two more problems we need to address. The first being that our cards are going into promiscuous mode and the second being how fast the packets are being sent out.
You should be able to figure out a way around the network card problem, there are limitless possibilities. Although, unless you're on a secure network where you think/know they have something checking for network cards in this mode, don't worry about this too much. One way around it would be to send packets to and from each other instead of spoofing the source and destination addresses. Then, we can set tshark to not run in promiscuous mode. If you start sending trash requests to different webpages at the same time, it would be like finding a needle in a haystack when looking through logs. Let alone them somehow knowing of your private channel.
As for the amount of packets being sent out in a short time, we can fix that easily. Sending a lot of packets rather quickly is a problem that has great potential to trigger all sorts of alerts. Time out your packet sending, maybe send a packet at random intervals between 3-20 seconds? Remember, patience is a virtue.

It would probably be in your best interest to create some kind of program for automation of this method. A simple "./covert this would be the text you want to send", so you could pipe something else in there if you wanted (for those of you who can reconstruct a file after it's been fragmented like that). Then it encrypts the message for you and modifies your hping3 commands accordingly. Don't forget about packet sending times!
On the reciever's end, strip out the port numbers from your tshark dump and pipe it into your decryption program.

+++The Simple Covert Channel Walkthrough+++
--Just making a simple list for those who don't want to read the article. If you've read the article, you probably won't want to read this as it's just a repeat.--
1.) Port numbers represent characters. Each port number will be a character. We can use any open/closed, TCP/UDP, source/destination, ports. This gives us 131070*2 possibilities for our pre-defined charset.
2.) Create an encryption algorithm for the port to character conversion. Make one up yourself so it's completely unique. Don't be simplistic, we are using this for sending information we probably don't want anyone to find out about.
3.) Run hping to create and send packets. Use hping's ability to spoof source and destination addresses.
4.) Make the packets different than most network traffic, but not so much as to send up alerts. A simple change like ttl time would be recommended.
5.) Run tshark and apply a filter to find your modified packets.
6.) Take the port numbers and decrypt them for your message/file/etc.
7.) Automate the process for large files
8.) Now read the article for a more thorough analysis of this method, downfalls/possible problems, and how to free yourself from those possible problems.

-Tyler Borland-


Anonymous said...

Seems like an interesting idea, I will have to look into this further.

Anonymous said...

This looks very interesting. Thank you for sharing your idea.

Alexander Sverdlov said...

This is not encryption, this is encoding and in itself is a good but not practical idea.

Steffen Wendzel said...

It isn't new: It is a special version of what I call a protocol channel. I finished my research on it (and there is much more to know about it, then you mention in your post). I will upload my diploma thesis about this topic after I received my diploma in a few months (the information on my website and my paper on the topic are outdated and incomplete!). But at the moment I can give out no information and also can not talk about details.

More information:

Anonymous said...

It is a public key encryption

TurboBorland said...

Alexander, the point is to create your own encryption/encoding program with me trying to point you towards a more public key encryption system. Not just using my terrible example algorithm. :p

Steffen, I replied to your article. However your outdated one does not seem very similiar to mine besides that we both used ports. However, there have been other cases of using ports in covert channels, just not ONLY ports. I would love to read or talk to you about your updated idea, though.

Steffen Wendzel said...

TurboBorland: Your port example is an implementation of what I call a protocol channel since the "port" is an abstract protocol information. I already mention this in my thesis. You can also use protocol IDs within ethernet frames and the like. It is just another layer. The encoding (bits, chars and the like is also possible on different ways and my PoC code does what you do). I also ONLY use these "protocol" information. The difference between your thing an mine is the abstraction (but I didn't publish THAT information before).

Please contact me via email (steffen (at) ploetner-it (dot) de). I need to mention your paper in my thesis as a way to implement these channels since I cannot show that I've had this idea before. Poorly for me that you published this before I was able to do so... The protocol channel part of my thesis (what makes about 30%) was already 100% finished and now I have to rewrite it.

Hope to hearing from you.

Dante said...

Pretty interesting article. The problem I see with that protocol is that you rely on an unshielded network. I mean, if you have internal firewalls between your endpoints they would limit open ports you can use, reducing drastically your alphabet size. You may use a binary port encoding, a combination of tries in eight ports may give you the ASCII alphabet... problem is that sometimes you don't have even those eight ports open and you need to be aware of time related issues with this approach.

Maybe you'd like to read one of my blog articles written some time ago (25 Oct) about network steganography .

There I explain (and implement with python code) some ways to create covert channels in usual network traffic. I detail data hidding in ping data fields, in ID IP header field, in ISN TCP header and with ASN header in TCP. The later is pretty interesting because I implement an indirect covert channel connecting two endpoints through a middleserver which can be useful to circumvent firewall filtering rules and IDS detection. Besides, I think my python code can be useful to you as an starting point to automate your protocol. Please, tell me if you do it to announce it in my blog :)

TurboBorland said...

Well, it doesn't matter if it's an open port or not. The firewall will drop the packet if it doesn't want it, but that doesn't mean that the packet somehow didn't get sent.

The other ways you mention have a big problem seeing as they are important parts of the packet and have been talked about before. These will probably show most stateful or network analyzing security software, especially any active warden or network stabilizer, that illigitimate traffic is going on in the network. This is due to the way the parts of the packet you modify function as to how you are going to make them function.