280 likes | 511 Views
Remote Physical Device Fingerprinting. Authors Tadayoshi Kohno, Andre Broido, KC Claffy Appears in IEEE Symposium on Security and Privacy, 2005 Presented by Peter Matthews. Introduction. There are a number of reliable techniques for remote operating system fingerprinting nmap XProbe
E N D
Remote Physical Device Fingerprinting Authors Tadayoshi Kohno, Andre Broido, KC Claffy Appears in IEEE Symposium on Security and Privacy, 2005 Presented by Peter Matthews
Introduction • There are a number of reliable techniques for remote operating system fingerprinting • nmap • XProbe • Paper proposes the next step: • Remotely fingerprint a physical devicewithout that device's knowledge or cooperation
Clock Drift • A standard clock circuit in a computer system uses a quartz crystal oscillator as its time base, similar to any modern wristwatch • Some amount of imprecision in the oscillatory frequency • Clocks using these thus exhibit drift over time when compared to the actual time
Clock Skew • A clock will usually have some offset • Offset(t) = time_reported(t) – true_time(t) • The clock skew S is the change in this offset over time • S = d Offset(t) / dt • Measured in ppm (μs/s)
How much skew? • +/- 4 seconds a day common • (25 minutes a year) • Importantly, paper argues skew of a device is (generally) consistent and distinctive to that device • Thus can use as a fingerprint for this device 24 hours later
Network Time Protocol (NTP) • Hierarchical server system • Top-level servers synchronized via atomic clocks, GPS • Used to synchronizes system clock periodically
Techniques for Determining Clock Skew of a Remote Device • 3 approaches given
TCP Timestamps Option (TSopt) • 32-bit timestamp contained in each packet, taken from a virtual clock that is “at least approximately proportional to real time” • Frequency (Hz) between 1 and 1000 • Windows 2000, XP – 10 Hz (100 ms resolution) • Redhat 9.0 – 100 Hz (10 ms resolution) • Usually reset to zero upon reboot • Usually not affected by changes to the device's system clock (NTP synchronization does not affect)
Exploiting the TCP Timestamps Option (Passive Approach) • The measurer – any entity capable of observing TCP packets from the fingerprintee • Create a trace of TCP packets from fingerprintee • For each packet plot a point • X value: Amount of actual time passed between reception of first packet in trace and the current packet • Y value: The offset observed for this packet, based on timestamp
Use linear programming to determine the equation of the line y = αx + β that best upper-bounds this set of points • α is the estimate of the clock skew • β is an initial observed offset
TSopt clock skew estimates for two sources from a OC-48 link of a US Tier 1 ISP over a two hour period.
Exploiting the TCP Timestamps Option (Semi-Passive Approach) • Windows 2000 and XP machines do not set timestamp flag in their initial SYN packets • RFC 1323 mandates that noneof the following TCP packets in the connection can include timestamp • Thus, previous approach will not work if a Windows machine is behind NAT, firewall
Paper’s trick: The measurer includes timestamp in the responding SYN/ACK packet • Windows machines then include timestamp in all subsequent packets of this connection SYN, TSopt=0 SYN, TSopt=1 SYN-ACK, TSopt=1 Subsequently… data, timestamp data, timestamp
ICMP Timestamps • Reports value of system clock (milliseconds past midnight) • RFC 792 requires frequency is 1000 Hz (1 ms resolution) • If system clock is updated via NTP regularly, will be relatively accurate • However, most hosts do so infrequently
Exloiting ICMP Timestamp Requests (Active Approach) • The measurer: entity capable of sending ICMP Timestamp Request and storing the fingerprintee's subsequent ICMP Timestamp Reply messages • Limitation: Fingerprintee must not be behind a NAT or firewall that filters ICMP • Estimation of clock skew is similar to that in TSopt methods.
Questions Concerning Clock Skew • What is the distribution of clock skews among devices? • How stable are these clock skews over time? • Can these clock skews be measured accurately, independent of network topology and access technology?
Distribution of Clock Skews Figure 1: Histogram of TSopt clock skew estimates for sources in a 2 hour network trace from a OC-48 link of a US Tier 1 ISP. (Considered only sources that sent packet over a period of at least 50 minutes per hour, and sent at least 2000 packets per hour.)
Could this skew simply reflect different operating system and hardware configurations? • To answer this, TSopt clock offsets were measured for 69 Micron 448 MHz Pentium II machines running Windows XP SP1 over 38 days • ~48 TCP packets with timestamp per hour
TSopt clock offsets measured for 69 homogenous machines over 96 hours. • Clock skew can be used to distinguish some, but not all machines.
Stability of Clock Skews • The network traces from this experiment were then divided into 12 and 24 hour periods • All periods of the same length for each machine were then compared • Range of maximum difference for a single device: • 12-hour period: 1.29 – 7.33 ppm, 2.28 ppm mean • 24-hour period: 0.01 – 5.32 ppm, 0.71 ppm mean • Supports authors’ claim that modern processors have relatively stable clock skews
Independence of Access Technology • Fingerprinting of a laptop connected via various access technologies and locations • Skew estimates all within a 1 ppm range
Independence of Network Topology • PlanetLab machines located globally used as measurer, same laptop as previous experiment • Excepting measurement from IIT, skew estimates within .5 ppm range • Generally speaking, estimates are largely independent of topology and distance between fingerprinter and fingerprintee
Other OS Factors • For tested operating systems, system clock and TSopt clock effectively have the same clock skew
Applications • Detecting virtual honeynets and virtual hosts • Counting number of devices behind a NAT • Tracking individual devices • With some probability • Arguing that a given device was not involved in a recorded event • Could use un-anonymized traces on a link to assign hosts in an anonymized trace
Strengths • Shows that it is possible to extract relevant security information from data considered noise • Approach could be used with any other protocols that leak information about a device’s clock
Weaknesses • Further experimentation required • Laptop running Windows XP SP2 has a noticeably different TSopt clock skew after switching to battery power • Newer processors throttle their speeds based on temperature and load, affects voltage from power supply • Easy to circumvent particular methods • echo 0 > /proc/sys/net/ipv4/tcp_timestamps • Randomize TSopt timestamp • Filter ICMP timestamp
Possible Extensions of Paper’s Approach • Utilization of approach with other protocols that leak information about a device’s clock • Use of profiling in combination with skew data • Skew is within a certain range and machine visits certain websites frequently • OS profiling techniques