Zbr's days.

Hacking your ISP for fun and profit.

My ISP again blocked my account and can not unblock it although there are money on the deposit. There are serious problems in its billing system which requires manual intervention of the operator. Unfortunately it is a real challenge to call them, it already took more than half of a hour yesterday, and without success.
So, I decided to implement an interesting idea on how to bypass its blocking.

It is based on the security 'hole' in its (and I think vast majority of ISPs do the same) DNS configuration, which allows to request any DNS record even if account is blocked. It will be fetched from remote DNS server if there are no records in the IPSs cache.
Thus attack vector becomes visible: implement IP over DNS tunnel network device and setup local routing to use it by default. One has to control at least one remote machine which hosts DNS records for given domain name, since it is required to parse incoming DNS requests and process them accordingly.

There are at least two known IP over DNS tunnel solutions: NSTX (howto) and OzymanDNS (howto). Both solutions require that you own one or another server to run ip-over-dns tunnel server on it. Unfortunately I have only single machine with static IP address, which is not protected by lots of firewalls and allows incoming connections.

The simplest solution for this problem is to create iptables input target rule for the server, which will parse incoming DNS requests and redirect usual queries up the network stack to the userspace server, and handle 'poisoned' queries as tunnel.
Client can be TUN/TAP based, but can also be a tunnel network device.
I believe the more weird it looks, the more interesting it is, so likely will think more about kernel based tunnels.

DNS queries are limited enough not to allow binary data (IIRC, the most interesting is DNS TXT records), but it can be appropriately encoded and enciphered. So, will put it into todo list.
I even think that it is not that bad idea to have such modules in kernel :)

Erik wrote at 2008-06-27 02:26:

Take a look at iodine: http://code.kryo.se/iodine

Zbr wrote at 2008-06-27 09:07:

iodine looks even more interesting that other two solutions, but it still suffers from the same userspace problem: one has to control at least two servers outside the local network: DNS server with NS record and actual server.
The problem can be solved in a different way: to hack bind DNS server to be able to setup not only host names in its records, but also ports. Although there will be troubles with zone transfers, but it is possible to add somewhat a hack to use different ports for special names. But I never hacked ISC bind, so prefer kernel solution :)
Also there should be a way to workaround caching DNS servers, so system has to query new names (like random names or sequence counter in the controlled subdomain) each time it detects query was cached (or new name for each new query of ISPs servers caches all replies).

Erik wrote at 2008-06-28 17:29:

iodine uses 16-bit sequence number to keep queries from being cached.

valyala wrote at 2008-07-14 18:54:

ISPs also frequently provide free access to IRC servers. So it would be interesting to have "IP over IRC" solution ;)

Zbr wrote at 2008-07-15 10:46:

Do they allow to connect to any remote server or only ISP local one? The latter will not permit packets to reach own server in internet and send packets to other machines.

valyala wrote at 2008-07-23 15:58:

ISP IRC servers usually connected upstream to internet-visible IRC servers. So you can communicate with people, which are connected to internet-visible servers.

Pascal Terjan wrote at 2008-07-27 22:28:

There is another dns tunnel software working fine, dns2tcp that I have been using since last year http://www.hsc.fr/ressources/outils/dns2tcp/download/
Regarding the need for a dedicated server, you can tell bind to forward requests for a zone to another port

Zbr wrote at 2008-07-27 23:57:

Thanks for the link, but that application will not work for browser for example (as long is it is not forwarded via ssh) or any other tool, which can not be started via dns2tcp wrapper.

Thu, 26 Jun 2008