IP Tunneling Through Nameservers
But did you know that you can build up a fullfeatured and even bidirectional IP tunnel through Nameservers? Yes, that's right: "IP-over-DNS".
Using some toll free numbers which normally only allow outgoing packets to some few chosen servers, you can now surf the internet - completely and doing everything you could do with your normal, fullfeatured internet account. Microsoft has some of those restricted, toll free numbers.
The reason is: Most of these Microsoft PPP dialins allow you to use a Nameserver. And DNS lookups are just another kind of communication between a server and a client - the client asking for information to the nameserver known to him, the server which has been asked forwards the information to another nameserver or directly to the nameserver responsible for the asked information, and the now contacted server answering through the same path back.
That still sounds very useless for tunneling, but think about encapsulating the IP packets into nameserver requests, and the answer contains the traffic of the other direction. The request would look something like a hostname lookup to "KJhjh33.dd_2sT-XXT.dAAoi_f.mydnstunnel.org" (you see, the traffic is being encoded to represent legal hostnames), the answer contains the payload in a TXT record. That way you can build a fully functional IP tunnel.
You just need a client and a fake nameserver - making up the two communication endpoints.
It was tricky - the DNS protocol seems a little bit chaotic and it only allows packets of 512 bytes - so you have to fragment. And it uses UDP and not TCP - so you have to implement some mechanisms to ensure that the fragments are reassembled correctly (you see, you basically need a protocol which reimplements some features of IP and TCP). Additionally, the client can "contact" the fake nameserver everytime it wants to send traffic out - but the server is only able to answer, never to send on it's own. So you need some polling, if you want it really bidirectional.
We called the protocol used to achieve all this the "NSTX Protocol", meaning "Nameserver Transfer Protocol". The uglyness of the DNS protocol (just look at the headers: no alignment and no padding!) and the fact that we tried to use it in a way it really never was designed for (after all, remember that DNS is more like a phonebook than a communication facility) didn't make the design and implementation of NSTX easier at all.
But finally, we've done it. And with a toll-free Microsoft PPP dialin number in Germany (which of course only allows the download of some patches etc.) it worked - surprisingly stable and not even slow.
Think about it - many companies have "closed" networks which also don't allow outbound connections, but they have a nameserver in the same network that can resolve any hostname out there. That way you could also use the tunnel to establish a bidirectional communication path between the secured network and the outside world, where it wouldn't have been possible.
For everyone who likes to play around with this new kind of tunnel that probably only few persons have ever thought of, just take a look at http://nstx.dereference.de where you can find the full source code. It implements a client and a fake nameserver for both tunnel endpoints of an "IP-over-DNS"-tunnel. Both use the Linux Ethertap device for giving you a tunnel network interface. The server is a fake nameserver fully compliant to the DNS specifications and the client issues the requests, also using intelligent timing mechanisms for polling queued traffic from the server.
Maybe security managers in companies should look if they have nameservers in places where they better shouldn't have.
And maybe you also like the idea of using the internet using a toll free Microsoft dialin number, completely at no charge."
Sounds exactly like the IP equivalent of declining a collect call from "Itsaboy Eightpounds".
There was this little item in Bugtraq that I stumbled across while trying to hit thier site (doing a Google search for "DNS tunnel")- seems someone previously did a demo of this exploit with the intents of putting in Phrack, deciding to put it up in Bugtraq instead.
Look here for the info in question.
Letsee now...
HTTP Tunnel.
Mail Tunnel.
Now, DNS Tunnel.
Wonder what wonders they'll come up with next.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
http://hostname.tld:79/\ userid
Note the space preceeding the userid.
Totally wrong protocol to send to finger yet it worked. The HTTP protocol sends a "GET / userid HTTP/1.0" to the finger daemon. Luckily fingerd supports multiple userid lookups at the same time. Naturally 'GET' and '/' and 'HTTP/1.0'resolve to invalid users, but userid retrieves the .plan file!
Since HTTP ignores stuff preceding the <HTML> tag, my web page rendered correctly! From a system where such things were prohibited! Woo hoo! In your face Woods (the sysadmin back then)! Of course, few people cared back then as the web was a whacked far out academic project. Gopher was the big thing back then. Blargh.