[time-nuts] When NTP goes wrong...

[Neil Schroeder]

I would like to respond in a generic and sweeping way - having not read in
the detail Bob layed out for us required to fully analyze the situation -
to the notion that circuit level access or prior topological knowledge is
required to exploit this or any other spoofing attack.  On a corporation or
education network, I could generate such malformed packets with almost no
effort as long as i had my Mac or a similarly not-windows device, or access
to one.  I estimate it'd take less than 5 minutes for me to do for the
majority of targets - which means any motivated party could within an hour
or two. I'm not warranting I would succeed - hopefully there would be a
real firewall SOMEWHERE in the path from the open internet to a real
physical host.

IP routers are, by design, completely disinterested in source information
and the additional overhead of becoming aware and meaningfully acting on it
is significant - hence multimillion dollar price tags on single linecards
in most Internet-scale devices.  Additionally, the amount of knowledge
required to effectively benefit from it while avoiding massive
architectural issues is frequently impractical if not to distribute to the
necessary infrastructure devices.

Long story short: this sort of processing is only practical at the
very.ingress interfaces to a network.  In the case of a Level 3 sized
carrier that would mean the number of interfaces that are not protected
from such a packet would number literally in the millions.  Level 3 is a
poor example of an vulnerable path - i would be hard pressed to circumvent
their security strategies due to effective onion-like layering - but
AT&T's?  No problem.  All I need is one host that is willing to play and is
on a segment without reverse path forwarding  - which is all of them, in my
experience.  Once i am past the first hop I can get the rest of the way
there.

The network should not *ever be the solution *to a host vulnerability.  It
can provide a break-fix level of response but as I believe it was PHK said
- the only effective mitigation strategy starts with a real firewall
followed by a very aggressively managed host.  The level of protection
offered by standard anti-spoofing ACLs or advanced RPF detection is merely
insurance.

Other effective strategies include NEVER allowing the internet to connect
directly to a host.  A simple reverse proxy or server load balancer
combined with a RFC 1918 numbering scheme on host networks is a VERY
powerful tool.  Such L4-7 inspection engines are just the ticket to foiling
an evil exploit.

NS



i Sun, Oct 25, 2015 at 2:01 PM Paul <tic-toc at bodosom.net> wrote:

> [This is my final contribution to this topic since real time-nuts using NTP
> run their own S1 servers driven by their Thunderbolts (et.seq.) and don't
> need to worry about this]
>
> On Sun, Oct 25, 2015 at 11:27 AM, Florian Teply <usenet at teply.info> wrote:
>
> > >
> > > >But if I read that article on ars technica correctly, it looks like
> > > >it is something inherent to the ntp protocol itself and the
> > > >definitions it makes.
> >
>
> Only loosely.  It might appear that RFC5095 admits certain attacks using
> the 'debug' interface however the 'source'* document says (referring to the
> 'nonce' check)
>
> "While it seems reasonable to expect this check to be performed on the KoD
> packet as well, RFC 5905 [41, Sec. 7.4] does not seem to explicitly require
> this."
>
> I believe this is an incorrect interpretation but in any case I think it's
> clear the RFC is ambiguous and the published "fix" is to explicitly
> validate the nonce.  Other fixes include completely disabling the 'debug'
> interface. Implicit in this is the need to update the NTPv4 RFC.
>
> I advise those concerned to read RFC5095, the BU paper* (don't worry about
> the 68 references) and check the NTP security notice** to draw your own
> conclusions about this problem keeping in mind Wojciech's recent comments.
>
> *http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf
> **http://support.ntp.org/bin/view/Main/SecurityNotice
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>