DNS (53 TCP,UDP)

DNS (53 TCP,UDP)
DNS must be one of the most underrated services in terms of hacking. DNS is most powerful. Let us look what can be done by only manipulating DNS. Let's assume that I have full control of a domain's primary DNS server. For this example we'll assume that the domain name is sensepost.com. Sensepost.com's has two MX records; one marked as pri 10 - wips.sensepost.com and the other pri 20 - winston.mtx.co.za. Let say for now that I insert another MX records at pri 5 - and point it to attacker.com. What would be the effect of this? All mail to sensepost.com would first travel to port 25 at attacker.com. At attacker.com it can be read at leisure and then redirected to the MX 10 (wips.sensepost.com), and we won't know of any better. Sure, if one look at the mail header it will show that the email is relayed through attacker.com, but how many people check their mail header on a regular basis? How do we do the actual redirect? A slightly modified version of "bounce" (a popular TCP redirector program that is available for just about any platform) comes in very handy. The program binds to a port and redirects any traffic from one IP to a port on another IP. I have modified bounce in order to see the actual traffic - line 75 is inserted and reads:
fprintf(stdout,"%s\n",stail);
and inserted line 83 reads:
fprintf(stdout,"%s\n",ctail);
so that all "server" and "client" data is written to the /var/log/messages file (it is up to the reader to write nice parsing code to populate individual mailboxes according the "RCPT TO:" field). The program is called with the following parameters:
bounce_rt -a 160.124.19.98 -p 25 196.xxx.115.250 25
In above case my IP is 160.124.19.98 (the attacker.com) and 196.xxx.115.250 is the victim. SMTP traffic is seamlessly translated from me to the victim - the only trace that the mail was intercepted is the mail header.
Things get more interesting where commerce sites are involved. Let us assume that my victim has an Internet banking site. I completely mirror the site, and point the DNS entry for the banking site to my IP number (where the mirror is running). The site is a mirror save for the backend system - the mirror replies with some kind of error, and the link to "please try again" is pointing to the actual IP number of the real site. Sure - what about SSL and server certificates you might say. And what about it? Do you REALLY think that people notice when a connection is not SSL-secured? Maybe 10% would - the rest would gladly enter their banking details on an open link. My "fake" site would farm a whole lot of interesting data before anyone would know the difference.
Another application for DNS hijacking would be abusing of trust relationships. Any service that makes use of DNS names for authentication can be tricked into allowing access to an attacker (provided that one also controls the reverse DNS entries). Here I am thinking of any TCP wrapped service, R-services and possibly even SSH.
How does one gain control over a primary DNS server? Maybe this is easier than you would expect. Why would we want to take over the DNS server if we can simply BE the primary DNS server? Remember when you registered your domain? You needed to provide a primary and secondary DNS server (now-a-days places like Register.com does that for you - but you still have the option to change it). And there is some mechanism for you to change that - right? (at Register.com is a username and a password) So - it would be possible for me to change it - by basically convincing the system (be that human or electronic) that I am you. And all of sudden a large portion of your IT infrastructure and security hinges on a single username and password.
Another attack (that has been successfully carried out in the field many times) is simple social engineering. Most corporates host their DNS service at an ISP. Why bother to set up a primary DNS server and change DNS entries on root servers if I can convince your ISP to make changes to your local DNS? How does your ISP identify you? A telephone call? A fax? E-mail? All of which can be spoofed. Even scarier. All of a sudden things move away from high technology and hyper secure servers and we are down to more "meat" things - and technology that was never intended to be used as security devices.
Attacking the DNS service itself by using exploits is also an option. Certain versions of the popular DNS service BIND for Unix have known exploits, and can be tricked into giving you a root account on the host. How to find vulnerable DNS servers? There is the quick way, and the proper way for bulk scanning. The quick way is to issue the command:
dig @ns.wasp.co.za version.bind chaos txt
would result in the output:
; <<>> DiG 8.3 <<>> @ns.wasp.co.za version.bind chaos txt
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; version.bind, type = TXT, class = CHAOS
;; ANSWER SECTION:
VERSION.BIND. 0S CHAOS TXT "8.2.2-P5"
;; Total query time: 592 msec
;; FROM: wips.sensepost.com to SERVER: ns.wasp.co.za 196.31.211.1
;; WHEN: Tue Sep 19 16:27:43 2000
;; MSG SIZE sent: 30 rcvd: 63
note the part that says [VERSION.BIND. 0S CHAOS TXT "8.2.2-P5"]. This tells us that ns.wasp.co.za is using BIND version 8.2.2-p5 - a safe version (at the time of writing :)) This method is a bit messy, but works fine if you quickly want to check some version. A better way is to use VLAD. The script in question is "dnsver.pl", a script that check the BIND version, and report if it is vulnerable or not:
> perl dnsver.pl -v ns.wasp.co.za
RAZOR BIND Scanner v1.0.1
By Robert Keyes (c) BindView Corporation
http://razor.bindview.com/tools/vlad/
Requires Net::DNS module from
http://cpan.valueclick.com/authors/id/M/MF/MFUHR/Net-DNS-0.12.tar.gz
Checking ns.wasp.co.za
Server Response: NOERROR
DNS Server Version: BIND 8.2.2-P5
The script only finds the BIND version, and as such is non-intrusive. Using
this script with multiple IP numbers are very simple. Put the IP you wish to
check for in a file (assuming the file is called /tmp/ips) Execute the
following script, piping its output to your results file:
#!/usr/local/bin/tcsh foreach a (`cat /tmp/ips`)
perl dnsver.pl -v $a
continue
end
By this time you should really be familiar with this type of script.