Have a look to other posts of this serie:
[8] Helper tools
Yesterday we were talking about how time synchronization works in Mac OS X, and how it is different for pre-Mavericks versions and the most modern ones. Today, we are having a look to GNU/Linux. Of course, we have a big amount of Linux flavors available, and we couldn't review all of them, but I chose the two favors that I think are most extended in desktop users (Ubuntu and Fedora), since they would be the target for this attacks.
Disclaimer: All this information has been obtained from empirical tests and in a specific period of time, so they could have changed.
Ubuntu Linux is the only one reviewed system that doesn't synchronize the time in a regular basis, so it isn't just a matter of waiting the necessary amount of time and intercept the NTP request. In Ubuntu, time synchronization is done each time than a network interface comes up (and, of course, when the system boots up). This is easy to see if we have a look at the script files that Ubuntu runs when that happens:
$ ls /etc/network/if-up.d/
000resolvconf avahi-daemon ntpdate wpasupplicant
avahi-autoipd ethtool upstart
There isn't any restriction in terms of a big date change, so we could easily intercept this request and set the computer's clock using Delorean. There are two possible scenarios: Intercept at boot time or when the computer connects to a network, or just detach the computer from the network (deauth on a Wifi, for example) and wait for the next connection.
On the other hand, Fedora Linux use a similar approach than Mac OS X. In previous versions, it just synchronized the time each minute, without any security restrictions, so it was easy and fast to use Delorean in order to tamper the system clock:
$ tcpdump -i eth0 -nn src port 123
12:43:50.614191 IP 192.168.1.101.123 > 89.248.106.98.123: NTPv3, Client, length 48
12:44:55.696390 IP 192.168.1.101.123 > 213.194.159.3.123: NTPv3, Client, length 48
12:45:59.034059 IP 192.168.1.101.123 > 89.248.106.98.123: NTPv3, Client, length 48
At some point they changed the synchronization approach. At this moment, there is a daemon called "chrony" which works in a similar way than "pacemaker" in Mac OS X. However, Chrony are configured in a more secure way than Pacemaker. By default, it doesn't accept big date changes. It only accepts them in the first three tries from the last reboot, so we can still use a Delorean attack at boot time or if we can crash the chrony service.
We're probably going too fast, because we haven't talked about HSTS and how it could be bypassed using time synchronization attacks, but let me show you an example of this attack against an Ubuntu Linux box:
[4] Microsoft Time Synchronization
[5] Attacking HTTP Strict Transport Security
[6] Attacking the Public Key Infrastructure
[7] Other Attacks[8] Helper tools
Yesterday we were talking about how time synchronization works in Mac OS X, and how it is different for pre-Mavericks versions and the most modern ones. Today, we are having a look to GNU/Linux. Of course, we have a big amount of Linux flavors available, and we couldn't review all of them, but I chose the two favors that I think are most extended in desktop users (Ubuntu and Fedora), since they would be the target for this attacks.
Disclaimer: All this information has been obtained from empirical tests and in a specific period of time, so they could have changed.
Ubuntu Linux is the only one reviewed system that doesn't synchronize the time in a regular basis, so it isn't just a matter of waiting the necessary amount of time and intercept the NTP request. In Ubuntu, time synchronization is done each time than a network interface comes up (and, of course, when the system boots up). This is easy to see if we have a look at the script files that Ubuntu runs when that happens:
$ ls /etc/network/if-up.d/
000resolvconf avahi-daemon ntpdate wpasupplicant
avahi-autoipd ethtool upstart
There isn't any restriction in terms of a big date change, so we could easily intercept this request and set the computer's clock using Delorean. There are two possible scenarios: Intercept at boot time or when the computer connects to a network, or just detach the computer from the network (deauth on a Wifi, for example) and wait for the next connection.
On the other hand, Fedora Linux use a similar approach than Mac OS X. In previous versions, it just synchronized the time each minute, without any security restrictions, so it was easy and fast to use Delorean in order to tamper the system clock:
$ tcpdump -i eth0 -nn src port 123
12:43:50.614191 IP 192.168.1.101.123 > 89.248.106.98.123: NTPv3, Client, length 48
12:44:55.696390 IP 192.168.1.101.123 > 213.194.159.3.123: NTPv3, Client, length 48
12:45:59.034059 IP 192.168.1.101.123 > 89.248.106.98.123: NTPv3, Client, length 48
At some point they changed the synchronization approach. At this moment, there is a daemon called "chrony" which works in a similar way than "pacemaker" in Mac OS X. However, Chrony are configured in a more secure way than Pacemaker. By default, it doesn't accept big date changes. It only accepts them in the first three tries from the last reboot, so we can still use a Delorean attack at boot time or if we can crash the chrony service.
We're probably going too fast, because we haven't talked about HSTS and how it could be bypassed using time synchronization attacks, but let me show you an example of this attack against an Ubuntu Linux box:
.png "English"){kind=small}
Posts
No comments :
Post a Comment