ICS Essentials: Dissecting PTP Packet Captures

In this follow-up to the previous Precise Timing Protocol (PTP) blog post, we flipped our evil bits and analyzed a PTP capture file; thus, enumerating an unknown target's PTP implementation. The target PCAP file is available on Wireshark's Wiki: https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=ptpv2.pcap

Capture & Display Filters. PTP typically traverses across the network over UDP [RFC768], IPv4 [RFC791, IPv6  [RFC2460] or Ethernet as "ptp-event" or "ptp-general" messages. Wireshark supports the generic "ptp" display filter, but more granular packet-field filters are available on the site's "Display Filter Reference: Precision Time Protocol (IEEE1588) display filter" page. Alternatively, you can specify a port/protocol specific capture filter to limit packet ingest: "udp port 319 or udp port 320 or tcp port 319 or tcp port 320". For PTP over Ethernet packets, specify: "ether proto 0x88F7". As mentioned earlier, we analyzed the Wireshark provided "ptpv2.pcap" file. Based on the capture file's contents, we can assume the aforementioned capture filter was utilized as the viewed packets are either Ethernet encapsulated, sourced from, or directed to an IANA registered PTP port.

Time Source Identification. A reverse OUI lookup disclosed the time source's vendor (i.e., Hirschmann): Ethernet II, Src: Hirschma_00:09:ba (00:80:63:00:09:ba). This layer two address is correlated with subsequent messages that list the same MAC address as the network's Grand Master Clock:

• ClockIdentity: 0x008063ffff0009ba -- ptp.v2.mm.clockidentity. The IETF demands that the clock servers "always be identified by their clock ID and not the IP or Layer 2 address." In IPv4 networks, the utilization of a Layer 3 address may indicate a lack of NAT or simply an ineffective PTP architecture.
• grandmasterClockIdentity: 0x008063ffff0009ba -- ptp.v2.mm.grandmasterclockidentity. This subnet had a single master clock, known as the grandmaster clock or best master clock, which forwarded time to subordinate devices. The identities include a "ffff" padding implanted between its MAC address, which is similar to Rockwell Automation's inclusion of  "fffe" padding as a CIP Sync identifier value. Perhaps, this is a format CIP Synch format specific to Hirschmann?  
• Note: Wireshark protocol field-specific display filters follow the double hypens throughout this blog entry.

We can speculate that there was no higher-level master clock (northbound) of the Hirschmann switch as the  "TimeSource: Unknown (0x80)" was present -- ptp.v2.mm.timesource. If there was another Best Master Clock (BMC), we could have expected to observe a known value:

• 0x10: atomicClock
• 0x20: gps
• 0x22: terrestrialRadio 
• 0x40: ptp 
• 0x50: ntp 
• 0x60: handSet
• 0x90: other
• 0xA0: internalOscillator

Additionally, all announce and sync messages originated from the Hirschmann switch. These packets are transmitted by the Grand Master to Slave clocks. Also, note that the Hirschmann device had an assigned "priority1" value (ptp.v2.an.priority1) of 96. Although, subsequent announce messages contained a secondary unknown time source, the Hirschmann still had a lower priority number. This second time source's layer two OUI resolved to MAKU Informationstechik GmbH, which manufactures a VMS Application gateway for ATMs, CCTV cameras, and card readers.

The layer 3 header also reveals that neither Quality of Service (QoS) nor Differentiated Services Codepoint (DSCP) values are applied to the IPv4 encapsulated traffic: Differentiated Services Fiel: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not ECN-Capable Transport)) -- ip.dsfield . The DSCP value, which ranges from 0 to 64 as per RFC 2474, may be indicative to the time source device's manufacturer. For instance, Juniper's PTP value is set at "ipv4-dscp 56"; whereas, the Cisco ASR 9000 has a default value of 46. A review of the Hirschmann RPS datasheet stated that the vendor does in fact, support TOS/DSCP prioritization. Perhaps the administrator failed to correctly configure the device? Is this indicative of the target network's design?

Leveraging Wireshark's Statistics > Endpoints functionality easily identifies which addresses are communicating by what protocol. A review of the IPv4 addresses tab clued us into that only the Hirschmann was the sole time-source (192.168.2.6) transmitting UDP packets to 2240.0.107 (Mcast_PTP_v2) and 224.0.1.129 (Mcast_PTP_v2_messages) multicast addresses. The inspection of each packet's PTP flag bits revealed no unicast messages: ".... .0.. .... .... = PTP_UNICAST: False" -- ptp.v2.flags.unicast. All of the Delay Request messages were transmitted as multicast. We observed the same behavior earlier in the capture within the layer two traffic as the destination MAC addresses are all multicast (e.g., start with a "01:" octet). Given there isn't any master-initiated unicast communication, PTP delay responses or follow-up messages nor slave initiated sync/delay request messages , we assume that either the Hirschmann switch is the sole PTP device or an additional capture/display filter was implemented; thus, preventing us from observing additional endpoints. The fact that there isn't any unicast traffic is also peculiar given certain vendors' integration of the PTP standard. For example, Cisco's ASR 1000 supports IPv4 unicast not multicast and only supports unicast negotiation mode in PTPv2 boundary clocks.

Each packet also had a "subdomainNumber: 0" value -- ptp.mm.default.data.set.subdomainname. NIST defines a "PTP subdomain" as "a logical grouping of 1588 clocks that synchronize to each other using the PTP protocol, but that are not necessarily synchronized to PTP clocks in another PTP subdomain. Subdomains provide a way of implementing disjointed sets of clocks, sharing a common network, but maintaining independent synchronization within each set." Furthermore, Boundary Clocks (BCs) "define the segments within a subdomain." This packet capture either was limited previously identified Hirschmann switch or we may be observing a smaller ICS cell (logical) zone. Subsequent captures would provide clarification on its topology and connected devices.

Time Conversion. The Sync message included a time-stamp in Epoch seconds: originTimestamp (seconds): 1169232201 -- ptp.v2.pdrq.origintimestamp. Converting these seconds to a human-readable calendar date revealed the time of capture: Fri, 19 Jan 2007 18:43:25 GMT. Naturally, this is dependent on a properly configured time source. Since the master clock included the time within the Sync packet, we know that the clock is configured in "One-Step" mode. If the time would have been absent in the Sync packet and later found in the Follow-up message, we could've assumed that the master clock was configured for two-step mode. The latter found most typically in Rockwell devices.

We have discussed a few ways traffic analysis can be quite revealing both from defense, as well as offense perspectives. The above is just a small sampling of what is possible; thus, I encourage all administrators to capture and review their networks for any information disclosure, misconfiguration or potentially malicious traffic.

References:

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
https://wiki.wireshark.org/Protocols/ptp
https://www.wireshark.org/docs/dfref/p/ptp.html
https://tools.ietf.org/html/rfc2474#section-4.1
http://www.epochconverter.com/
http://www.nist.gov/el/isd/ieee/terms1588.cfm
http://www.chronos.co.uk/files/pdfs/itsf/2013/Day1/14.05_david_chen_nokia_solutions.pdf
http://www.ieee802.org/1/files/public/docs2015/as-cummings-ieee-1588-security-requirements-0115-v41.pdf
https://tools.ietf.org/html/draft-ietf-tictoc-ptp-enterprise-profile-05
https://tools.ietf.org/html/rfc7384

http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guide/chassis/asrswcfg/1588v2ptp.html.
https://www.belden.com/docs/upload/PB342_RSP_Switches.pdf
https://www.maku-info.eu/index.php/en/produkte-e/physical-security-e/diva-connect-vms-e.html