1 / 40

A Security Analysis of Version 2 of the Network Time Protocol NTP Matt Bishop

A Security Analysis of Version 2 of the Network Time Protocol NTP Matt Bishop. Presented by Alexander Gorman. Goal of Paper. Examine the security requirements of the Network Time Protocol (version 2) Determine if version 2 meets requirements Suggest Improvements. My Goals.

talen
Download Presentation

A Security Analysis of Version 2 of the Network Time Protocol NTP Matt Bishop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Security Analysis of Version 2 of the Network Time Protocol NTPMatt Bishop Presented by Alexander Gorman

  2. Goal of Paper • Examine the security requirements of the Network Time Protocol (version 2) • Determine if version 2 meets requirements • Suggest Improvements

  3. My Goals • Describe version 2 of NTP • Analyze attacks • Improvements

  4. Attacks • Masquerade • Modification • Replay • DoS • Delay

  5. Assumptions • Messages leave source uncorrupted • Not altered on arrival • Focus on transmission

  6. NTP • NTP = Network Time Protocol • Primary time servers • Secondary time servers • Stratum Number • Measure distance from primary to secondary time server

  7. NTP Top level stratum Primary Level 2 stratum B A Level 3 Stratum C

  8. NTP Rules • Primary time servers synchronized by external system • Secondary time servers synchronized by: • Primary time server • Another secondary time server with lower stratum number

  9. Association Modes Non-Server sync with NTP Server • Client • What time is it? • Send msgs to peers • Server • Created when received client msg • Responds with server’s time, terminates • Broadcast • Sends periodic time messages

  10. Association Modes Time Server sync with other Time Servers • Symmetric active • Broadcast sync msgs • Symmetric passive • If sender strata > receiver, reply + terminate • Else, sender syncs host and receiver responds with time msg of its own. Note: Normally servers with high strata run in active mode

  11. Smooth Data • Improve accuracy Algorithm 1 • Compute roundtrip delay and offset • Take sample from last 8 msgs • Choose lowest delay and use associated offset as estimated clock offset • Estimate sample dispersion

  12. Offset and Delay ti-3 ti-2 Local Server Remote Server ti-1 ti Ci = ((ti-2 - ti-3) + (ti-1 – ti)) / 2 Di = (ti – ti-3) + (ti-1 – ti-2)

  13. Selection of Source Peer • Algorithm 2 • Who should sync clock? • Uses Algorithm 1 • List is sorted and scanned repeatedly • Clock dispersion relative to peer is computed • Highest dispersion eliminated • Only one source left

  14. Receive and Packet Procedures • When a msg (packet) is received either • Error: packet discarded, association deleted • Packet Procedure

  15. Packet Procedures if (time packet transmitted=time last received packet transmitted) then sanity := true; if (time peer received last packet from host<>time last message sent to peer) then sanity := true; (*update association variables in Figure 3*) if (peer clock not synchronized) or (peer clock not updated for 1 day) then sanity := true; if (not authenticated correctly) then sanity := true; if (peer not preconfigured) and (packet’s stratum>peer’s stratum) then sanity := true; if sanity then (*discard message and exit*) if (packet originate timestamp= 0) or (time last message received by peer= 0) then (*exit; note sanity flag not set*) (*compute delay, offset, corrections, update local clock*)

  16. Packet Procedures • Check • Eliminate re-transmitted packets • Packet not transmitted at the same time as the last one received from that peer • Ensure messages are received in order • The last packet received from the local host was indeed the one the local host sent to the peer • Peer clock is synchronized correctly • Packet is authenticated correctly • Packet is preconfigured correctly and • Packet’s stratum level > peer’s stratum level FAIL

  17. Packet Procedure • If successful • Resets internal variables • Adjusts local clock if necessary • Possibly select new peer as clock source

  18. Security Mechanisms • Delay Compensation • Access Control • Authentication

  19. Delay Compensation • Compensate for network delays • Algorithm calculates roundtrip delay and clock offset relative to peer • Applies statistical procedure to update clock (see book Network Time Protocol (Version 2) Specification and Implementation)

  20. Access Control • All hosts partitioned into 3 groups • Trusted • Allowed to synchronize the local clock • Either preconfigured or based on trusted ticket service (Kerberos) • Friendly • Sent NTP msgs and timestamps when needed • Cannot change local clock • Others • Messages from this group are ignored

  21. Authentication • Covers Authentication and integrity • Packet in authenticated mode • Transmitted • NTP packet (except for authenticator) is checksummed using active peer’s key • Key depends on mode

  22. Authentication if peer.config = 0 then if(authenticator in message data) then peer.authenable := 1 else peer.authenable := 0; if peer.authenable =1 then begin peer.authentic := 0; if (authenticator in message data) then begin peer.keyid := packet.keyid; compute_mac(mac, peer.keyid, packet); if peer.keyid <> 0 and mac = packet.check then peer.authentic := 1; end; end; (*if peer.authenable is 0, authentication is not done;*) (*otherwise if peer.authentic is 0, the integrity of the *) (*packet’s contents are suspect*)

  23. Authentication • Packet Received • If msg contains authentication info • Index # of peer’s key reset to that in packet • Checksum recomputed and compared to transmitted checksum • If checksums match check succeeds • If packet has no authentication info • Check fails, routine exits

  24. Analysis of Security • Analyze the following: • Access Control • Authentication

  25. Access Control • Relies completely on an unauthenticated source address (in the absence of an integrity checking mechanism) • Solution: routing info • IP record route

  26. Authentication • Key index can be altered • Check is only 64bits • No key distribution mechanism defined • Keys used on a per host basis • Could lead to a compromise of all hosts that peer synchronizes

  27. Attacks • Goal • Attack • Effect • Countermeasure

  28. Masquerade • Goal • Convince timekeeper that attacker is authorized to synchronize it • Attack • Send a victim packets with source address of timekeeper • Effects • If host is known • None if change is drastic • Drift created if timestamps changed gradually • Unknown host • Compromise server by sending 8 uninterrupted messages • Send msgs claiming low stratum number • Countermeasure • Use authentication • Do not allow non-preconfigured peer to become clock source

  29. Message Modification • Goal • Alter msgs from one timekeeper to another to cause incorrect synchronization • Attack • Alter packets sent to victim • Different types of attacks

  30. Modification Attacks • Integrity the recipient’s clock • pkt.rec, pkt.xmt, pkt.precision • Change round trip delay

  31. Modification Attack

  32. Modification • Countermeasures • Use Authentication! • Stratum level used only if checks pass • Access controls indicate if connection is trusted

  33. Replay • Goal • Intercept + resend NTP msgs to cause recipient to incorrectly resynchronize • Disable active association • Attack • Record msgs + replay them later • Effects • Alternate and replay • Reset local clock to earlier time • Counter • Reject any msg with a timestamp older last msg received • Create a special msg when clock needs to be changed backwards • Route based

  34. Delay • Goal • Cause incorrect resynchronization • Disable active association • Attack • Artificially increase the roundtrip delay of an association • Effects • Delay packets in sample • Peer sending packets not source • Results in having no source, DoS • Counter • Redundancy of clock sources

  35. DoS • Goal • Prevent NTP msgs from one timekeeper to another • Attack • Prevent packets from clock sources from reaching an NTP host • Effects • Forces NTP to run under its own clock, high drift! • Counter • Redundancy of clock sources

  36. Combined Attack • Very effective • E.g. Deny a secondary server from all but one source, and delay packets from source • To counter, deal with each component attack separately

  37. Suggestions • Internal Mechanisms • Assume no underlying security mechanism • Always use Authentication • Keys used per-path not per-host • Base Access Control on recorded routes • Change variables after packet passes checks • Further restrict values of variables • Increase sample size • Require special packet to set clock backwards • Redundancy, server should have many sources

  38. Suggestions • External • Secure transmission • Run into problems with this scheme • Public-key checksum - Too slow! • IP does not provide sufficient security • Strict source does not work!

  39. Conclusion • NTP has some weaknesses, but well designed • Remember, security analyst’s view • May or may not impact goals of protocol

  40. Questions?

More Related