During Microsoft’s scheduled release of security updates earlier this month, they issued an update MS15-122 to resolve a security vulnerability responsibly disclosed (defined) to them by security researcher Ian Haken of Synopsys Inc.
How this does flaw work?
Apologies but this explanation is as short as I can make it while explaining what’s happening as we go along:
This authentication bypass succeeds since an artefact used by the Kerberos protocol (defined) is used for malicious intentions.
In a standard scenario where a legitimate user logins onto their organizations domain using their device, their hashed password (defined) is checked against the corresponding password hash stored on the domain controller (defined). However, when the user is away from the office and cannot connect to the domain controller, the user’s hashed credentials (stored within the device) are used to log them on to their device.
A machine/device hashed password is also created and stored on the device. This device password is a defence in depth measure (defined)(PDF) used to prevent a scenario such as a stolen laptop being connected to a purposefully created domain controller in order to access the contents of the stolen device. Since the domain controller would not have any corresponding device password for this stolen device (i.e. it has no prior knowledge of this device), the device remains secure since the attacker can’t logon to it.
In a similar manner to the user’s password as mentioned above however this check of the device password with the domain controller can’t happen if the legitimate user is away from the office. This fact is exploited by this authentication bypass to access the contents of the device.
As discussed above a purposefully created domain controller can be created by the attacker with the same account name used by the owner of the device (this can be obtained by just looking at the login username on the screen of the device or by using a man-in-the-middle attack (defined) to sniff the network (obtain information from passing data packets on a network connection) since DNS and Kerberos send the account username in plaintext (not encrypted)). The attacker also creates a corresponding password for the user’s account on the domain controller that has a creation date many years in the past (in the example code provided on page 8 within this report (PDF), the year 2001 was used).
If the attacker were to connect the device to the newly created domain controller (which is under their control) and try to logon as mentioned above the logon should fail since the domain controller would not have any prior knowledge of that device (no corresponding machine password would be present on the controller). But this check never happens because the account password is checked first and as we will see below, this account password check will eventually succeed (it was never thought that the account password could be changed) resulting in the device being unlocked.
Next; the attacker enters the password they set earlier using the code mentioned above; the password is rejected since it’s very old (the domain controller the device is connected to informs the device of this) and the attacker is asked to set a new password, once they do so, they have access to the device and all the data it contains. The device unlocked the encrypted drive since it received the correct password and did not detect that anything was wrong.
Why Should This Issue Be Considered Important?
In order for this attack to succeed it needs to assume the following:
- The Windows device to be attacked has been joined to a Windows domain (defined) and a legitimate user from that domain has previously successfully logged in.
- Microsoft Windows BitLocker is enabled without pre-boot authentication i.e. no PIN or USB drive is required for the Windows login password prompt to be displayed. This is often the case since its more convenient for the users of the device to login.
- Assumes the attacker has physical access to the target device for a short period of time.
This attack can be executed in a matter of seconds using a set of commands based on the example within page 8 of this report (PDF).
How Can I Protect Myself From This Issue?
You should ensure that all of your Microsoft Windows devices have the update mentioned in Microsoft’s security bulletin MS15-122 installed. This update resolves the issue discussed above.
I recommended installing this update as part of the scheduled November Microsoft updates discussed in a recent blog post. The steps for installing this update and the other November updates are also provided in that blog post.