[dns-operations] DNS Attack over UDP fragmentation

[Haya Shulman]

On Sun, Sep 8, 2013 at 5:25 PM, Aaron Campbell <aaron at arbor.net> wrote:

> On 2013-09-06, at 3:44 PM, Haya Shulman <haya.shulman at gmail.com> wrote:
>
> > We studied the IPID randomisation on the name servers (not the
> resolvers). Only the name server side IPID randomisation is relevant to the
> attack, since it is the response from the name server that the attacker
> attempts to alter (by crafting a spoofed second fragment). IPID
> randomisation on the server, along with a smaller defragmentation buffer on
> the resolver, should suffice to make the attack impractical. The random
> suffix further raises the bar for the attacker.
>
> This is a good recommendation, but In practical terms, the trouble with
> randomizing the IPID is that this would require kernel-level patches (as
> opposed to just DNS server software upgrade), I believe.  This makes it
> somewhat harder to deploy.
>

Can you please extend? In particular, why is it more difficult (and how
much more difficult is it) to deploy by distributing a kernel patch?
Thanks.


> > Unmentioned variation: random-length suffix?  Instead of just
> randomizing the fictitious IP address, tack a random string on the front of
> the fictitious domain name.  The advantage is that, in addition to the
> checksum, you add IP and UDP length to the entropy (although these adjust
> in tandem, unfortunately).
> >
> > Do you mean to add a random `name` and not only `value` in the
> fictitious resource record? I think that this seems like a good idea.
> Thanks!
>
> Yes.
>
> > I would like to know if there is any merit to my earlier suggestion to
> Florian, namely, ignore glue records in large DNS responses, and have the
> recursors resolve dangling authority referrals using a separate (shorter)
> query.  The second request is a simple A or AAAA query for the first[*]
> nameserver listed in the original response.  The reply should contain the
> same authority and glue from the original response, but the data is more
> credible since the parameters of this query were not chosen by an untrusted
> stub.  The assumption is that this second response would not also be
> fragmented, although I suppose the recursor could drop the EDNS0 option to
> force TC=1 just in case (even though that would result in a 3rd
> transaction, ugh).
> >
> > Fragmentation can also occur in the `authority` section, e.g., similarly
> to our attack exploiting referral response from a parent domain. So, I am
> not sure how this can work, I think that this requires evaluation to
> confirm.
>
> It has since been mentioned on the thread that the countermeasure I
> described above is essentially what the "harden-referral-path" option
> implements in Unbound.  It would be interesting to re-test your attacks
> against Unbound with this option.
>

Ok, I have not tested this.

>
> -Aaron
>
>


-- 
Best Regards,
S.H.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130910/d733bcad/attachment.html>