Have a look to other posts of this serie:
[8] Helper tools
Last week we showed how Delorean works, and how we could use it in order to tamper NTP responses. However, time synchronization work slightly different between OS vendors.
Disclaimer: All this information has been obtained from empirical tests and in a specific period of time, so they could have changed.
Pre-Mavericks Mac OS X use a simple time synchronization approach. An ntpd daemon is running and time is synchronized each 9 minutes. Any restriction or security configuration are applied in this daemon, so an attacker could use Delorean and change the internal clock easily.
$ tcpdump -i eth0 -nn src port 123
09:02:18.166708 IP 192.168.1.100.123 > 17.72.148.53.123: NTPv4, Client, length 48
09:11:20.059792 IP 192.168.1.100.123 > 17.72.148.53.123: NTPv4, Client, length 48
09:20:17.951361 IP 192.168.1.100.123 > 17.72.148.53.123: NTPv4, Client, length 48
However, Apple changed the time synchronization in Mavericks. NTPd is still running but it doesn't change the clock directly. The time drift is stored in /var/db/ntp.drift , and there is another service, called "pacemaker" that should check this file and change the clock if needed.
This new service has several benefits. For example, It adapts the amount of NTP requests to the powers state (plugged or battery). Another important difference is that clock changes are not applied in a single step. The clock speeds up or slows down in order to correct the date but avoiding big time steps. It doesn't implement any other security feature so it can be intercepted using Delorean as well.
Despite it shouldn't be a problem, we have found that NTPd wasn't working properly in modern versions of Mac OS X, so time synchronization was not working at all. There are some people arguing in the Internet about this. Does it mean that modern Mac OS X are not vulnerable to a Delorean attack? The answer is NO. Let's have a look to the /usr/libexec/ntpd-wrapper script:
As you can see above, Mac OS X runs a sntp (simple NTP) command at boot, before running the NTPd daemon. This sntp binary is not affected by the same bug, so we could intercept this synchronization and run a Delorean attack when a Mac OS X boots up.
There is still an additional way to exploit this weak time synchronization in Mac OS X. When a user opens the "Date & Time Preferences" menu, the operating system automatically synchronize the time without user's knowledge, so we could use Delorean in this scenario as well.
In the following posts, we will see how we could exploit this in order to intercept SSL communications, as we presented in DEF CON recently.
[4] Microsoft Time Synchronization
[5] Attacking HTTP Strict Transport Security
[6] Attacking the Public Key Infrastructure
[7] Other Attacks[8] Helper tools
Last week we showed how Delorean works, and how we could use it in order to tamper NTP responses. However, time synchronization work slightly different between OS vendors.
Disclaimer: All this information has been obtained from empirical tests and in a specific period of time, so they could have changed.
Pre-Mavericks Mac OS X use a simple time synchronization approach. An ntpd daemon is running and time is synchronized each 9 minutes. Any restriction or security configuration are applied in this daemon, so an attacker could use Delorean and change the internal clock easily.
$ tcpdump -i eth0 -nn src port 123
09:02:18.166708 IP 192.168.1.100.123 > 17.72.148.53.123: NTPv4, Client, length 48
09:11:20.059792 IP 192.168.1.100.123 > 17.72.148.53.123: NTPv4, Client, length 48
09:20:17.951361 IP 192.168.1.100.123 > 17.72.148.53.123: NTPv4, Client, length 48
However, Apple changed the time synchronization in Mavericks. NTPd is still running but it doesn't change the clock directly. The time drift is stored in /var/db/ntp.drift , and there is another service, called "pacemaker" that should check this file and change the clock if needed.
This new service has several benefits. For example, It adapts the amount of NTP requests to the powers state (plugged or battery). Another important difference is that clock changes are not applied in a single step. The clock speeds up or slows down in order to correct the date but avoiding big time steps. It doesn't implement any other security feature so it can be intercepted using Delorean as well.
Despite it shouldn't be a problem, we have found that NTPd wasn't working properly in modern versions of Mac OS X, so time synchronization was not working at all. There are some people arguing in the Internet about this. Does it mean that modern Mac OS X are not vulnerable to a Delorean attack? The answer is NO. Let's have a look to the /usr/libexec/ntpd-wrapper script:
As you can see above, Mac OS X runs a sntp (simple NTP) command at boot, before running the NTPd daemon. This sntp binary is not affected by the same bug, so we could intercept this synchronization and run a Delorean attack when a Mac OS X boots up.
There is still an additional way to exploit this weak time synchronization in Mac OS X. When a user opens the "Date & Time Preferences" menu, the operating system automatically synchronize the time without user's knowledge, so we could use Delorean in this scenario as well.
In the following posts, we will see how we could exploit this in order to intercept SSL communications, as we presented in DEF CON recently.
.png "English"){kind=small}
Posts
