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