1 . A covert channel is a communication channel that violates a security policy

Question

1 . A covert channel is a communication channel that violates a security policy by using shared resources in ways for which they were not initially designed (Cabuk, 2009).   A storage covert channel involves a location to which the covert channel sender writes and from which the receiver reads. A timing covert channel is established when the sender can modulate the receivers response time in a way that can provide information. An excellent example of covert storage channels in a well known application is the ICMP error message echoing functionality. Due to ambiguities in the ICMP RFC, many IP implementations use the memory within the packet for storage or calculation. For this reason, certain fields of certain packets, such as ICMP error packets which echo back parts of received messages -- may contain flaws or extra information which betrays information about the identity of the target operating system. This information is then used to build up evidence to decide the environment of the target (Covert Storage Channel, cwe.mitre.org) . This is the first crucial step in determining if a given system is vulnerable to a particular flaw and what changes must be made to malicious code to mount a successful attack.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Type your question here

Explanation / Answer

DNS Tunnelling by psi 1. Introduction 2. What is it? 3. Why is it necessary? 4. How does it work? 5. Example 6. Final Words 7. Links and Sources 1. INTRODUCTION "If, on one system, it is possible to transmit bits to another in any form, and in turn receive a reply as a result of that transmission, then it is inherently impossible to effectively limit or censor the flow of data between them." - Father Andrew of the C.o.W. 2. WHAT IS IT? The technique of DNS tunnel involves encapsulating binary data within DNS queries and replies, using base32 and base64 encoding, and to use the DNS domain name lookup system itself as a bi-directional carrier for this data. Therefore, as long as you can do domain name lookups on a network, you can tunnel any kind of data you want to a remote system, and also the internet. 3. WHY IS IT NECESSARY? In short, it is not. DNS tunnelling is inefficient, slow and wasteful. But, sometimes it is all you might have. e.g. hotspots at airports or coffee shops, where you need to purchase internet time on their network. Ultimately, it is just an interesting experiment in how DNS and tunnelling works. 4. HOW DOES IT WORK? For a better understanding of how DNS work, definitely have a quick read through http://en.wikipedia.org/wiki/Domain_name_system . Let's assume you are connected to a network that allows DNS lookups, but no other traffic. To tunnel data over DNS, you will need control of your own domain, and an internet connected computer for running a proxy disguised as a DNS server. First of all, you will add two records for your domain. If you own example.com, you will add a NS record (see wikipedia) for a subdomain, like: t.example.com NS my.proxy.com . This tells the DNS servers for example.com to delegate all DNS queries regarding t.example.com (and its subdomains) to the specified server (my.proxy.com). So, if the DNS server for example.com ever gets asked "What is the address of test.t.example.com" , it will say "Go ask my.proxy.com". The second record is not strictly necessary, but it would be good form to add it. It is either an A record for the address of my.proxy.com if the proxy server has a static IP, or a CNAME record if the proxy has a dynamic address and you're use a service like dynDNS. (See wikipedia on A and CNAME records). Now, if you do a query for hello.t.example.com , the query will get relayed to your proxy server at my.proxy.com (which acts as a fake DNS server). The proxy can parse the data part of the query ("hello"), and return an appropriate response in the form of a DNS reply: "Hi there". As you can see, this is bidirectional flow of data. ---- On the client side: On the client side, binary data is encapsulated in DNS queries using base32 encoding. This is because domain names are alphanumeric and case-insensitive, so you only have [a-z],[9-0] and a couple other chars for encoding. A DNS query string is in the form: label3.label2.label1.example.com , where the maximum length is (in theory) 255 characters, with a limitation of 63 chars per label. You are effectively limited to about 200bytes of base32 encoded data per request, which is highly inefficient. A lot of DNS queries will have to be made on the client side, which might be detected by network monitoring systems. ---- On the proxy side: The proxy server has slightly more space for sending a reply. It could make use of a TXT record or EDNS0 message. "TXT records allow free-form data and can even include spaces. You can as such store information in it encoded with base64, allowing 220 bytes of data per record. EDNS0 messages can be larger than the 512 byte maximum for UDP DNS, and can carry a 1280 byte payload by default. OzyManDNS uses a 768 byte payload for stability" [1] ---- Other problems: The only problem is that the proxy server cannot just send information to the client whenever it wants to. It may only send a reply packet to a DNS query, therefore the client will have to implement a polling mechanism to periodically check whether the proxy has data for it, which also decreases efficiency. 5. EXAMPLE As an example, let's transmit the data "Greetings!" and then receive a reply "Hello...". 1. First b32encode "Greetings!" on the client side and encapsulate it in a DNS query: I5ZGKZLUNFXGO4ZB.t.example.com 2. Do a standard lookup request for I5ZGKZLUNFXGO4ZB.t.example.com . The request goes to the DNS server for .com which says "I don't know that, but I do know the address of example.com, ask the DNS server of example.com at address: 123.123.212.212". That server says "I was told to delegate that request. Ask the server for t.example.com at address: my.proxy.com". So, the request gets forwarded a couple of times and eventually reach the "DNS server" at my.proxy.com . 3. The proxy server takes the part in front of ".t.example.com" and base32 decodes it to get "Greetings!" again. 4. The proxy server base64 encodes "Hello..." to get "SGVsbG8uLi4=" and returns that in a TXT record. 5. The client receives "SGVsbG8uLi4=" and b64decode's it to get "Hello..." 6. FINAL WORDS For a proper DNS tunnel, all that needs to be done is have the proxy forward all incoming data to an internet server. For instance, you might specify that the proxy server forwards all data to "irc.shadowfire.org". When the client "connects" to irc.shadowfire.org, it actually sends b32encoded data up the tunnel to the proxy. The proxy decodes it and forwards the data to irc.shadowfire.org. The replies from shadowfire.org to the proxy gets b64encoded and gets sent down the tunnel to the client. 7. LINKS AND SOURCES Current DNS tunnelling projects: NSTX: http://savannah.nongnu.org/projects/nstx/ OzyManDNS: http://www.doxpara.com/ DeNiSe: (python) http://c0re.23.nu/c0de/snap/DeNiSe-snap-20021026.tar.gz DNSLabyrinth: (python) http://labyrinth.za.net Other DNS tunnelling pages: http://www.daemon.be/maarten/dnstunnel.html http://thomer.com/howtos/nstx.html http://dnstunnel.de/ Sources: [1] http://www.daemon.be/maarten/dnstunnel.html

Related Questions

Navigate

• Browse (All)
• Browse 1
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.