Domain hijacking, InterNIC loopholes





While filling in details for modification of my domain (dxm.org)

I realised that I haven't seen much written on domain hijacking.



We all know about mail spoofing, which let's you pretend you're

someone else. Mail spoofing is one-way - you can send, but not

receive. This is the same with IP spoofing, where you pretend

to be a trusted machine, but again you can send but not receive.

Unlike IP spoofing, which can lead to major security breaks (you

can become root on someone else's machine), domain hijacking is

not so much a security issue as a commercial one. Domain hijacking

uses loopholes in InterNIC domain registration procedures to

completely take over a domain, allowing you to send and receive

e-mail, and other traffic such as ftp/www. As I haven't seen this

explained, and have seen no warnings for sysadmins, here goes:



To do 'IP hijacking' (receive packets as well as send) you

will need to modify routing tables all over the place, where

you're not likely to have access. To do domain hijacking,

you would need to modify DNS entries in several nameservers,

to which again you're not likely to have privileged access. On

the other hand, if you could associate an existing domain with

a nameserver you _do_ control (root access on any machine

connected to the Net is enough for this), your lack of access

to the present nameservers would become irrelevant. So,

1. set up a nameserver on your machine, with address, cname or

   MX records as required for the victim domain address - victim.com.

   You can do fancy things with nslookup on victim.com's existing

   nameservers to find out what's required. Make sure the MX, address

   and cname records in your machine point to machines under your

   control.

2. send a modify domain mail to hostmaster@internic.net, with

   your machine as nameserver replacing any existing ones. The

   InterNIC has no authentication procedures for normal hostmaster

   requests, so your modification will get processed.

3. Ta DA! Wait for InterNIC to update its records and broadcast

   changes to other nameservers. From then on, a lookup for victim.com

   will go to ns.internic.net, find that ns.evil.org is the nameserver,

   and send all mail to @victim.com to victim.evil.org, route traffic

   to www.victim.com to www.evil.org, whatever you want.



This is not a security risk? No. But, to quote a delightfully

low-key document from InterNIC, "[such] an unauthorized update

could lead a commercial organization to lose its presence on

the Internet until that update is reversed."



Ah. But that update will be reversed only when victim.com's sysadmins

realise what's happened. If evil.org is clever enough, it will

not halt the mail flow, but forward everything on to victim.com

(after keeping a copy, of course). It could act as a proxy server

to www.victim.com, accessing all URLs (using victim.com's real

IP address) on demand and relaying them to browsers who are actually

looking at www.evil.org. And so on. Unless victim.com's admins

are particularly observant, they may not notice a thing.



How many sysadmins out there do what victim.com could have done? I.e.

run nslookup on victim.com regularly to check that the nameservers

listed are as they should be, and if they're not, to immediately

send a new update to InterNIC? Not many, I believe. On the other

hand I know no case of domain hijacking actually taking place. But

I don't know specific instances of WWW credit card fraud either.



That delightful InterNIC document I mentioned is the draft paper

on the InterNIC Guardian Object, first out in November 1995, latest

version out earlier this month. It's an internal InterNIC proposal

for a "Guardian Object" which would guard any other object (such

as a domain name, or individual, or hostname, or even another

guardian). It would allow a range of authentication methods, from

none (very clever) and MAIL-FROM (easy to spoof) to CRYPT (1-way

hash, like Unix passwd) and PGP (using public keys stored at

InterNIC). All domain and other templates will be changed to

work with guardians. The procedures in the original draft looked

easy enough; the latest ones are formidable.



šIncidentally, this draft appeared two months after the InterNIC

started charging. The wonders of the profit motive.





Rishab



ps. I'm not quite back on the Cypherpunks list yet, so please Cc

responses you feel are important to me at rishab@dxm.org.

pps. I quite forgot. The URL for the latest Guardian Object draft:

     ftp://rs.internic.net/policy/internic/internic-gen-1.txt