Unsurprisingly covert channels defined in 1973 are system based. However they are still relevant in any shared environment.
• Storage Channels : the most basic indeed, based on the used of a shared data storage area. Most evolved techniques rely on locks or semaphores which positioning may be a piece of information such as a 1 when no lock means 0.
• Timing Channels : the time needed by a process to perform an operation can be voluntarily manipulated to provide information to another process.
• Termination Channels : a process launches a task. It this task is finished at a specified time it means 1, 0 otherwise.
• Resource Exhaustion Channels : the value (0 or 1) is provided by the availability of a specific resource which may be filled up (hard disk), overloaded (100% cpu) etc.
• Power Channels : in this case the information is based on power consumption.
http://www.iv2-technologies.com/CovertChannels.pdf
----
//gray-world.net/projects/papers/html/covert_paper.html
1. THE HTTP THEORY APPROACH
1.1. THE HTTP PROTOCOL IN OUR CYBER-WORLD
1.2. BASICALLY, THE HTTP PROTOCOL IS
1.3. THE HTTP CLIENT/SERVER PROTOCOL ABSTRACTION
1.4. WHY DID WE CHOOSE AN HTTP THEORY APPROACH ?
2. CLIENT/SERVER IMPLEMENTATION
2.1. SERVER MODELS
2.1.1. Httpd-like server model
2.1.2. Proxy-like server model
2.1.3. CGI-like server model
2.2. ON THE WIRE MODELS
2.2.1. Server proxy chain model
2.2.2. Intermediary distributed servers model
2.2.3. Almost-real proxy server model
2.2.4. Legitimate third-party model
2.3. MODES
2.3.1. Single application client mode
2.3.2. Single application client proxy mode
2.3.3. Server proxy mode
2.3.4. Client reverse connection proxy mode
2.3.5. Proprietary user defined protocol mode
2.4. APPLYING MODELS AND MODES IN THE REAL WORLD
2.4.1. Http proxies
2.4.2. Reverse proxies
2.4.3. Other applications are using HTTP intermediaries
3. USING HTTP METHODS
3.1. DATA CONTAINERS RESTRICTIONS
3.1.1. URI string
3.1.2. Header string
3.1.3. Message body
3.2. METHODS WITHOUT MESSAGE BODY : GET, HEAD, DELETE
3.2.1. The GET method
3.2.2. The HEAD method
3.2.3. The DELETE method
3.3. METHODS WITH MESSAGE BODY : OPTIONS, POST, PUT, TRACE
3.3.1. The OPTIONS method
3.3.2. The POST method
3.3.3. The PUT method
3.3.4. The TRACE method
3.4. THE HTTP PROXY CONNECT METHOD
3.5. CONCLUSION
4. SECURITY ASPECTS
4.1. AUTHENTICATION
4.2. AUTHORIZATION
4.3. DATA STREAM CIPHERING
4.4. DATA STREAM INTEGRITY
4.5. REPLAY PROTECTION
5. COVERING AND STEGANOGRAPHIC METHODS
5.1. CONFUSION ON THE HTTP STREAM
5.1.1. Hiding data in the HTTP header
5.1.2. Hiding data in the HTTP body
5.2. CONFUSION ON THE DATA STREAM
5.3. CONFUSION ON THE SERVER SIDE
=============
Various design aspects can be taken into consideration when implementing an HTTP Client/Server covert channel tool : What kind of server model can be implemented (Httpd-like, Proxy-like, CGI-Like) - How can the tool be designed to add confusion from a traffic watcher point of view (Server proxy chain, Intermediaries distributed servers, Almost-real proxy server and legitimate third-party models) - What kind of functionality can be implemented into the covert channel (Single application client and Single application client proxy modes, Server proxy mode, Client reverse connection proxy mode and Proprietary user defined protocol mode).
Then, when the HTTP covert channel client/server tool is modelized, designers can think about how their design could be applied in a real world environment : What kind of HTTP method can be used (With or Without Message body, be using the CONNECT method or not ?) - What kind of HTTP legitimate servers can be used to transit the arbitrary data stream through the NACS (HTTP and reverse proxies, other applications).
http://gray-world.net/projects/papers/cctde.txt
==========
Covert channel methods establishing unauthorized tunnels are often used to transit real world application data streams. A Covert Channel (CC) client opens a legitimate connection through a NACS and uses this connection to send and receive arbitrary data from a CC server.
Questions are now : "What characterizes such kind of covert channel
tunnels ?" and "What kind of tunnel traces can we get from the network streams ?".
We will now present some kind of tunnel traces. Some of them may be redundant to the reader point of view but we are trying here to have a (non-exhaustive) list of tunnel traces.
Unauthorized tunnel traces :
(1) : High amount of inbound/outbound data transiting through the NACS -
Inside POST or PUT requests for example - These high data amounts
may occur one time only or be generated during a specific period
delay.
(2) : Small but frequent amount of inbound/outbound data transiting
through the NACS - A CC telnet-like communication channel will, for
example, generate a very small but frequent amount of data.
(3) : Requests/responses are sent too frequently or are sent on a curious
static interval.
(4) : One "user" requests a small quantity of external resources too
frequently.
(5) : The data stream transiting through the NACS contains some specific
patterns such as SSH banners for examples.
(6) : The data stream transiting through the NACS generates HTTP protocol
anomalies or violations.
The first four tunnel traces could be detected by a behavioral-based detection engine. The fifth one could be detected by a signature-based one while the last tunnel trace could be detected by a protocol-based one
Covert storage channels include all vehicles that would allow the direct or
indirect writing of a storage location by one process and the direct or indirect reading of it by another. Covert timing channels include all vehicles that would allow one process to signal information to another process by modulating its own use of system resources in such a way that the change in response time observed by the second process would provide information.”
http://gray-world.net/papers/adiscussionofcc.pdf
=======
http://en.wikipedia.org/wiki/Covert_channel
http://www.cl.cam.ac.uk/~sjm217/papers/ ... erttcp.pdf
http://david.inchcolm.org/Portals/6/050 ... Slides.pdf
A GUIDE TO UNDERSTANDING COVERT CHANNEL ANALYSIS OF TRUSTED SYSTEMS
http://www.fas.org/irp/nsa/rainbow/tg030.htm
http://www-scf.usc.edu/~csci530l/downloads/covert_tcp.c
/* Covert_TCP 1.0 - Covert channel file transfer for Linux
* Written by Craig H. Rowland (crowland@psionic.com)
* Copyright 1996 Craig H. Rowland (11-15-96)
* NOT FOR COMMERCIAL USE WITHOUT PERMISSION.
*
*
* This program manipulates the TCP/IP header to transfer a file one byte
* at a time to a destination host. This progam can act as a server and a client
* and can be used to conceal transmission of data inside the IP header.
* This is useful for bypassing firewalls from the inside, and for
* exporting data with innocuous looking packets that contain no data for
* sniffers to analyze. In other words, spy stuff...
*
* PLEASE see the enclosed paper for more information!!
*
* This software should be used at your own risk.
*
* compile: cc -o covert_tcp covert_tcp.c
------------
http://www.cycom.se/dl/rrs
rrs is a reverse (connecting) remote shell. Instead of listening for incoming connections it will connect out to a listener (rrs in listen mode). The listener will accept the connection and receive a shell from the remote host. rrs features full pseudo-tty support, full OpenSSL support (high encryption, client/server authentication, choice of cipher suites), Twofish encryption, a simple XOR cipher, plain-text (unencrypted) session, peer-side session monitoring (snooping), daemon option and reconnection features. rrs is Free Software distributed under the MIT License and is known to compile and run under Linux, FreeBSD, NetBSD, OpenBSD and QNX.
-----
http://www.plenz.com/reverseshell
In this little guide I'll quickly cover three very helpful methods to get a reverse shell on a host, using ssh, netcat or Perl.
-----
http://sourceforge.net/projects/matahari/
A reverse HTTP shell to execute commands on remote machines behind firewalls. Once you run the script on the target machine, it periodically polls its designated server for commands to execute. Traffic traverses firewall as outgoing GET/POST requests.
-----
http://www.iv2-technologies.com/CovertChannels.pdf
the reason why ICMP was one of the first protocols that was used for
covert channels, often considered (and is still sometimes) as innocuous and offering a great "legitimate" possible load thanks to the data field. This field provides from 84 bytes (ICMP Redirect/Destination unreachable) to (MTU-28) bytes (ICMP echo request/replies), which is a very good capacity.
A trivial implementation is provided by the icmpchat tool [icmpchat]. This is an ICMP stealth equivalent of talk using any ICMP type and code and providing encryption.
At the application layer, covert channels will make possible to use legitimate traffic both from the security policy and communication standards point of view. Also such traffic should not look too suspicious as important HTTP traffic always look more natural than
ICMP.
Due to outgoing restrictions, most application traffics used to create channels are the web, mail and DNS ones. When they are linked to really mechanisms such as proxy chains or anonymous remailers, these channels ensure integrity (in the TCP meaning) of the communication, very good capacity and an indubitable resistance to source traceback.
What is more, and because application protocols are full of functionalities,
possibilities to create channels are almost unlimited.
-----
http://caia.swin.edu.au/cv/szander/cc/c ... s-bib.html
[1] D. Stødle. ptunnel - Ping Tunnel, 2005. http://www.cs.uit.no/daniels/PingTunnel.
[ http ]
[2] P. LeBoutillier. HTTunnel, 2005. http://sourceforge.net/projects/httunnel/.
[ http ]
[3] T. M. Gil. IP-over-ICMP using ICMPTX, 2005. http://thomer.com/icmptx/.
[ http ]
[4] T. M. Gil. IP-over-DNS using NSTX, 2005. http://thomer.com/howtos/nstx/.
[ http ]
[5] Sergey Chvalyuk. Icmp Tunnel - ITun, 2005. http://sourceforge.net/projects/itun.
[ http ]
[6] I. Zelenchuk. Skeeve - ICMP bounce tunnel, 2004. http://www.gray-world.net/poc_skeeve.shtml.
[ http ]
[7] T. Pietraszek. IP-over-DNS tunneling using DNScat, 2004. http://tadek.pietraszek.org/projects/DNScat/.
[ http ]
[8] D. Kaminsky. IP-over-DNS using Ozyman, 2004. http://www.doxpara.com/.
[ http ]
[9] J. Rutkowska. NUSHU Passive Covert Channels in the Linux Kernel, 2004. http://www.invisiblethings.org/tools.html.
[ .html ]
[10] T. MacDermid. StegTunnel - Covert Channel in IPID, 2003. http://www.synacklabs.net/projects/stegtunnel.
[ http ]
[11] M. Langston. Sifr's Obfuscator (PoC-code), 2003. http://www.bitshift.org/archives/new-sob.c.
[ http ]
[12] S. Castro. Covert Channel Tunneling Tool (cctt), 2003. http://gray-world.net/pr_cctt.shtml.
[ http ]
[13] A. Dyatlov. Firepass - Is a Tunneling Tool, 2003. http://gray-world.net/pr_firepass.shtml.
[ http ]
[14] P. Padgett. Corkscrew, 2001. http://www.agroman.net/corkscrew/.
[ http ]
[15] A. Vidstrom. AckCmd Backdoor, 2000. http://ntsecurity.nu/toolbox/ackcmd/.
[ http ]
[16] M. Lundström. MailTunnel. http://gray-world.net/tools/mailtunnel-0.2.tar.gz.
[ http ]
[17] A. Heydecke. Sockster/trapster - covert channel and tunnel development. http://tunnel.gotdns.org.
[ http ]
[18] W. Zheng. MsnShell - Encapsulate Shell Commands Within MSN. http://gray-world.net/pr_msnshell.shtml.
DNR