Date: Thu, 24 Jul 2008 23:41:45 +0300
From: "Troy Xyz" <fatpodesta@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: DNS spoofing issue. Thoughts on potential
	exploits

I am now posting some analysis I wrote on the subject right after my last
post.
Since the exploits are now available too, this should primarily be helpful
to the good guys.
I wrote this without full details of the exploit, but it shoud all be
pertinent nonetheless.
It might help in some cases where there are firewall issues.
I also propose a new solution. No response from ISC, so I don't know if they
disagree or what.
Anyway, this is my contribution. I hope it helps somebody.

Cheers.

-fatpodesta




Further notes:
1.
Using a dedicated nameserver for SMTP leaves the system susceptible to
attacks on
the mail system. To fix this too, the HELO checks must be removed from the
mail system
and moved to a separate HELO checking system (e.g. milter). The mail server
can then be
changed back to using the normal nameserver.

2. It should be noted that when resolvers and nameservers are configured to
use random source ports, both the firewall between the internal LAN and DMZ
and the firewall in between the DMZ and the Internet must allow for the
random ports.

3.
What is always required is a machine where the user has the ability to write
packets to the network with any IP. This usually means super user access.
It is difficult in most cases to send udp packets with forged IP since
routers will not accept them. That is why it is difficult to conduct an
attack against a random target.
In certain situations, however, faking IPs is possible.
The machine must also be somewhere in the path between the two networks,
Company A and SiteB, so that packets released on the network get routed to
the target IP (A or B).
This scenario is realized if the attacker has access to a machine on the
same LAN with Company A's nameservers.
If the nameservers are
(a) inside a DMZ (a LAN in between two firewalls, one to the company's
internal LAN and one to the Internet).
(b) on a company's internal LAN.
(c) on a LAN directly connected to the Internet.

In all scenarios, the attacker must get access to the LAN or in case (c) to
the ISP's LAN which connects Company A to the Internet.

The attacker can get access to the LAN in one of the following ways:
1. client virus (only works in scenario (b).
2. break-in to the server itself.
3. break-in to a machine on the same LAN.
4. If the server is in a virtualized environment, access to any kernel
running on the hardware, and configured to use the same LAN. This can happen
if the server is hosted on a service provider's virtualized machine.
5. break-in to the router/firewall which connects the nameservers to the
Internet.

Scenario 1 is feasible. The solution is to run servers inside a DMZ. Running
them on a LAN is just not smart. Environments where servers are not inside a
DMZ are inherently not secure because packets can be forged too easily.
Scenario 2 with root access makes it unnecessary to go through the hassle of
spoofing.
Scenario 3 is feasible.
Scenario 4 is feasible.
Scenario 5 is the only on in which case nothing works. If the attacker gets
access to the router/firewall, then even random ports will not help. This
scenario exposes servers to so many possible attacks that guarding against
them is seemingly impossible. I would have to say that this scenario should
be excluded from this discussion because not only DNS, but all protocols
which do not use cryptographic checks are vulnerable.

All environments where machines share a LAN so that sniffing packets is
possible from machines other than the sender/router/firewall/recipient pose
a security risk from all kinds of attacks. Networks should be designed so
that sniffing is not possible.

In addition, if networks connected to the nameserver allow packets with any
source address, then additional attack vectors become possible. Any DMZ
should only allow packets with internal network IPs from the internal
network, and others only from the Internet. If such strict checking is not
enabled, attacks against a server inside a DMZ become possible even from the
internal LAN.

Consequently, only scenarios 3 and 4 are worthy of contemplation in this
case.

In both cases, if the attacker is able to sniff traffic on the network, it
can always succesfully conduct the above mentioned attack, since it then
knows the ID, the IP and the port.

Randomizing the port works even when the attacker can sniff the network,
because there is no time for the attacker to do a DOS against the legitimate
nameservers.

If randomizing is not possible, servers should be protected against sniffing
by using hardware solutions which make it impossible. This should be done in
any case, since sniffing exposes traffic to analysis, which can expose other
vulnerabilities on the network. In the case of virtualized servers, if this
is not already done, then it should be.

Other apps which use udp could have similar problems. I would think that
only protocols which can be invoked by a remote user face similar risks.
Therefore the obvious udp using protocols such as RPC and NTP are excluded.


Attack against client resolvers:
A LAN attack works if the attack is conducted against individual client
machines. The attack makes client+resolver "A" and the caching nameserver
"B." In this case it is sufficient to get a virus in one client machine and
conduct attacks from there. There is no need to poison the cache on the
caching nameserver if all clients' caches can be poisoned. Poisoning the
nameserver cache is only possible if the firewall between the internal LAN
and the DMZ allows packets with external IPs to pass.
In terms of getting the client's resolver to make queries, the question is
how? Images on web pages can trigger a DNS query. Javascript, java and flash
can also be used to trigger DNS queries. Another potential way to trigger a
DNS query is if the client uses software which resolves IPs. Firewall
logging software might do this. This would only be a threat to the arpa
domain for resolving IPs, though. Javascript, java and flash pose a real
threat, since the client can be forced to query any list of hostnames.
An attack would need to coordinate the two attacks, so this seems a bit
complicated.


OTHER SOLUTIONS:
The randomized port solution essentially makes it more difficult for an
attacker to guess what data is sent by the resolver/nameserver in its query
packets. With only a 16 bit ID, there are 2^16 values to guess. With the
added ports, there are 2^32-1024 possibilities. It also makes a DOS
impossible.
The exactly same effect (except for the DOS) could be achieved by adding 2
bytes to the ID, or by using 2^16 random IPs to send the query. The random
IP solution is not practical. Adding more bits to the ID is feasible only
through modifications to the DNS protocol. Any changes would have to be
backwards compatible, so as not to break compatibility with unpatched
systems, or systems which use the random port solution.

Where to add the extra bits?
(a) use qdcount and ancount fields (both 16 bits) to send the extra ID bits.
A query has an unused ancount and a response has an unused qdcount, so these
are available.
(b) always send two questions (qdcount always >= 2). The second question
should be a for a random name. The response doesn't matter, as long as it
contains the random name.
(c) add RR (resource record) data with the extra bits. This is probably the
easiest one to implement, and is also what is used by DNSSEC. A new type
would need to be added, called DNSID or something of the kind.

Solutions (b) and (c) have the advantage that more than 16 bits of
randomness can be added, making guessing even harder.

The other benefit of random source ports is that a DOS against the
nameserver will not succeed. Using more random bits in the DNS packet will
still allow for the DOS.
A disadvantage of random source ports is that it adds burden to the network,
especially for large installations.
Another disadvantage of random ports is that if the attacker is able to
induce the attacked system to use many of its ports, with the information on
the ports available to the attacker (e.g. through sniffing or by forcing the
nameserver/resolver to query hosts whose DNS was under the attacker's
control), randomness is reduced. It should be fairly easy for an attacker to
force a large number of queries to its own nameservers within a short period
of time, thus reducing the available port range considerably. Also, most
systems (at least GNU/linux and windows) allow the user to limit the number
of ports available for outgoing connections. This will also reduce
randomness.
A third disadvantage of random ports is that large installations might have
difficulty with only 2^16-1024 available connections for all udp traffic.

A cryptographic solution such as DNSSEC would also solve the problem, since
faking responses wouldn't be possible. A DOS should still be possible even
with DNSSEC. The difficulty with DNSSEC is its slow implementation. DNSSEC
adds extra data to DNS packets, just as the above mentioned solution (adding
extra bits to the ID) does, and is also backwards compatible. The advantage
of the solution above is that it doesn't necessitate signing of DNS records,
and can thus be implemented through regular software updates.

A disadvantage of the above mentioned solution with extra bits of randomness
is political. Would it slow down the spread of DNSSEC? My speculation is
that it wouldn't, since it wouldn't diminish the additional benefits of
DNSSEC, which are, namely, integrity of records for owners of domains.
A more serious disadvantage is that both the authoritative nameserver and
the caching nameserver have to implement the solution against attacks from
the Internet. As a solution to maintain compatibility with unpatched
systems, caching nameservers could disable caching for responses where extra
ID bits are not included.
Attacks from the LAN do not suffer from this issue with the same acuteness,
since only the caching nameserver and clients need to be updated. Client
resolvers can be configured to disallow responses without the extra ID bits,
since they only use one nameserver for all their queries.

We can also conclude that the issue under discussion exposes a vulnerability
also in DNSSEC, since clients who make queries cannot know whether a
particular domain uses DNSSEC or not before they make a query. Thus, if an
attacker can DOS a caching namserver or an authoritative nameserver, he can
also send fake data to the client, who is none the wiser. If an external
mechanim is used to verify the existence of DNSSEC for a particular domain,
then spoofing wouldn't work. I am not familiar enough with the details of
DNSSEC implementations to say whether this is the case.

Using TCP will remove the possibility of a spoofing exploit. A DOS would
still be possible. A disadvantage of TCP is that it is heavier on networks
because if multiplies the number of packets sent.

The best solution in my mind would be to combine the information we have and
device a solution as follows: Add at least 16 bits to the ID. Send a normal
UDP query from a static port. Only allow several seconds for the nameserver
to respond. If a response is not received, wait and try again with a new ID.
Reject messages received after the window has passed. The key is to not
resend a query with the same ID. The second query uses TCP (which always
uses a random source port) or a random UDP port. This would solve the DOS
issue without adding burden to the network in most cases, since only one
source port and UDP would be used in normal situations. Since TCP would only
be used when a DOS is taking place, or during congestion, normal DNS related
packets wouldn't increase. Systems able to implement source port
randomization for UDP would be able to use UDP. Installations without source
port randomization for UDP would be able to use TCP. Adding bits to the dns
IDs will achieve better randomness without adding but a minimal amount of
burden to the network (using the qdcount and ancount variables, no burden is
added). Using random UDP source ports or TCP only on the second query will
reduce the burden on firewalls. All systems could protect themselves against
a DOS and against the spoofing exploit.

END

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