[dns-operations] DNS Attack over UDP fragmentation

[Haya Shulman]

You are right, proper randomisation is one property, and secure application
thereof to real world systems is another.
So, as you said, there are a number of requirements, which should be
addressed, to ensure correct functionality and security, including having a
sufficiently large range which the attacker cannot traverse efficiently,
and no collisions/duplications.
Using a pseudorandom permutation should satisfy both these requirements.
(Although generally, 2^16 does not constitute a sufficiently large range,
but, taking into account the (much smaller) defragmentation buffer at the
recepient, the result is an `artificially inflated` range of values). I
have not written a kernel based implemention of this design, so I am not
sure what impact such an implementation has on the efficiency and what its
overhead is on systems. But, it seems (again, requires testing) that it
should be affordable (and would prevent attacks against [RFC6056]).

Regarding [RFC6056]:  we showed (in papers that will soon appear at
ESORICS'13 and ACSAC'13) that the algorithms recommended in [RFC6056] are
vulnerable to prediction attacks by off-path attackers. We also showed that
some of the online DNS checkers (to best of my recollection we tested 5-6,
see details in papers), that were set up to enable clients to test
unpredictability of the port allocation that their systems support, report
the clients as secure to port prediction, while they are not.
Since DNS checkers may often be the only way for administrators to evaluate
security of their systems against off-path attackers, DNS checkers
constitute an important tool, and should report susceptibility to
vulnerabilities.

For instance, DNS-OARC does not detect port prediction attacks, and reports
clients as secure, while they are vulnerable to attacks. I contacted the
maintainers of DNS-OARC and notified them of this vulnerability last year,
and proposed a simple fix to the problem... but the system was not updated
and still reports vulnerable systems as secure, so relying on its feedback
may be risky.

GRC DNS checker, provided by Steve Gibson, exhibited high sensitivity to
all attacks against which we tested it, and I highly recommend it.
 [Notice, that we have not tested sensitivity of DNS checkers to all
attacks, but only against selected known attacks].
(For details and a complete list of DNS checkers we tested see paper).

To conclude, indeed, many systems (based on our inspection of CAIDA
captures and tests of the selected systems), deploy algorithms recommended
in [RFC6056]. We found a number of different techniques (e.g., exploiting
fragmentation, or interrupt driven scheduling) to derandomise ports on
clients' systems, which use algorithms from [RFC6056], and so it may be
best to patch since these works will be published in the upcoming months.
Today at ESORICS I will present fragmentation-based techniques for port
derandomisation against resolver-behind-upstream, which support algorithms
from [RFC6056] (even if the upstream supports truly random and secure port
allocation method).
So, we recommend using a PRP both for port allocation and IPID assignment,
and will be happy to collaborate and discuss implementation challenges.





On Mon, Sep 9, 2013 at 10:12 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr>wrote:

> On Fri, Sep 06, 2013 at 09:44:34PM +0300,
>  Haya Shulman <haya.shulman at gmail.com> wrote
>  a message of 232 lines which said:
>
> > We studied the IPID randomisation on the name servers (not the
> resolvers).
>
> Just a warning: it's IPID _unpredictability_ (for a blind attacker)
> which is important. Randomisation can be bad because it creates the
> risk of IPID duplication (see RFC 6274 but RFC 6056, while talking
> about a different field, may be interesting too).
>



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