Domain name takeover and spoofing
By Squire James squirejames@geek.com
1.0 Introduction
2.0 What exactly is DNS?
3.0 What is the difference between spoofing
(cache poisoning) and takeover?
3.1 So what's it good for then?
3.2 The commonly held misconception
4.0 How do I know what box to take over?
5.0 I've got root, what happens next?
5.1 Modifying the records
6.0 DNS Spoofing
6.1 How does it work?
6.1.1 Attack 1: DNS Packet ID prediction
6.1.2 Attack 2: Caching data
7.0 How can I make my Name Sever secure?
8.0 Final words and shout out's
1.0 Introduction
Well, it looks like black.box is back on track again, and ready to
publish a new set of articles (woohoo!). For those of you who may
have been reading black.box for a while now, you may remember one of
the questions in the Q&A section of Issue #12. Simply put, it went
like this;
I have several questions that you could put on the black box
the first is about domain name hacking on the net. I would
like the knowledge to change redirecting on domain names and
taking them over, if you could put this on the site muchas
grasias
Well, zWanderer asked me to write and article in response to the
question in return for a lifetime supply of Guinness. Well, maybe not,
but it's a nice thought. I probably don't really deserve a lifetime
supply of anything, since this paper will be pretty short, but I live
in hope.
If you do it, it's not my fault, if you tell someone how to do it and
they do it, it's not my fault. If your hair falls out, it's not my
fault. If women find you unattractive because you're a computer geek
it's not my fault. In fact, if anything happens, ever, It's not my
fault, honest.
2.0 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 IdleHands Paper on the basics of TCP/IP in black.box
issue# 10 and my articles on the OSI Stack and subnetting in black box
issues# 11 and 12 respectively. 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.
3.0 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.
3.1 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.
3.2 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%\system32\DNS.
4.0 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-1advertising.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.
5.0 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.
5.1 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).
6.0 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.
6.1 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.
6.1.1 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, but I doubt it).
6.1.2 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.
7.0 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.
Apart from that, 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.
http://education.hp.dk/dns/SecuringNameServers.pdf
8.0 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.
A couple of quick shouts...
thredheaddeb - Thanks for putting up with a geek
Dazzler - Yo Brother Noomsi, wicked!
UmmYep - Get a haircut, and get a real job
(
geocities.com/eljehad1)