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

of 40 /40
A Security Analysis A Security Analysis of Version 2 of the of Version 2 of the Network Time Protocol Network Time Protocol NTP NTP Matt Bishop Matt Bishop Presented by Alexander Gorman Presented by Alexander Gorman

Embed Size (px)


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. - PowerPoint PPT Presentation

Transcript of 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 BishopPresented by Alexander Gorman

  • Goal of PaperExamine the security requirements of the Network Time Protocol (version 2)Determine if version 2 meets requirementsSuggest Improvements

  • My GoalsDescribe version 2 of NTPAnalyze attacksImprovements

  • AttacksMasqueradeModificationReplayDoSDelay

  • AssumptionsMessages leave source uncorruptedNot altered on arrivalFocus on transmission

  • NTPNTP = Network Time ProtocolPrimary time serversSecondary time serversStratum NumberMeasure distance from primary to secondary time server

  • NTPABCTop level stratumLevel 2 stratumLevel 3 StratumPrimary

  • NTP RulesPrimary time servers synchronized by external systemSecondary time servers synchronized by:Primary time serverAnother secondary time server with lower stratum number

  • Association ModesNon-Server sync with NTP ServerClientWhat time is it?Send msgs to peersServerCreated when received client msgResponds with servers time, terminatesBroadcastSends periodic time messages

  • Association ModesTime Server sync with other Time ServersSymmetric activeBroadcast sync msgsSymmetric passiveIf sender strata > receiver, reply + terminateElse, sender syncs host and receiver responds with time msg of its own.

    Note: Normally servers with high strata run in active mode

  • Smooth DataImprove accuracy

    Algorithm 1Compute roundtrip delay and offsetTake sample from last 8 msgsChoose lowest delay and use associated offset as estimated clock offsetEstimate sample dispersion

  • Offset and Delayti-3titi-2ti-1Ci = ((ti-2 - ti-3) + (ti-1 ti)) / 2Di = (ti ti-3) + (ti-1 ti-2)

  • Selection of Source PeerAlgorithm 2Who should sync clock?Uses Algorithm 1 List is sorted and scanned repeatedlyClock dispersion relative to peer is computedHighest dispersion eliminatedOnly one source left

  • Receive and Packet ProceduresWhen a msg (packet) is received eitherError: packet discarded, association deletedPacket Procedure

  • Packet Proceduresif (time packet transmitted=time last received packet transmitted) thensanity := true;if (time peer received last packet from hosttime last message sent to peer) thensanity := true;(*update association variables in Figure 3*)if (peer clock not synchronized) or (peer clock not updated for 1 day) thensanity := true;if (not authenticated correctly) thensanity := true;if (peer not preconfigured) and (packets stratum>peers stratum) thensanity := 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*)

  • Packet ProceduresCheckEliminate re-transmitted packetsPacket not transmitted at the same time as the last one received from that peerEnsure messages are received in orderThe last packet received from the local host was indeed the one the local host sent to the peerPeer clock is synchronized correctlyPacket is authenticated correctlyPacket is preconfigured correctly andPackets stratum level > peers stratum level FAIL

  • Packet ProcedureIf successfulResets internal variablesAdjusts local clock if necessaryPossibly select new peer as clock source

  • Security MechanismsDelay CompensationAccess ControlAuthentication

  • Delay CompensationCompensate for network delaysAlgorithm calculates roundtrip delay and clock offset relative to peerApplies statistical procedure to update clock (see book Network Time Protocol (Version 2) Specification and Implementation)

  • Access ControlAll hosts partitioned into 3 groupsTrustedAllowed to synchronize the local clockEither preconfigured or based on trusted ticket service (Kerberos)FriendlySent NTP msgs and timestamps when neededCannot change local clockOthersMessages from this group are ignored

  • AuthenticationCovers Authentication and integrityPacket in authenticated modeTransmittedNTP packet (except for authenticator) is checksummed using active peers keyKey depends on mode

  • Authenticationif peer.config = 0 thenif(authenticator in message data) thenpeer.authenable := 1elsepeer.authenable := 0;if peer.authenable =1 then beginpeer.authentic := 0;if (authenticator in message data) then beginpeer.keyid := packet.keyid;compute_mac(mac, peer.keyid, packet);if peer.keyid 0 and mac = packet.check thenpeer.authentic := 1;end;end;(*if peer.authenable is 0, authentication is not done;*)(*otherwise if peer.authentic is 0, the integrity of the *)(*packets contents are suspect*)

  • AuthenticationPacket ReceivedIf msg contains authentication infoIndex # of peers key reset to that in packetChecksum recomputed and compared to transmitted checksumIf checksums match check succeedsIf packet has no authentication infoCheck fails, routine exits

  • Analysis of SecurityAnalyze the following:Access ControlAuthentication

  • Access ControlRelies completely on an unauthenticated source address (in the absence of an integrity checking mechanism)Solution: routing infoIP record route

  • AuthenticationKey index can be alteredCheck is only 64bitsNo key distribution mechanism definedKeys used on a per host basisCould lead to a compromise of all hosts that peer synchronizes

  • AttacksGoalAttackEffectCountermeasure

  • MasqueradeGoalConvince timekeeper that attacker is authorized to synchronize itAttackSend a victim packets with source address of timekeeperEffectsIf host is knownNone if change is drasticDrift created if timestamps changed graduallyUnknown hostCompromise server by sending 8 uninterrupted messagesSend msgs claiming low stratum numberCountermeasureUse authenticationDo not allow non-preconfigured peer to become clock source

  • Message ModificationGoalAlter msgs from one timekeeper to another to cause incorrect synchronizationAttackAlter packets sent to victimDifferent types of attacks

  • Modification AttacksIntegrity the recipients clockpkt.rec, pkt.xmt, pkt.precisionChange round trip delay

  • Modification Attack

  • ModificationCountermeasuresUse Authentication!Stratum level used only if checks passAccess controls indicate if connection is trusted

  • ReplayGoalIntercept + resend NTP msgs to cause recipient to incorrectly resynchronizeDisable active associationAttackRecord msgs + replay them laterEffectsAlternate and replayReset local clock to earlier timeCounterReject any msg with a timestamp older last msg receivedCreate a special msg when clock needs to be changed backwardsRoute based

  • DelayGoalCause incorrect resynchronizationDisable active associationAttackArtificially increase the roundtrip delay of an associationEffectsDelay packets in samplePeer sending packets not sourceResults in having no source, DoSCounterRedundancy of clock sources

  • DoSGoalPrevent NTP msgs from one timekeeper to anotherAttackPrevent packets from clock sources from reaching an NTP hostEffectsForces NTP to run under its own clock, high drift!CounterRedundancy of clock sources

  • Combined AttackVery effectiveE.g. Deny a secondary server from all but one source, and delay packets from source To counter, deal with each component attack separately

  • SuggestionsInternal MechanismsAssume no underlying security mechanismAlways use AuthenticationKeys used per-path not per-hostBase Access Control on recorded routesChange variables after packet passes checksFurther restrict values of variablesIncrease sample sizeRequire special packet to set clock backwardsRedundancy, server should have many sources

  • SuggestionsExternalSecure transmissionRun into problems with this schemePublic-key checksum - Too slow!IP does not provide sufficient securityStrict source does not work!

  • ConclusionNTP has some weaknesses, but well designed

    Remember, security analysts viewMay or may not impact goals of protocol

  • Questions?

    Page 2Page 2Page 2End page 2 + 3Page 3Association is an instantiation of the protocol machinea stratum n server is at a higher stratum than a stratum n-1 server If a peer sends a "symmetric active" packet, it is willing to modify the NTP server's time Draw picture on top of page 5 for class?A measure, in seconds, of how scattered the time offsets have been from a given time server.slideRecord two packets from the peer then rapidly alternate and replay