Friday 30 October 2015

Microsoft Time Synchronization

Have a look to other posts of this serie:

[5] Attacking HTTP Strict Transport Security
[6] Attacking the Public Key Infrastructure
[7] Other Attacks
[8] Helper tools

Of course, I couldn't finish my examples without talking about Microsoft. From the desktop OS vendor that I have tested, Microsoft has the most robust one in terms of security. It works in a different way for standalone computers than in domain members, so let's cover both circumstances:

In a standalone Windows box, time synchronization takes place each 7 days (Sundays at 1-2am or so) so the only one option to intercept an NTP request is to be there on Sunday or Monday, whenever the victim boots the computer for the first time after the synchronization time. In addition, Windows has a clock drift limitation of 15 hours, so we can't change the clock more than 15 hours on each synchronization, which is a real problem for most attacks that we will see in the following posts.

The 15 hours value is not a harcoded value, it is stored in the registry, in a couple of keys called "MaxPosPhaseCorrection" and "MaxNegPhaseCorrection", and they change in different systems, for example, in a Windows 7/8 is 15 hours but in a Windows Server 2012 is 48 hours, and in older servers is different as well. It could also change when some changes happen in the box, for example when a box become a domain member.


In combination, both controls make Windows boxes pretty secure in terms of time synchronization. However, if any of both are changed by the user, there are some attack vectors that could be used. For example, there are many tutorials in the internet explaining how to change the time synchronization scheduled task, because they think (and probably they're right) that once a week is not enough for a good clock accuracy.


So, under this circumstance, a new attack vector came to my mind. What happen if the user configure his system to synchronize the time more often than the maximum clock drift allowed? The answer is than an attacker could intercept that NTP request and change the clock just a few seconds before the next scheduled time synchronization, then intercept the following NTP requst and do the same, and again, and again, and again until he reach the desired time. I called this attack "Time Skimming", because it's a similar idea than a stone skimming in a lake, and it's implemented in Delorean:



There's another way to force time synchronization, but it requires some kind of social engineering. When the user manually request a time synchronization using the "Internet Time Settings", but it's not as easy as in Mac OS X, since it takes several clicks.

Domain members work in a different way. The Max[Pos|Neg]PhaseCorrction value is set to 0xFFFFFFFF which means "accept any clock drift". That is a risk, but they include a packet signature in order to authenticate the source of the response:


They use the NTP standard in a creative way. Key ID should be a value that identify which key should be used to sign the response. In a regular NTP request it should be 1 or 2, depending on the number of keys available. However, what Microsoft did was use this to identify the computers username in the active directory that is requesting the time synchronization. For example, if we have a KeyID 0x5e040000 we need to change its endianess and then we have 0x0000045e. The first bit of this is a key selector (0 or 1), and the rest is the Relative ID (RID) for the computer.


As you probably know, both computers and users are objects in active directory. Computers are a special kind of users. They set a password for this user when they join the domain, and those passwords are changed in a regular basis. A Domain Controller store the last two known hashed passwords, so the key selector that we mentioned before identify this.

/* Sign the NTP response with the unicodePwd */
MD5Init(&ctx);
MD5Update(&ctx, nt_hash->hash, sizeof(nt_hash->hash));
MD5Update(&ctx, sign_request.packet_to_sign.data, sign_request.packet_to_sign.length);
MD5Final(signed_reply.signed_packet.data + sign_request.packet_to_sign.length + 4, &ctx);


Response packets are signed using MD5 ( md5(hashed_password+response_body) ), which is not the most robust hashing algorithm in the world, but I couldn't find a working attack for such a small message, so at this point I think a Microsoft domain time synchronization is the most robust that I have seen in my research.

Wednesday 28 October 2015

Fedora / Ubuntu Time Synchronization

Have a look to other posts of this serie:

[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:

Tuesday 27 October 2015

Mac OS X Time Synchronization

Have a look to other posts of this serie:

[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.

Wednesday 21 October 2015

NTP MitM Attack using a Delorean

Around one and a half year ago, I started a research about how computers synchronize their internal clocks, and how this could be used in order to attack well-known protocols and services running in Operating Systems. As a result, I have presented my findings in several security conferences such as BlackHat Europe 2014, RootedCON 2015 (Spanish), DEF CON 23 and Navaja Negra / ConectaCON 2015 (Spanish).


Today, October 21th 2015, it's the date when Marty McFly went to the future in the second part of the amazing Back to the Future saga, so I can't think in a better date to start releasing all the details about this research.

[4] Microsoft Time Synchronization
[5] Attacking HTTP Strict Transport Security
[6] Attacking the Public Key Infrastructure
[7] Other Attacks
[8] Helper tools

As we will see in the upcoming posts, all the OS vendors that I have tested use the Network Time Protocol (NTP) in order to keep their internal clock accurate, which is very important for some authentication protocols and other stuff. Most of them don't deploy this service in a secure way, making it vulnerable to Man-in-the-Middle attacks.

In order to exploit this issue, I developed a tool called DELOREAN. Delorean is an NTP server written in python, open source and available from GitHub (contributions are welcomed). I borrowed a few lines of code from kimifly's ntpserver and, of course, all the credits to him have been included.

What makes Delorean different and useful for us is that we can configure its flags in order to make it work in a different way than a regular NTP server. Basically, we can configure it in order to send fake responses, similar to the Metasploit's fakedns module.

$ ./delorean.py -h
Usage: delorean.py [options]

Options:
-h, --help show this help message and exit
-i INTERFACE, --interface=INTERFACE Listening interface
-p PORT, --port=PORT Listening port
-n, --nobanner Not show Delorean banner
-s STEP, --force-step=STEP Force the time step: 3m (minutes), 4d (days), 1M (month)
-d DATE, --force-date=DATE Force the date: YYYY-MM-DD hh:mm[:ss]
-x, --random-date Use random date each time


We have the typical interface (-i) and port (-p) flags, that help us to bind the service exactly where we want. The -n flag only hides the super-cool Delorean banner :)

                                    _._                                          
                               _.-="_-         _                                 
                          _.-="   _-          | ||"""""""---._______     __..    
              ___.===""""-.______-,,,,,,,,,,,,`-''----" """""       """""  __'   
       __.--""     __        ,'                   o \           __        [__|   
  __-""=======.--""  ""--.=================================.--""  ""--.=======:  
 ]       [w] : /        \ : |========================|    : /        \ :  [w] :  
 V___________:|          |: |========================|    :|          |:   _-"   
  V__________: \        / :_|=======================/_____: \        / :__-"     
  -----------'  ""____""  `-------------------------------'  ""____""  

We can use Delorean in several modes, but we are going to focus in the most useful ones. There are some other attacks that weren't really interesting after developing them, but they are still in the code. Perhaps I will remove them in the future, sine they require scapy and some dependencies.

Since it's too soon yet to talk about how OS synchronize, we will test how Delorean works using the command line tool "ntpdate":

$ ntpdate -q 192.168.1.2
server 192.168.1.2, stratum 2, offset 97372804.086845, delay 0.02699
20 Oct 06:05:45 ntpdate[881]: step time server 192.168.1.2 offset 97372804.086845 sec


By default (no flags), Delorean responses a date that matches the same week and month day than the current date, but at least 1000 days in the future. This was useful for the HSTS bypass as we will see in upcoming posts.

# ./delorean.py -n
[19:44:42] Sent to 192.168.10.113:123 - Going to the future! 2018-08-31 19:44
[19:45:18] Sent to 192.168.10.113:123 - Going to the future! 2018-08-31 19:45


We can set a relative jump from the current date using the step flag (-s). Relative jumps can be defined as 10d (ten days in the future), -2y (two years in the past), etc:

# ./delorean.py -s 10d -n
[19:46:09] Sent to 192.168.10.113:123 - Going to the future! 2015-08-10 19:46
[19:47:19] Sent to 192.168.10.113:123 - Going to the future! 2015-08-10 19:47


We can also set a specific date, and Delorean would answer always the same date:

# ./delorean.py -d ‘2020-08-01 21:15’ -n
[19:49:50] Sent to 127.0.0.1:48473 - Going to the future! 2020-08-01 21:15
[19:50:10] Sent to 127.0.0.1:52406 - Going to the future! 2020-08-01 21:15


There are an additional attack called "Skimming Attack" that is useful only on certain configurations, but we will go in depth with it when we will talk about Microsoft synchronization, despite it could be useful in other platforms.