91 lines
4.6 KiB
Plaintext
91 lines
4.6 KiB
Plaintext
|
||
|
||
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.
|
||
|
||
|
||
|
||
<EFBFBD>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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|