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

[Bob Camp]

Hi

Well here’s one of their points in “Attacking The Network Time Protocol":

They start off in the paper proposing the a KoD packet can be easily 
used to disconnect NTP from it’s upstream time sources. Thus forging 
KoD’s would appear to be the first step in their proposed attack. 

Can you forge them - sure. 

It would *seem* that things like polling rates are going to get into 
the mix pretty fast. If I have an artificially high poling rate set up, it’s going 
to be easier than if the rate has backed off to some slow rate. It also 
will be easier to fake if I’m not doing some sort of burst (multi query) 
check on the server(s). 

So a question - how does all this impact your ability to do a faking prices? 
Will you be flooding me with so many fake replies that a fairly simple patch 
will spot what you are doing?

No, this isn’t the whole key to the whole thing. It’s just one of a big bundle of
things that need to be gone through. 

Bob


> On Oct 25, 2015, at 3:24 PM, Neil Schroeder <gigneil at gmail.com> wrote:
> 
> 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.
>> 
> _______________________________________________
> 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.