Modern Macs Still Need FileVault

Built-in Mac SSD Encryption Is Easily Bypassed by an Attacker With Physical Access if Filevault Isn’t Enabled

If you buy a modern Mac in 2020, it is going to come with a special physical component called the Secure Enclave. This component enables Apple to carry over many popular iOS features which require extra hardware security like Touch ID and Apple Pay to the Mac.

One of the lesser-known features of the Secure Enclave is that it performs automatic hardware based encryption of a Mac’s built-in SSD. This means that without any user intervention, your new Mac is encrypted right out of the packaging. With this fact in mind, you may be wondering if taking the extra step of enabling FileVault is still necessary? I am here to tell you, yes, it is absolutely necessary.

An encrypted Mac without FileVault allows anyone who has physical access to your device to trivially read your personal data. They don’t even need to know your password. Even worse, some tools used to detect FileVault’s status (like osquery), can conflate the differences between Encrypted versus FileVault On causing you to believe the data on your Mac is safe, when in fact, it’s unprotected from the most common scenarios wherein we rely on encryption to save us.

In this article we will review the current situation, the steps you should take to ensure you are correctly polling this information, and how we are patching osquery to resolve this confusion.

The situation today, TL;DR

• The osquery disk_encryption table as of December 20th, 2020, reports a value of encrypted = 1 for all T2 and M1 Macs, regardless of the FileVault status. This information is technically correct, but has likely resulted in inaccurate interpretations about FileVault’s status.
• Kolide determined that the SSD of Encrypted Macs without FileVault can be trivially accessed with simple physical access to the device.
• Kolide shipped a hotfix for its own customers with a new launcher table kolide_filevault_status, and amended its Check to address the issue.
• Kolide shipped a patch for the osquery disk_encryption table to include a new column: filevault_status

How to Access Files on a Mac That Has Encryption but No FileVault

For 30 years, Apple has included a tool with its operating systems called ‘Target Disk Mode’. This utility allowed a user to mount the disk of one Apple device, on another device as a network volume. There are a variety of reasons this functionality is helpful, the most common being, the retrieval of data on a Mac that no longer boots successfully.

Apple’s built in Target Disk Mode makes it stupid easy to dump the entire contents of an “encrypted” Mac that doesn’t have FileVault enabled

However, using macOS’s Target Disk Mode an attacker with physical access to a device can trivially access the contents of the disk by physically connecting it to another computer and booting it in Recovery Mode. So while that disk may ‘Actually’ be Encrypted at Rest thanks to the Secure Enclave, it is completely vulnerable to data exfiltration so long as FileVault has not been configured.

How easy is this you might wonder? In our testing you can start pulling down a target device’s files in less than 3 minutes:

1. Shut down and Boot the target device into Recovery Mode (either by holding ⌘+R or on M1 Macs by holding the Power button)
2. Once in Recovery Mode (On M1 Macs): Click Options
3. Under the Utilities dropdown, select Share Disk
4. Connect your target device to the recipient device using a Thunderbolt 3 USB-C cable
5. Select your internal hard disk and click Start Sharing
6. In Finder on your recipient device, click MacBook Pro under Locations > Network
7. Copy any desired target files.

Recovery Mode on Target Device

Accessing Networked Target Disk on Recipient Device

What Good Is Hardware Encryption Then?

In 2018, Apple introduced a slate of Macs with a new security co-processor called T2. With this new Secure Enclave CPU, Apple moved from a pattern of software encryption (FileVault2) to automatic hardware encryption. In 2020, on the newly introduced Apple Silicon Macs, a similar Secure Enclave is built right into the M1 SoC.

Both the T2 and the M1 Secure Enclave securely store a 256-bit AES key (UID) which cannot be directly accessed and is burnt into the chip, protecting both the SSD’s data and the TouchID sensor’s stored fingerprints, as well as disabling the device’s camera and microphone when the computer is locked.

What this means in practice, is that the data on a Mac’s disk cannot be accessed once the disk is physically separated from the Mac or if the underlying encryption key is lost. In fact, if your Secure Enclave is damaged or wiped, this encryption will prevent you from accessing any of the contents of the drive. This is yet another failure mode one must negate with backups (which come with their own encryption considerations)

Encryption at Rest ≠ FileVault (osquery & nuance)

Before the introduction of the T2 security chip, disk encryption was synonymous with FileVault configuration on macOS. However, with hardware encryption this distinction became multi-faceted. This nuance was particularly problematic for security agents that did not differentiate between a disk that was ‘encrypted’ and a device that had FileVault configured.

Unfortunately, osquery fell into that camp, and its disk_encryption table simply returned a boolean value for the column encrypted, leading many to draw an erroneous conclusion causing a false sense of security.

Osquery conflates the differences between FileVault and Encryption in its `disk_encryption` virtual table leading to False Negatives

This issue was discovered when the output of common macOS terminal utilities (diskutil apfs list and fdesetup status) returned different information from what was observed when querying devices using osquery.

This issue proved initially difficult to track down, due to the false-negative nature. It is often easier to track down a coding issue producing a false-positive but an intermittent false negative can be truly maddening. Because users are encouraged during setup to configure FileVault on new devices it is uncommon to see devices without it, this coupled with the fact that the table worked as expected on older hardware, led to a difficulty in establishing a pattern and subsequently a lag-time in discovery.

Fortunately with some additional reverse engineering of Kolide updated its own agent and Osquery itself to report this data accurately. At the time of this writing the Osquery core-team has not issued an official release containing this fix, but building the agent yourself should net the new column you need.

Edit 12/29/20: Is this really a problem?

Since publishing this article, I have gotten some feedback suggesting I am making a mountain out of a molehill. The most common critique that I have encountered is:

“Isn’t it basically impossible to setup a device without FileVault in 2020?”

While I would love for this to be the case, it is actually surprisingly easy to configure a device without Enabling FileVault.

I was similarly skeptical when I first encountered this situation; certainly only someone with intent and know-how could avoid FileVault.

To verify I wiped and then setup an M1 MacBook from a blank-slate. The step where FileVault would have been enabled was gated by connecting an AppleID. No mention of FileVault was made and no warning was given when the step was opted out:

While surprising (and somewhat disappointing) this serves as another helpful reminder, that it is important for any IT or Security focused professional to stay abreast of the shifting sands on which we labor.

Additional Resources

• About the Encrypted Storage in your new Mac [Apple Support]
• Secure Enclave Overview [Apple Support]
• Use FileVault to encrypt the startup disk on your Mac [Apple Support]
• Add “filevault_status” to disk_encryption table [Github/Osquery]