Domain name takeover and spoofing

Posted by linuxbox Saturday, May 04, 2002 - 09:14 PM EDT

This article (supposedly) serves to instruct the reader into the methods and
workarounds when dealing with DNS takeovers and spoofing. Unfortunatley, there
seems to be some confusion within circles as to the difference between DNS
takeovers and spoofing. This document trys to answer these questions. Also, please
note that I am not trying to instruct anybody in the In's and Out's of the DNS
system itself, and I assume that you at least know what DNS is used for, and how
to setup a simple DNS domain. If you don't know, read some DNS tutorials that
you'll find anywhere (using your internet best-buddy, google.com), and check out
the RFC's for DNS. Also, I haven't really tried this with MS systems (Such as
Windows NT or Wnidows 2000), if anybody does, please feel free to drop me a note
and let me know how it went/what you found and I'll include the details in the
next revision of this document and give you credit. Otherwise, I'll have to do it
myself, and I'm a lazy little prick at the best of times.

What exactly is DNS?

Firstly, DNS is known my many names, and I think I pretty much use them all in
this paper. The original version of a DNS server was called BIND. However, there
are many different versions of the original, and you may see them referred to as
DNS servers, named servers, or the plain old unbiased nameserver(s).

The core of everything on the Internet is based around TCP/IP. If you've been
seriously playing with computers for any amount of time I'm sure that you've come
across the concept of an IP address, which is a set of 4 numbers ranging from 0 -
255 divided by a period. If you have no idea whatsoever about what the hell I'm
talking about, stop now and read a paper on the OSI stack and TCP/IP. Then read it
again until you understand it. This should give you enough information to follow
what I'm talking about (hopefully).

Now, every machine on the Internet needs a unique IP address, as this is the
ultimate source that all packets will be routed to. However, we humans are pretty
stupid when it comes to remembering all those groups of numbers, and to get around
this problem, the Domain Name System was invented.

In the Domain Name System (DNS), a nameserver holds records for all the different
domains that it serves. These records supply mappings from Hard-to-Remember IP
addresses to easy to remember Domain Names (like black.box.sk). That's it, that's
all that DNS does. However, remember that everything, including emails
(%yourname%@%domainname%) rely in this system to get to where they need. The DNS
server's records detail exactly what each host in the entry will do. For example,
there are MX records (For Mail Exchanger), and you generate records that point to
www.domain.com ftp.domain.com etc. etc.

What is the difference between spoofing (cache poisoning) and takeover?

Essentially, a domain takeover occurs when somebody takes control of the zone
records for a particular domain, and changes the entries so that users are now
pointed to a different IP. A spoof is when tailored responses are sent to DNS
servers in response to their requests, causing the nameserver to enter bad data
into its cache. This may not seem like it's really much use for anything except
redirecting the www pages to a "your site is hacked, because we're 5up3r l337"
page, but there are many things that these changed entry's can be used for.
So what's it good for then?

One of the scariest things about losing control of your DNS (and the coolest thing
if you get your greedy little paws on somebody else's), is the ability to reroute
all of their incoming mail to a new location (by modifying the MX record).
Essentially, if you have a permanent IP address, you can redirect all incoming
mail for a particular domain to your own sendmail (or whatever) box. You could
then script the box to receive the mail, make a copy and then forward to the
fixed-ip address of their mail server. Viola! You now have all inbound
correspondence, and thanks to the fact that most people include the original email
when replying, you'll end up with both sides to a lot of stories.

Apart from that, there's a whole heap of things that you could do in conjunction
with a Domain takeover. I'll leave it up to your fertile imaginations to work out
other things that you could use it for.

The commonly held misconception

The Domain Name takeover does not rely on any particular flaw with the DNS system.
In fact, it has very little to do with the DNS system at all. The only way that
you can try something like this is by gaining root on the primary name server, and
then altering the zone records. So, as you would probably imagine, it doesn't
really happen to often. However, since the question was pretty broad one I thought
I'd include it. If you already know heaps about DNS and you're not really
interested, skip to the spoofing section. Naturally, this type of attack is quite
difficult to effect on a Windows 2000 or NT server, as there is no console access,
which makes things difficult. For those of you who wish to hack out DNS on a
Windows NT box for a complete "takeover", you need to NetBIOS hack \%servername%C$
(as long as C: is the system drive), or somehow get a trojan on the box, and then
alter the records which you will find in %systemroot%system32DNS.

How do I know what box to take over?

The only machine that can update the Domain Name information for a site is the
Primary Name Server. Everybody has their favourite tool to find the name servers;
here are a couple of ways.

Unix head's

Use dig. If you don't know how, check out the man pages. It's pretty
straightforward. Just dig the domain name that you want from your name server, and
then dig the domain name from the actual domains domain name servers, which will
hopefully respond with an SOA record (just remember to use a recursive dig).

Windows Users

You'll need a third party piece of software for Windows 98, or access to a domain
name server with a web interface, as dig isn't part of the Windows TCP/IP suite
(yayyyy, thanks Microsoft). Well, you can use the ls command from within nslookup
on NT/Win2K/XP systems. However, I'd suggest downloading SamSpade, the output is
easy to read, it does all of the work for you, and it's free.

Essentially, from within Sam Spade, you want to perform a Dig to the domain name
in question, which will hopefully get you all of the information that you need.

Alternates
Search on google for web dig interfaces, there's a few about.
Now, whichever method you use, you should get a similar output. Have a look below
at the example that I have included below, which I got from Sam spade. Most unix
systems will do a simple recursive dig from your own name server, and then you've
got to dig one of the nameservers to find out the primary. Sam spade does it all
for you.

Domain: spankme.com

Query for spankme.com type=255 class=1

spankme.com A (Address) 208.236.11.27:
spankme.com NS (Nameserver) ns.nationala-1advertising.com
spankme.com SOA (Zone of Authority)
Primary NS: ns.nationala-1advertising.com
Responsible person: 1webmaster00@nationala-1advertising.com
serial:5
refresh:43200s (12 hours)
retry:36000s (10 hours)
expire:259200s (3 days)
minimum-ttl:86400s (24 hours)
ns.nationala-1advertising.com A (Address) 208.236.8.10

Looking further down the record, we can also find the following

Query for spankme.com type=255 class=1

spankme.com NS (Nameserver) NS.NATIONALA-1ADVERTISING.com
spankme.com NS (Nameserver) NS3.NATIONALA-1ADVERTISING.com
spankme.com NS (Nameserver) NS4.NATIONALA-1ADVERTISING.com
spankme.com NS (Nameserver) NS4.NATIONALA-1ADVERTISING.com
spankme.com NS (Nameserver) NS.NATIONALA-1ADVERTISING.com
spankme.com NS (Nameserver) NS3.NATIONALA-1ADVERTISING.com
NS.NATIONALA-1ADVERTISING.com A (Address) 208.236.8.10
NS3.NATIONALA-1ADVERTISING.com A (Address) 208.236.11.20
NS4.NATIONALA-1ADVERTISING.com A (Address) 209.218.113.195

You can see the primary name server listed in the first indented line, which reads
Primary NS: ns.nationala-advertising.com. If all that you can get is the second
set of outputs, then the administrator of the domain has been smart and restricted
zone transfers (i.e. digs). If this is the case, then you'll have to use NSLookup
to generate your query, and set the record type to SOA. For Windows9x users, who
don't have nslookup as part of the TCP/IP suite, use this web page as an excellent
online version:

http://www.hexillion.com/utilities/

Once you have the primary name server identified, it's now up to you to hack it
(try to avoid doing it like a script kiddie, OK?). Once you have root access on
the box, you can go onto the next stage.

I've got root, what happens next?

Well, essentially all that you have to do is alter the record on the nameserver to
reflect whatever changes you want. There are a couple of things that you have to
watch out for, though. Firstly, you've got to find out where the DNS records
themselves are stored. To do this on most Linux systems, you need to look in
/etc/named.conf (/etc/named.boot on older systems) to see the named record
directory. Generally the first thing inserted into the config file is the location
of this directory, although different bind implementations and versions do it
differently. Here is the first part of an example BIND 8 configuration (taken from
http://www.cv.nrao.edu/~dbrown/lunch-talks/bind-8.2/page.4.shtml)

/*
* A simple BIND 8 configuration
*/

options {
directory "/var/named";
};

There you go, you now know that the records can be found in the /var/named
directory. You can check out the named.conf for the actual filename of the
database etc.

zone "isc.org" in {
type master;
file "master/isc.org";
};

And now we know that the database file for the records of isc.org can be found
from within /var/named/master/isc.org. Once you manage to find the zone file, open
it up and have a look. I've inserted an example zone file below.

royal.com. IN SOA squire.royal.com. squirejames.royal.com. (

2002011301 ; Serial
28800 ; Refresh
3600 ; Retry
3600000 ; Expire
86400 ) ; Minimum

royal.com. IN NS squire.royal.com.
royal.com. IN NS baron.royal.com.
royal.com. IN NS ns.yourisp.net.
royal.com. IN NS ns2.yourisp.net.

royal.com. IN A 192.168.0.1
squire.royal.com. IN A 192.168.0.2
baron.royal.com. IN A 192.168.0.3
messenger.royal.com. IN A 192.168.0.4
backupmail.royal.com. IN A 192.168.0.5

www.royal.com. IN CNAME royal.com.

ftp.royal.com. IN CNAME royal.com.

royal.com. IN MX 5 messenger.royal.com.
royal.com. IN MX 10 backupmail.royal.com.

; End of Zone file

Looking at the record, there are a couple of things that should be pointed out. We
have in the DNS a number of record types, including NS records, A records, CNAME
records and MX records.

NS records contain the nameservers for the domain

A records resolve a fully qualified domain name to an IP address

CNAME records "redirect" that name to the server listed (in this example, both
www.royal.com and ftp.royal.com ultimately direct to royal.com, or 192.168.0.1).

MX records are mail exchanger records, showing the mail servers that will receive
mail for the domain. Essentially speaking, the one with the lowest number takes
the highest priority, so if you ever want to steal somebody's mail, make sure that
you put your mail server in at a higher priority, otherwise you'll only get mail
when the other server cannot be reached.

There is one other record, called the SOA record, which appears at the start of
the record. The SOA (Start of Authority) record is always the first record, and it
contains lots of useful information. The main one that we are concerned about is
the Serial Number, which I'll go into in the next section. Another bit of useful
information that you can get from the SOA is the primary name server, this is the
first DNS name after the phrase SOA, which in my example is squire.royal.com.

Modifying the records

In my example, I am going to modify the records to redirect the sites mail to a

new location, and to redirect www.royal.com to a new location.

Essentially, I will create a new MX record for my mail server, leaving the other
MX records in, but assigning a higher priority with the new record. This means
that if my server dies, the mail will just go to the next server on the list,
which means that people won't stop getting mail, and I don't get caught
(hopefully). I will also create an A record to my mail server. I will also create
a new A record for www.royal.com, and delete the current CNAME entry, as we will
be directing www.royal.com to a new IP unique address so a CNAME won't do the job.

On to our final tasks (and these are the two bits that everybody ALWAYS forgets).
Firstly, we have to increment the serial number contained in the SOA record, as
zone transfers to the secondary's only occur when the serial number on the Primary
is different. Most records are setup with a serial number YYYYMMDDxx, with xx
being a number that is incremented just in case more than one change is done in
the one day. Once the record is changed on a different day, this number is
generally returned to 01. Secondly, always remember to put the period after you
have finished typing in any name, as that makes it a fully qualified name. If I
left it off squire.royal.com., the record would really be
squire.royal.com.royal.com. Because of that, it is possible to just put entries in
like "www", as royal.com would automatically be appended. Here's the trick, err on
the side of caution. If you're not sure, type the whole domain name in and end it
with a period. Okay, so when I finish, my record will now look like this;

royal.com. IN SOA squire.royal.com. squirejames.royal.com. (

2002011302 ; Serial
28800 ; Refresh
3600 ; Retry
3600000 ; Expire
86400 ) ; Minimum

royal.com. IN NS squire.royal.com.
royal.com. IN NS baron.royal.com.
royal.com. IN NS ns.yourisp.net.
royal.com. IN NS ns2.yourisp.net.
royal.com. IN A 192.168.0.1
squire.royal.com. IN A 192.168.0.2
baron.royal.com. IN A 192.168.0.3
messenger.royal.com. IN A 192.168.0.4
backupmail.royal.com. IN A 192.168.0.5
www.royal.com. IN A 200.200.200.1
soulsearcher.royal.com IN A 200.200.200.2

ftp.royal.com. IN CNAME royal.com.

royal.com. IN MX 1 soulsearcher.royal.com.
royal.com. IN MX 5 messenger.royal.com.
royal.com. IN MX 10 backupmail.royal.com.

; End of Zone File

One thing to note is that if my mailserver with a permanent IP address already has
a DNS record active for it (say soulsearcher.com), you can leave off the A record
that was created, and just create an MX record pointing directly to the DNS name,
i.e.:

royal.com IN MX 1 soulsearcher.com.

And that's it, it's all done. Now all I have to do is restart the named service on
the machine (or just crash it if it's an NT box, it's still the easiest way to
remotely stop and restart all services), or wait for the refresh period in the
SOA, at which time all the secondary's will check back for changes (in this case,
28800 seconds, or 8 hours). After that, anybody that want's to get to
www.royal.com will be directed to 200.200.200.1, and all mail will be sent to
soulsearch.royal.com, or 200.200.200.2.

Having said all that, it's pretty stupid to ever try something like this, as
somebody one day will get suspicious, inspect the zone file and trace you to your
fixed IP. However, it is an acceptable way to instantaneously direct everybody to
a new web page (that you can't be traced from).

DNS Spoofing

DNS spoofing is used to give BIND servers incorrect information about a domain
that they will generate a request for. Note: This will not effect or alter the
zone files on any of the domain NameServers. The only way to alter the Zone file
is by hacking the name server. A DNS spoof is generally much easier and safer then
hacking a system and changing the record manually, but most systems are now pretty
well protected against this form of attack. On top of that, since spoofing is
based on cache poisoning, whenever the service restarts all of the information in
the cache will disappear, and the spoof will have to be reapplied before the
redirection will take effect again.

If you're seriously trying to take over a Zone Record permanently, or make an all-
encompassing change to the resolved IP addresses for a domain, then the full hack
is the only way to go.

How does it work?

First of all, you need to picture exactly how a spoof works. All that we are going
to do is feed a namesever information about a certain domain. If we do it
properly, then the nameserver will enter the information that we send it into it's
cache, and anybody that queries the nameserver will get the cached information.
This is all that spoofing can be used to do, it can only effect individual
nameservers that will query for a particular domain.

There are two main methods of attack that I have come across that may be used to
spoof a DNS server, and although most (smart) Administrators have protected their
servers from this form of attack, you may be able to find the odd server that is
still unpatched. Furthermore, if you're serious about trying to spoof, read the
DNS RFC's (http://www.rfc-editor.org/rfcsearch.html) and get to know the packet
structure as well as you can, it will take quite a while of staring at packet
captures and generated requests before you'll be able to create them for use with
a packet injector.

As a further note, if the nameserver already has the information that you want to
spoof in it's cache, it's not going to work, as the server won't generate the
request. Therefore, you'll generally have to "arrange" for the service to crash
before you can do much.

Attack 1: DNS Packet ID prediction

What you need: Brain

A Primary Name Server for a domain
A Packet Injector
The Ability to DoS

You can get packet injectors from the following locations:

Win9x: http://home19.inet.tele.dk/moofz/index_o.htm
Linux: http://packetstormsecurity.org/UNIX/utilities/nemesis-1.0.tar.gz

How it works: Every DNS packet has a 16-bit ID number that it uses to determine
what the original query was. As DNS queries run on UDP connections, there is no
sequencing of the packets etc. etc. so all we have to worry about is getting the
ID number correct. What you have to do is generate a query for your name server
from the server that you want to receive the spoofed entry. Capture the packet as
it comes through. While this is going on, DoS the nameservers for the domain that
you wish to spoof. Get the ID-Number from the packet, generate a packet resolving
whatever you'd like (in this case an MX record for the name), increase the ID
number in the packet by one. Then, generate a request for the MX records of the
domain you want to spoof from the nameserver you want to receive the spoofed
entry. Straight afterwards, send your constructed packet through to the
nameserver. If there were no other requests before your packet arrived, then the
nameserver should enter the information into it's cache and viola, instead of the
MX record pointing to mail.acme.com, it's now directed at whatever you like. Cool,
eh?

Down Side: There has been a patch released to randomise the number by SNI. This is
available for BIND, but I am unaware of any such patch for microsoft, I've never
spoofed to a MS DNS server, so they could well randomise their packets already,
although I believe that this is certainly not the case for Win9x/ME boxes.

Attack 2: Caching data

What you Need: Brain

Primary Name Server
Second machine running as a subdomain nameserver
Packet injector

How it works: When a nameserver generates queries to another nameserver, it is not

sure how much information it is going to get, so we can fill it full of spoofed
information which it will accept (if it's not patched, anyway ;-). How we generate
this scenario is by setting up a sub-domain under your registered domain;

royal.com. IN SOA squire.royal.com. squirejames.royal.com. (

2002011302 ; Serial
28800 ; Refresh
3600 ; Retry
3600000 ; Expire
86400 ) ; Minimum

royal.com. IN NS squire.royal.com.
sub.royal.com. IN NS spoofer.royal.com.

squire.royal.com. IN A 192.168.0.2
spoofer.royal.com. IN A 192.168.0.50

; End of Zone File

Now, we start our packet injection program on spoofer.royal.com, which will

respond with the information that we want (eg an A Record for www.acme.com etc.
etc.) as soon as the query from the nameserver that we want to provide spoofed
information to reaches it (eg, ask for all A records from sub.royal.com).
Hopefully if your packet is formed properly, and the DNS server isn't too smart,
it won't realise that the information you're feeding it has nothing to do with the
domain being queried. However, if the entries are not placed into cache it's
probably because the nameserver has cottoned on. The only way around that is to
generate something like a CNAME record from acme.com that relate to a host on the
domain being queried (royalty.com), which ultimately has an A record that resolves
to the IP address that you ultimately want to send the data too. Unfortunately,
there is no set standard in tricking a nameserver, you've just got to try
convolute things until they work, and you may need to build a couple of queries
into the final solution. The main benefit with this method is that you don't DoS
the nameservers as you generate a request to the royal.com domain, so there's a
very good chance that nobody will catch you, and once you get it all set up, it's
surprisingly easy.

How can I make my Name Sever secure?

Probably the easiest way to avoid getting hacked, is to make your primary
nameserver "invisible" to requests.

Firstly, create a zone file like this one....

royal.com. IN SOA squire.royal.com. squirejames.royal.com. (

2002011301 ; Serial
28800 ; Refresh
3600 ; Retry
3600000 ; Expire
86400 ) ; Minimum

royal.com. IN NS ns.yourisp.net.
royal.com. IN NS ns2.yourisp.net.

royal.com. IN A 192.168.0.1
squire.royal.com. IN A 192.168.0.2
baron.royal.com. IN A 192.168.0.3
messenger.royal.com. IN A 192.168.0.4
backupmail.royal.com. IN A 192.168.0.5

www.royal.com. IN CNAME royal.com.

ftp.royal.com. IN CNAME royal.com.

royal.com. IN MX 5 messenger.royal.com.
royal.com. IN MX 10 backupmail.royal.com.

; End of Zone File

Essentially, what I have done here is created a zone file with a primary name
server that is not being "published" to the real world as it is not listed in the
name server section (i.e. as a NS record). Just make sure that it's still an A
record, so the BIND machines can find it when they need to zone transfer. This
means that the primary name server can only be found by doing an SOA record check
on the domain name. Even if the cracker get's the primary server name, they will
not see any open ports on the server due to the access list restrictions on the
firewall. Instead, I have only published the ISP's DNS server, so they get all
name requests, meaning that I have,
a) Cut down on my bandwidth consumption, and
b) Can now restrict access to the DNS server

Once you have propagated the record, configure your firewall to reject any
requests on UDP port 53, which is the port that DNS listens on for name
resolution, and apply a second access list that allows TCP port 53 access only
from the IP address of the secondary name servers. TCP port 53 is the port that
DNS uses for zone transfers (i.e. propagating record changes). After that,
configure BIND so that it will only zone transfer to the IP addresses of the
secondaries. You'll have to check out the man pages/microsoft support page to work
out exactly how to do it on your system (or refer to the link supplied at the
bottom of this section), but if you implement it, it means that nobody can dig
your domain except for the secondaries (who are the only ones that need to). Just
make sure that your ISP is restricting zone transfer from their nameservers,
otherwise it's not worthwhile at all. Furthermore, don't name your DNS server NS
or NS1 or something like that, as it is the first thing that a cracker that's
serious about his job will start checking.

So, if we do all this, we create the following scenario,

1. Only the ISP's nameservers get requests (thanks to the record)

2. The name of the primary nameserver will never be from a Dig (thanks to
restricting the zone transfers), although it can be found via an NSLookup on the
SOA record.
3. The only port open on the DNS machine is TCP/53, and that is only to
the ISP's nameserver (thanks to your firewall and nameserver
configuration), which means that even if somebody portscans the
primary nameserver, they won't see any ports open, so they'll have
no idea what it does, or even what OS it is.

Apart from that, about the only thing that you can do is make sure you apply
relevant security patches as they come out and that's pretty much as secure as you
can make your nameserver from malicious cracking attempts.

Now, as far as the prevention of spoofing, the best thing to do is upgrade your
nameserver to the newest version. That way you'll have all of the latest patches,
which keep getting smarter and smarter about forged packets, as well as applying
the randomising patch to any implementations of BIND that you may be running, and
that's about the best you can do. There is nothing you can do about having your
domain records spoofed to something else on another nameserver.

Also, the only servers that can be effected by spoof attacks are recursive
servers. A recursive DNS server is one that will respond to query request, and try
to get all of the information that it can about a certain site, allowing a
malicious cracker to pass malformed data and attempt to alter the cache. However,
you cannot switch the server into iterative mode if you intend to serve any DNS
requests to anybody, which unfortunately, most nameservers have do.

You can also check out the following web page for a list of
commands/configurations of various implementations of BIND/Microsoft DNS etc. and
for a couple of other ideas to help prevent become effected by spoofing.

Final words and shout out's

Well, there it all is. If you're serious about trying to spoof then you really
have to get into the RFC's (http://www.rfc-editor.org/rfcsearch.html) and start
pulling apart the packets themselves to get to know how they work. Obviously, this
has not been an all-encompassing paper on DNS, as I have really only touched on
the security side of things. After that, it's just a case of some at home trial
and error and before long you'll be cache poisoning all over the place.

couple of quick shouts...

Dazzler - Yo Brother Noomsi, wicked!

UmmYep - Get a haircut, and get a real job
IceBerg - pimp mastah yo!
Drew - Tomorrow the world... bwahahahahahhaha!
X - xtrition.org, the single greatest link site in the world, keep up the good
work!
Saruman - Keep it real big fellah!

Article By Squire James