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