[ntp:security] [Bug 2935] New: Deja Vu: Replay attack on authenticated broadcast mode

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Sat Oct 10 21:23:24 UTC 2015


http://bugs.ntp.org/show_bug.cgi?id=2935

             Bug #: 2935
           Summary: Deja Vu: Replay attack on authenticated broadcast mode
           Product: ntp
           Version: 4.2.8
          Platform: All
        OS/Version: All
            Status: CONFIRMED
          Severity: normal
          Priority: P5
         Component: Security Bugs
        AssignedTo: stenn at ntp.org
        ReportedBy: stenn at ntp.org
                CC: aanchal4 at bu.edu, security at ntp.org
             Group: Security
    Classification: Unclassified


Harlan Stenn <stenn at ntp.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |blocking4.2.8+

Expected Behavior: RFC 5905 page 29 Section 8 states that the
  on-wire protocol resists replay of server response packet in broadcast
  mode. Also on page 55 section 15, the RFC claims security in
  authenticated mode against on-path attackers where an attacker can:

      a) Intercept and archive packets forever

      b) In a wiretap attack, intercept, modify and replay a packet.

      c) In a middleman attack or masquerade attack, intercept, modify
         and replay a packet and prevent onward transmission of the
         original packet.

  The expected behavior in authenticated broadcast mode MUST then at the
  least prevent against an on-path replay attack.

  Actual Behavior:

      a) In a middleman attack, where the intruder is positioned between
         the server and the client and can intercept, and replay a
         packet and prevent onward transmission of the original packet,
         the protocol does not resist the replay attack.

      b) Also if the attacker is one of the machines on the network or
         adjacent network who also gets broadcast packets from the same
         NTP server and has the same trusted keys as the victim, then he
         can simply replay the packets that he receives from the broadcast
server.


  Implications of the attack: Man-in-the-middle or a malicious client
  on the same/adjacent subnet can replay broadcast server packets and
  make the victim client's machine be stuck at a particular time value
  forever. Having time  back in the past has severe implications on
  various applications.

  Testbed Configuration for NTP:

      a) We have a broadcast server and broadcast client.

      b) The broadcast server is a stratum 1 server. Its refid is
         .LOCL. The following lines are added to the ntp.conf file for
         broadcast server.

             broadcast subnetaddress key keyid1
             trustedkey keyid1 keyid2
             keys /etc/ntp/ntp_key  # Path to the key file

         We also create a key file ntp_key where all the keys are listed
         in /etc/ntp directory:

             keyid1 MD5 password1
             keyid2 MD5 password2

      c) The broadcast client is configured only as a broadcast client
         and does not have any other associations. Following lines are
         added to the ntp.conf on the client:

             broadcastclient subnetaddress
             trustedkey keyid1 keyid2
             keys /etc/ntp/ntp_key  # Path to the key file

         We also create a key file ntp_key where all the keys are listed
         in /etc/ntp directory:

             keyid1 MD5 password1
             keyid2 MD5 password2

aa  Testbed Configuration for NTPSec:

    ...

  Recommendations: The major problem here is that there is no origin
  timestamp check on the broadcast packets as origin timestamp is set
  to null in the broadcast server packets. There are a couple
  of recommendations that might be effective:

      a) The broadcast server packet may include an incrementing counter
         value in the extensions field. The client should maintain state
         for this value in the previous packet and check if this counter
         value in the current packet is greater than that of the previous
         packet. This simple check can prevent the replay of the old packets.

      b) There could be some way for NTP to see if it is stuck at the
         same timestamp for a considerable amount of time and should log
         an error or do something to warn the admin.

  Note: Be aware that this issue could affect other ntpd modes of operation
such as
  multicast.

  This defect was discovered by Aanchal Malhotra <aanchal4 at bu.edu>.

-- 
Configure bugmail: http://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the security mailing list