💾 Archived View for spam.works › mirrors › textfiles › internet › domain.hac captured on 2023-11-14 at 10:22:54.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
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