[dns-operations] DNS Attack over UDP fragmentation

[Haya Shulman]

Hello Aaron,

Please see below.


On Fri, Sep 6, 2013 at 7:33 AM, Aaron Campbell <aaron at arbor.net> wrote:

> On 2013-09-05, at 10:02 PM, Haya Shulman <haya.shulman at gmail.com> wrote:
>
> > I would recommend short term patched (that we recommend in the paper) in
> the meanwhile, and addressing the deployment challenges of DNSSEC.
>
> Some comments on these recommendations.  Based on the caveats documented
> by Google, I'm not sure the random prefix defenses would be recommended for
> general deployment, see link:
>

You are right, these are certainly obstacles to deployment of such a
countermeasure. We also mentioned in that paper, that there is no perfect
solution, that would prevent all the attacks, but adoption of additional
randomisation (in second fragment) along with reduction of IP
defragmentation buffer, would make the attacks by off-path adversaries very
difficult to launch.

>
> https://developers.google.com/speed/public-dns/docs/security#add_entropy
>
> i.e., blacklist management.  I also speculate that this will become even
> weirder with the new gTLD rollout.
>
> The random suffix defense makes sense, except then the attacker just has
> to repeat the attack for different checksums.  Based on your research, only
> 1% of resolvers actually randomize the IP-ID, so it provides marginal
> entropy at best (side note, OpenBSD has been randomizing IP-ID for eons, I
> think even since the 90's-- http://www.openbsd.org/crypto.html#prng).
>

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.


> 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!

>
> 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.

Thanks.

 -Aaron
>
> [*] It is important to use the first namserver, since this is the one most
> likely to be contained in the first fragment (we have to consider that an
> attacker could corrupt the authority RRs, not just the additional glue RRs).




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