[dns-operations] summary of recent vulnerabilities in DNS security.

[Haya Shulman]

On Tue, Oct 22, 2013 at 11:15 PM, Paul Vixie <paul at redbarn.org> wrote:

> Haya Shulman wrote:
>
>
>
>>  > > so if i add "first weaponized by Haya Shulman" this would settle the
>> > > matter?
>> >
>> > Thank you, can you please use Amir Herzberg and Haya Shulman (I
>> > collaborated on this attack together with my phd advisor Amir Herzberg).
>>
>> it shall be done.
>>
>
> Thank you.
>
>
> upon deeper consideration, "weaponized" is the wrong verb, unless you have
> released your software. i can say "first published" if that will serve your
> purpose.
>
>
>
I have implemented the code of the attack which I ran in a lab setting
against Bind and Unbound, but it can't be released, since (1) it is an
attack and (2) it is not automated (I adjust it manually against each
target domain, and resolver, and response type, e.g., NXDOMAIN, referral or
answer).
In any case, `first published` is fine. Can you please cite the conference
version (i.e., IEEE Conference on Communications and Network Security (CNS)
2013).
Thank you.

  Eastlake cookies is a very neat proposal. In contrast to other
> challenge-response mechanisms, which reuse existing fields for security
> (while those fields were originally designed for a different purpose),
> e.g., source ports, Eastlake's proposal uses the EDNS to add randomness in
> order to authenticate communication between resolver and name server. So,
> you are right, it does prevent many attacks, but, it does not prevent all
> the attacks, particularly those that exploit fragmentation. For instance:
>
> 1. what about an IP packet that is fragmented into three fragments, such
> that the EDNS OPT RR is in the third fragment? By replacing the second
> fragment, the attacker can inject malicious content.
>
> 2. another example also involves IP fragmentation, however in this
> scenario the second fragment can be of any size, e.g., a single byte. The
> attacker overwrites the transport layer port of the first fragment, e.g.,
> to its own port and intercepts the packet (along with the cookie); replaces
> the DNS records and forwards the resulting response to the resolver.
>
> Both tricky but feasible.
> Correct me if I am wrong, but I think that the cookies would not prevent
> these (above) attacks.
>
>
> i can't tell whether you're wrong, there's not enough detail here. if
> you're able to replace the middle fragment, or perhaps replace all
> fragments except the last one, then only SIG(0) or TSIG or DNSSEC could
> stop you. however, my back of envelope estimate is that replacing the
> middle fragment with one the same size but different content is more than
> just "tricky", and replacing all-but-the-last fragment would require many
> hours at 100MBit/sec, which to me places it out of consideration as an
> attack worth defending against.
>


You are right that cryptographic defenses, e.g., DNSSEC, prevent the
attack.

Sorry for the brief description earlier, fyi, a slightly more elaborate
design:
The idea is to replace a single middle fragment, e.g., given n fragments,
for n>2, we replace some fragment, s.t., 1< i < n.
Assume n=3 (and also assume, for simplicity, that fragments arrive in order
- adjusting for the general case is straightforward).
I want to replace fragment i=2 with a spoofed 2nd fragment.  The challenge
is to place the spoofed 2nd fragment in IP defragmentation cache, such that
it is (1) reassembled with the first fragment, but, (2) not overwritten by
the 2nd legitimate fragment. If the attacker plants a spoofed second
fragment in a defragmentation cache, it will be reassembled with the 1st
authentic, but then will be overwritten by the legitimate 2nd fragment that
will subsequently arrive. To ensure that the spoofed second fragment is not
overwritten (by the 2nd legitimate fragment), we should set its offset to
some lower value (i.e., this results in a gap - that has to be filled - in
the resulting reassembled packet). Then when the 3rd (authentic) fragment
arrives, it is further reassembled with them (1st and spoofed 2nd). What
remains to do, is to fill the missing gap in 2nd fragment.
So, to launch this, the attacker has to send two fragments: a spoofed 2nd
fragment (which offset is lower than the offset of the authentic second
fragment) before (or right after) triggering the DNS request, and after the
thre fragments (authentic 1st, 3rd and spoofed 2nd) are reassembled a small
fragment is sent to fill the missing bytes (in the spoofed 2nd fragment).
Then the packet is ready to leave the IP defragmentation cache.

So, you are right that it is more involved, but, if the fragmentation
occurs at the same boundary, then it is doable. Just to clarify, when I say
that there is a vulnerability, I mean, that it can be exploited in
practice. As you (and others on this mailing list) mentioned, something
that can be done will not necessarily be exploited, e.g., if it is too
complex and the gain is not significant.

The second example is an extension of the description above.


> i believe that mark andrews of ISC is going to re-release eastlake
> cookies. i expect that in consideration of your fragmentation work, he will
> add a 32-bit CRC covering the full message to the EDNS option that contains
> the cookie. since the cookies method is something we need anyway (for DDoS
> prevention), we ought to depend on it to solve for fragmentation as well.
>
>
Is that CRC based on a cryptographic function? or is it similar to, e.g.,
UDP checksum?



>
>
>
>> > I absolutely agree with you, deploying DNSSEC on the end hosts would be
>> > ideal for security.
>>
>> wait, wait, that's not what i said. i said recursive dns should be
>> on-premise
>> or on-host, not wide-area. i said nothing about end to end dnssec. what
>> are
>> you specifically agreeing with?
>>
>
> Yes you are right, I agree with you that it is best to validate on
> recursive resolver on-premise.
>
>
> that is, again, not what i said. i want recursion, iteration, and caching
> to occur on-premise or if necessary on-host. i will want this even in the
> absence of globally deployed dnssec. i will also want on-premise or if
> necessary on-host validation where possible, but that's not what i was
> saying in the text you quoted.
>
> Ok, understood.

>
>    But, I also wanted to add, that I think best to validate on the end
> host; this would also prevent attacks by attackers that are on the same
> network with the client, e.g., wireless networks or networks of ISPs.
>
>
> that's a controversial topic, as i expect followups to this thread to
> demonstrate. i won't address it here.
>
>
>
>> > I think I may have been misinterpreted. I believe cryptography is
>> important
>> > and efforts should be invested in deployment of DNSSEC. One of the
>> goals of
>> > our work on DNS was to motivate adoption of DNSSEC.
>>
>> that's great to hear.
>>
>
> a side by side reading of your earlier draft (
> http://arxiv.org/pdf/1205.4011.pdf) and your current draft:
>
>
> https://0a94266f-a-62cb3a1a-s-sites.googlegroups.com/site/hayashulman/files/fragmentation-poisoning.pdf?attachauth=ANoY7cpB1yJsBXMWL0_spxDjUMV9m5G_TjI98UgJE6OtoP98H-WrlRJ2AyJVhajdZ5za2vjZ14twuMHuB7NUcRW_EYv36scybuofLgPOwoU2Rvs7zpSnm_Qj3jA3noSc3ibX9b9_7tncZJdGca0FLY8SOrzMTY_O5bd0NPcwBXtDx9vtCjbRisMFf48MiOYFNO-66BY3iyGa584pJ0Sy2vYfI5ZKKCmvJhJsmY96N4XChK5cGgky8eg%3D&attredirects=0
>
> ...shows a remarkably different attitude toward dnssec. what led to your
> reconsideration?
>
>
Your observation is correct. Initially it seemed that large responses were
a consequence of DNSSEC. But, then we found other techniques to cause
fragmentation, not related to DNSSEC, like spoofed ICMP fragmentation
needed (reduces the MTU beyond 1.5KB - and removes the requirement of large
responses), and malicious domains (created by the attacker), with large
responses. This made it clear that the attacks were not an artifact of
DNSSEC.

On the other hand, DNSSEC prevents these (and other known and future,
unforeseen) attacks against DNS.

I also found it very easy to deploy DNSSEC on resolvers, and zones. Many
people invested a lot of efforts in it, and there are a number of elaborate
tutorials available online, and automatic scripts (e.g., keys generation,
automatic zone signing procedures).

I faced some challenges related to interoperability, e.g., the network that
we ran the attacks on, blocks fragments (in the FW), and we had to
explicitly ask to allow fragments to our resolver host.
 Of course, these (and/or other) challenges are not specifically an issue
of DNSSEC, but a general challenge of deploying new mechanisms in the
Internet.



 vixie
>



-- 

Best Regards,

Haya Shulman

Technische Universität Darmstadt

FB Informatik/EC SPRIDE

Mornewegstr. 30

64293 Darmstadt

Tel. +49 6151 16-75540

www.ec-spride.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131023/2cab7b45/attachment.html>