Tag Archives: Full Disk Encryption

Blog Post Shout Out: June 2018

A number of varied security issues have come to my attention this week which I wanted to keep you informed of. I will provide a respectable shout out to the following sources:

Apple Encrypted Drive Information Disclosure:
At this time Apple macOS has an information disclosure vulnerability that affects encrypted drives in general (encrypted Apple HFS+ / APFS+ and VeraCrypt) that provide the potential for an attacker to obtain details of the files an encrypted hard drive is storing.

This vulnerability originates from the quick look feature of macOS; which allows a user to preview photos, files and folders quickly without having to open them. This feature stores the thumbnails (defined) of the files centrally in a non-encrypted area of the hard disk. This issue can also occur when a USB memory drive is inserted; the same feature stores thumbnails on the external drive and on the boot drive of the macOS system.

If you use an encrypted hard disk or value your privacy when using external drives, please run the following command documented at the end of the following news article after you have viewed sensitive info and want to clear that history/activity:

macOS Breaks Your OpSec by Caching Data From Encrypted Hard Drives: BleepingComputer by Catalin Cimpanu

This suggestion is a workaround until (and if) Apple patches this.

=================
Yubico WebUSB Bypass:
The two-factor authentication/secure login vendor, Yubico has published a security advisory for the use of their YubiKeys. The vulnerability does not reside within the hardware keys themselves but in the authentication steps a web browser (e.g. Google Chrome) uses to authenticate an individual.

In summary, if you are using Google Chrome, please ensure it is updated to version 67 or later and follow the additional suggestion from Yubico in their security advisory:

Security Advisory 2018-03-02 – WebUSB Bypass of U2F Phishing Protection: Yubico

Windows 10 Persistent Malware:
The security vendor BitDefender have published a 104 page report detailing a spyware (defined) which uses rootkit functionality (defined). This malware is noteworthy due to its longevity (dating back to 2012) and it’s ability to install even on modern versions of Windows e.g. Windows 10:

Six Years and Counting: Inside the Complex Zacinlo Ad Fraud Operation: BitDefenders Labs

=================
On a side note I am not too surprised this infection can persist on Windows 10. If a user is tricked into running malware e.g. by clicking a link or opening an attachment either of which can be contained in  a phishing (defined) email or an even more convincing spear phishing (defined) email from an organization or colleague you trust; strong defences won’t always keep you from becoming infected.

The BitDefender report can be downloaded from the above link (it does not request any personal information).

=================
The following news article links to 2 detailed but still easy to follow removal guides. If you are experiencing un-wanted adverts showing within websites that don’t usually show them (even though you are using an ad blocker) or are experiencing re-directs namely you wish to visit website A but are actually sent to website B, please follow these guides to remove this malware:

Rootkit-Based Adware Wreaks Havoc Among Windows 10 Users in the US: BleepingComputer: by Catalin Cimpanu
=================

Thank you.

Microsoft Patches Windows Authentication Vulnerability Used To Bypass BitLocker Encryption

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.

Thank you.