|
|
||||||
|
||||||
| Index Link To US Private Messages Archive FAQ RSS | ||||||
| Internet Security Discussion Forum This forum is for the discussion of security related issues. If you find a new Phishing scheme, spyware, virus or malicious site - let us know about it. If any of the above found you... here's where you ask for help. |
Share Thread: & Tags
|
||||
|
![]() |
|
|
LinkBack | Thread Tools | Display Modes |
|
|||
|
Hello security folks
I'm new to this forum and I hope to be a permanent member I'm working on a project where a detection system should be build to detect covert channels as many as the system can. I googled a lot about this topic and I found many research papers and some of them have very promising results. One of the solutions was to use SVM to detect IPID and ISN covert channels. Another solution was Snort. Also, there are many many other solutions such as statistical detection entropy detection and ,,, etc.. most are theoritical Here are my questions that I hope someone share with me the opinions: To build one system, is it better to use one detection technique like the SVM for most the covert channels or implement more than one approach in one system. If so, is it feasible? This is my first Covert Channel project and I'm not expert so :S I would appreciate a good response and some discussion |
|
||||
|
Covert channels go beyond simply checking the routing of a packet - with a covert channel, the packet is going where it should, but it contains information it shouldn't. Let me give a real world example:
A text file that is encoded in UTF-8 contains 8-bit characters. The letter A would be represented as follows: |01000001| A text file that is encoded in UTF-16 stores characters in two 8-bit bytes. The letter A is represented as: |01000001|00000000| In a text file containing ASCII characters, the second byte reserved for each character is simply left blank. Lets say a terrorist organization needs to distribute data to various cells. They create a UTF-16 document using ASCII characters, but encode a secret message in the second or lower byte of each character. They then upload the text file to a website and make it downloadable. Now, anyone can download the file, but only the users who know there is a hidden message and have a certain degree of expertise would be able to read it. Doing a forensic analysis following an attack or the capture of a cell, you have no way to know who was just downloading the file for the public information, and who was a terrorist downloading the file for the hiddden data. Note, in this example, the file size stays the same - the hidden data is virtually undetectable. This is what makes it a covert channel - you are hiding data within another connection. I also overly simplified a few aspects - following the steps I mention should actually result in a garbled file.
__________________
The best way to learn anything, is to question everything. Last edited by wige; 10-12-2009 at 10:52 AM. |
|
||||
|
Right - and the concerns you mentioned describe user-level steganography.
Most of the papers I found which concerned covert channel communications focused on the introduction of compromised hardware or a compromised operating system which was effectively attempting to "phone home" with information gleaned from a secured network. Figuring out where the information is heading and preventing it from reaching its destination is a primary concern if you are dealing with compromised hardware or software (but not with compromised people). The exfiltration of data assumed to be secure appears to be a primary concern of covert channel analysis on a secured network; if you have terrorists hiding messages with steganography on your secured network, you have much bigger problems than a compromised machine or OS - thence the question of what type covert channels Mouza seeks to expose.
__________________
Dan LeFree | Product Manager (Linux VPS Hosting) | Owner/Operator (Web development, marketing) |
|
||||
|
Hm... that reminds me of an old attack, which I didn't think of in association with covert channels. This attack replaced the randomly generated 64-bit payload of ping packets with the target data, and sent the ping to a compromised server, in groups of four. As I recall the only way this would have been detected is if the operator of the ping utility was identified and checked - ping should only ever be run by cmd.exe, whereas in this case it was being executed by a malicious application.
Programmatically, it would be literally impossible to detect this compromise unless the security software is running on the attacked machine to link the user to the operation.
__________________
The best way to learn anything, is to question everything. |
|
|||
|
Hey all,
Thanks for all for the reply. The reason I was away is that I decided to change my solution approach. However, I think that snort is the best solution to detect covert channels. Snort provides one or two rules that can help in detecting ICMP payload covert channels. This is one example. Another example is to detect the "Dont Fragment" bit covert channel and so on. These are simple examples. However, snort doesn't provide such rules and one needs to write them customized. In addition, there are some smart covert channels that are very difficult to detect like the ISN covert channel and timing covert channels. I feel like lost!! the covert channels are soooo many and I don't know how to minimize the scope! Should I focus on storage covert channels only? |
![]() |
|
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Covert Video for use on web | opel | Marketing Strategies Discussion Forum | 2 | 07-23-2008 01:07 PM |
| New Affiliate Program & Contest - Covert IM Software 40% | Jambhala | Affiliate Marketing Discussion Forum | 0 | 09-27-2006 07:18 AM |
| Adsense Channels | rawdist | Google AdWords/Google AdSense | 1 | 03-25-2004 12:10 PM |
|
WebProWorld |
Advertise |
Contact Us |
About |
Forum Rules |
MVP's |
Archive |
Newsletter Archive |
Top |
WebProNews
WebProWorld is an iEntry, Inc. ® site - © 2009 All Rights Reserved Privacy Policy and Legal iEntry, Inc. 2549 Richmond Rd. Lexington KY, 40509 |