Message-ID: <5e248f580807170859s1636aecct71b637bad6ba76bd@mail.gmail.com>
Date: Thu, 17 Jul 2008 18:59:07 +0300
From: "Troy Xyz" <fatpodesta@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: DNS spoofing issue. Thoughts on potential exploits

Hi,

I am troubled by these kinds of solutions which only help administrators
with standard distributions. Any kind of deviation from the norm, and it
will
be impossible to fix one's servers, or assess possible vulnerabilities.

I wanted to understand how someone could exploit this flaw against systems I
deal with, so I wrote some scenarios on how DNS could be exploited in
general. I believe the exploit, which is now unpublished, will probably be
something along the lines below. Of course I could be wrong. These are just
my thoughts.

First we have to understand the variables involved. They are:
-Client+resolver.
-Caching name server used by client.
-Authoritative name server for a domain.

As far as I know, the attack enables an attacker to cause false DNS data to
be served to clients. This implies that clients are affected because they
can be misled to fake sites. It also implies that domains can be compromised
because e.g. mail directed at them doesn't arrive, but is directed to an
attacker's site. This would only apply to specific clients, of course, but
creates a serious problem if one really thinks about it.

Here are my thoughts:

Possible attack vector No. 1:
1. EvilIP wants to redirect traffic from Company A, intended for SiteB, to
   EvilSiteX.
2. EvilIP sends a large number of queries to SiteB's nameservers, using
Company A's nameserver
   IP and port (i), making the packets look as valid as possible, with
random IDs and the port
   used by Company A's nameserver for outgoing queries (ii).
3. EvilIP connects to Company A's caching nameserver, and queries for
SiteB's DNS info (iii).
4. Company A's nameserver sends a query to SiteB's nameserver.
5. SiteB's nameserver doesn't respond to Company A's nameservers' requests,
as
   it considers them to be a DOS attack. All queries appear to come from the
same IP
   and port, using various valid IDs.
6. EvilIP can now iterate through the ID address space of valid IDs, sending
responses to
   Company A's nameservers, using SiteB's nameservers' IP in the udp packet.
The port
   number (53) is inconsequential, since Company A's nameservers have no
information on it.
7. One of the packets matches the ID of the query and is accepted by Company
A's nameserver.
   The result is stored in cache.
8. Future queries made by clients using Company A's nameservers will receive
the
   entry sent by EvilIP.

(i) We assume Company A has one nameserver for simplicity's sake. The same
method can
    be used for multiple nameservers.

(ii) EvilIP can find out the outgoing IP used by Company A's nameservers by
making
     them send queries to a nameserver which is controlled by EvilIP.
Information on
     the IDs can also be gathered this way.

(iii) Step 3 can be achieved by connecting to Company A's SMTP server, and
using
      Site B as HELO. Unless the SMTP server is using a dedicated
nameserver, it
      will query Company A's nameservers.


Possible attack vector No. 2:
An attack can also be done against the resolver. This involves a DOS between
the client and
the caching nameserver. Otherwise the attack is the same.


Solutions:

Randomizing ports:
If the caching nameserver randomizes its source port, EvilIP will not be
able to
create a DOS because SiteB's nameservers will only consider invalid queries
to be those
on ID/port pairs with too much traffic. The DOS attack might still work if
EvilIP is able to
flood all possible IP/port pairs. This depends on the amount of the time
SiteB's nameservers refuse to accept packets from Company A's nameservers.
If the window is too long, EvilIP is able
to flood all of them. This still leaves the issue that EvilIP will also have
to send
packets to all ports on Company A's nameservers. Since there are {possible
IDs} * {possible
ports} possibilities, a practical attack is made unfeasible.

If there is a firewall in between the Internet and the caching nameserver,
it must be
made sure that incoming traffic to UDP ports 1024 and above are allowed. If
NAT is used,
it must be made sure that it doesn't alter the source port of UDP packets.
If it does,
those ports must be randomized as well.

Port randomization in NAT can also replace it in the name server.


Without random ports:
A. If randomizing ports is not feasible either at NAT or nameserver level,
the caching nameserver should not be exposed to clients outside the LAN. An
SMTP server should be configured to use a dedicated DNS server, or one which
does port randomization. This approach still leaves the caching nameserver
vulnerable to attacks from the LAN. This can occur if one of the clients on
the network is compromized (virus etc.).

B. If TCP is used, an attack of this type is not possible.


-fatpodesta

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists