What is SNMPv3 Clock Synchronization and Why is it Important?
Clock Synchronization is a necessary part of SNMPv3 Authentication. The "clock" value is made of up two data items called SNMP Engine Boots (the number of times a computer system has started) and SNMP Engine Time (the amount of time that has passed since the last start). An SNMPv3 Manager obtains these values from an SNMPv3 Agent before sending SNMP requests to it (like an SNMP Get). An SNMPv3 Agent obtains these values from an SNMPv3 Manager before sending an SNMP Inform notification to it.
When one SNMP entity sends an SNMPv3 message to another SNMP entity, it stamps the message with the receiver's current time (SNMPv3 Traps are a special case—Traps contain the sender's current time). This ensures that messages are received in a timely manner and are not part of a replay attack. The clock value is part of the message authentication digest, which means that a message can be modified successfully only by someone who knows the correct private key.
In the simulated SNMP message exchange shown here, notice that the
first mention of SNMP Engine Time is 2332807, but the second mention
is 2336807 (an increase of 4000 hundredths of a second). The sender
of the last message shown keeps track of the passage of time and
increases its notion of the receiver's clock by the correct amount
before each subsequent message.
Clocks are resynchronized only when necessary.
Normal and Expected Clock Resynchronization
Hardware clocks between any two computers will drift apart over time. System updates or other human intervention can require a computer to restart at a scheduled time. Power loss or other unexpected interruptions can force a computer to restart at an unplanned time. These are all normal and expected events that will cause SNMPv3 entities to resynchronize.
When the receiver of an SNMPv3 message determines that the message has not been received in a timely manner, it does not perform the requested action. Instead, it sends back a Report PDU to indicate the problem. The MIB object usmStatsNotInTimeWindows indicates that the clocks are out of sync. The Report also includes the current clock value so the original sender can update its notion of the receiver's time. The clock value must always increase, never decrease.
Incorrect Clock Resynchronization
What happens if the Report PDU returned by the receiver contains a clock value that is less than the one in the original sender's memory? This behavior is called "clock rollback", and it is a violation of the SNMPv3 specification. This condition suggests that that the SNMP entity on the receiving device has been compromised by an attacker. It would be a breach of security for an SNMP entity to send information to or receive information from another SNMP entity that has potentially been compromised. Therefore, when this condition is detected, the sender should cease all communication until a human operator has investigated the device and determined the cause with certainty.
It is important to note that many commercial SNMPv3 Managers are programmed to ignore this vulnerability. Why? Because many human operators are concerned only about establishing and maintaining communication with devices in their network. If one management application, `A', can communicate with a device and another, 'B', can not, most operators assume that 'B' is at fault. However, if 'B' is protecting the operator from a potential network attack and 'A' is ignoring the error, this can be a fatal assumption. Consideration should always be given to the possibility that the managed device has been compromised.
Detecting SNMPv3 Agents That Have Clock Rollbacks
Security Analyzer can be run continuously in a network to detect errors like clock rollback that can not be discovered in a single sweep. Continuous monitoring of clock values is necessary to detect a clock rollback condition.
The report on the right shows a list of devices that have exhibited a clock rollback condition. This is a serious vulnerability, so the devices are highlighted in the color red.
A clock rollback condition does not necessarily indicate a network intrusion has taken place or that an attacker has compromised the network element. It is possible that the device has a programming error or hardware fault that prevents the clock value from always increasing properly. For example, if a battery maintains the value of the SNMP Engine Boots counter across restarts, then battery may be dead and need replacing. For problems that can not be resolved by the operators, contact the device vendor for a remedy.