Transcript A Security Analysis of Version 2 of the Network Time Protocol NTP

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
Describe version 2 of NTP
 Analyze attacks
 Improvements

Attacks
Masquerade
 Modification
 Replay
 DoS
 Delay

Assumptions
Messages leave source uncorrupted
 Not altered on arrival
 Focus on transmission

NTP
NTP = Network Time Protocol
 Primary time servers
 Secondary time servers
 Stratum Number

• Measure distance from primary to secondary
time server
NTP
Primary
A
Top level stratum
Level 2 stratum
B
Level 3 Stratum
C
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
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
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
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
Offset and Delay
ti-3
ti-2
ti-1
ti
Ci = ((ti-2 - ti-3) + (ti-1 – ti)) / 2
Di = (ti – ti-3) + (ti-1 – ti-2)
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
Receive and Packet Procedures

When a msg (packet) is received
either
• Error: packet discarded, association deleted
• Packet Procedure
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*)
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
Packet Procedure

If successful
• Resets internal variables
• Adjusts local clock if necessary
• Possibly select new peer as clock source
Security Mechanisms



Delay Compensation
Access Control
Authentication
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)
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
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

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*)
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
Analysis of Security

Analyze the following:
• Access Control
• Authentication
Access Control
Relies completely on an
unauthenticated source address (in
the absence of an integrity checking
mechanism)
 Solution: routing info


IP record route
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
Attacks




Goal
Attack
Effect
Countermeasure
Masquerade

Goal


Attack


Convince timekeeper that attacker is authorized to
synchronize it
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
Message Modification

Goal
• Alter msgs from one timekeeper to
another to cause incorrect
synchronization

Attack
• Alter packets sent to victim

Different types of attacks
Modification Attacks

Integrity the recipient’s clock
• pkt.rec, pkt.xmt, pkt.precision

Change round trip delay
Modification Attack
pkt.version
DoS
pkt.mode
Disconnection of association
pkt.stratum
Lower stratum
pkt.ppoll
Affects polling interval
pkt.distance
Affects roundtrip delay, effect choice of
clock source and frequency of polling
pkt.dispersion
Affects estimated dispersion
Modification

Countermeasures
• Use Authentication!
• Stratum level used only
if checks pass
• Access controls indicate
if connection is trusted
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
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
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
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

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
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!
Conclusion


NTP has some weaknesses, but well
designed
Remember, security analyst’s view
• May or may not impact goals of protocol
Questions?