Attacking networks using DHCP, DNS - probably kills DNSSEC

Bill Stewart bill.stewart at pobox.com
Sun Jun 29 17:19:51 EDT 2003


At 11:15 PM 06/28/2003 -0400, Steven M. Bellovin wrote:
>In message <5.1.1.6.2.20030628124252.033e5600 at idiom.com>, Bill Stewart writes:
> >This looks like it has the ability to work around DNSSEC.
> >Somebody trying to verify that they'd correctly reached yahoo.com
> >would instead verify that they'd correctly reached
> >yahoo.com.attackersdomain.com, which can provide all the signatures
> >it needs to make this convincing.
> >
> >So if you're depending on DNSSEC to secure your IPSEC connection,
> >do make sure your DNS server doesn't have a suffix of echelon.nsa.gov...
>
>No, that's just not true of DNSsec.  DNSsec doesn't depend on the
>integrity of the connection to your DNS server;
>rather, the RRsets are digitally signed.
>In other words, it works a lot like certificates,
>with a trust chain going back to a magic root key.

I thought about that, and I think this is an exception,
because this attack tricks your machine into using the
trust chain yahoo.com.attackersdomain.com., which it controls,
instead of the trust chain yahoo.com., which DNSSEC protects adequately.
So you're getting a trustable answer to the wrong query.

I'm less sure of the implementation issues of the
"Connection-specific DNS suffix", and I've seen conflicting documentation.
If the resolver looks up "domain.suffix" before "domain",
then the attacker's DNS doesn't need to control the DNS access,
and only needs to provide the attacker's certificates,
but if the resolver looks up "domain" before "domain.suffix",
then the attacker also needs to make sure that the lookup of "domain" fails,
which is most easily done by telling the DHCP client to use
the attacker's DNS server along with telling it the suffix.
(That doesn't add any extra work to the attack, but does make it
a bit easier to trace the attacker after the fact;
if you're not replacing the attacker's DNS server entry,
then all you need is a legitimate-looking server for
"*.attackersdomain.com".  In either case, somebody who can
pull off this kind of an attack probably uses a compromised machine
to run the DNS server on anyway.)

>I'm not saying that
>there can't be problems with that model, but compromised DNS servers
>(and poisoned DNS caches) are among the major threat models it was
>designed to deal with.  If nothing else, the existence of caching DNS
>servers, which are not authoritative for the information they hand out,
>makes a transmission-based solution pretty useless.

DNSSEC seems to do a pretty thorough job of making sure that
if you look up the correct domain name, you'll get the correct answer,
in spite of attackers trying to prevent it.
But this attack tricks you into looking up the wrong domain name,
and DNSSEC makes sure that you get the correct answer for the wrong name,
which isn't the result you want.






---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list