macOS FileVault2 Password Retrieval
macOS FileVault2 let attackers with physical access retrieve the password in clear text by plugging in a $300 Thunderbolt device into a locked or sleeping mac. The password may be used to unlock the mac to access everything on it. To secure your mac just update it with the December 2016 patches.
Anyone including, but not limited to, your colleagues, the police, the evil maid and the thief will have full access to your data as long as they can gain physical access - unless the mac is completely shut down. If the mac is sleeping it is still vulnerable.
Just stroll up to a locked mac, plug in the Thunderbolt device, force a reboot (ctrl+cmd+power) and wait for the password to be displayed in less than 30 seconds! Check out the demo video below:
How is this possible?
At the very core of this issue there are two separate issues.
The first issue is that the mac does not protect itself against Direct Memory Access (DMA) attacks before macOS is started. EFI which is running at this early stage enables Thunderbolt allowing malicious devices to read and write memory. At this stage macOS is not yet started. macOS resides on the encrypted disk - which must be unlocked before it can be started. Once macOS is started it will enable DMA protections by default.
The second issue is that the the FileVault password is stored in clear text in memory and that it's not automatically scrubbed from memory once the disk is unlocked. The password is put in multiple memory locations - which all seems to move around between reboots, but within a fixed memory range.
This makes it easy to just plug in the DMA attack hardware and reboot the mac. Once the mac is rebooted the DMA protections that macOS previously enabled are dropped. The memory contents, including the password, is still there though. There is a time window of a few seconds before the memory containing the password is overwritten with new content.
After the PCILeech hardware is connected just run the mac_fvrecover command on the attacker computer.
In Details
The password, when entered, is stored in memory as unicode. Every 2nd byte will be zero if a password consisting only of ascii characters is used. Enter a "random" phrase, not naturally occurring in memory, at the password prompt. In this example the phrase eerrbbnn is used. In memory this is stored as 6500650072007200620062006e006e. Search for this using PCILeech and you'll notice that the phrase is stored in multiple memory locations as per the example below.
After finding the memory locations it's possible to have a look at it. One might have to re-attach the attack device to the mac if the first read fails.
If the locations found are checked out the password will be clearly visible. In addition to this other signatures that may be scanned for are also found, such as phd0 at the beginning of the memory page read.
Can I try it out myself?
Yes - Absolutely! Download PCILeech from Github and purchase the hardware. Password recovery have been tested and found to work on multiple macbooks and macbook airs (all with Thunderbolt 2). The attack is not tested on more recent macs with USB-C.
Password recovery may fail if the user uses special (non ascii) characters in the password. In those cases a memory dump will be saved so that it can be manually searched for the password.
Please note that trying this on other macs than your own might not be legal.
Other Notes
Recovering the password is just one of the things that are possible unless the security update is applied. Since EFI memory can be overwritten it is possible to do more evil ...
The disclosure timeline is as follows:
Conclusion
The solution Apple decided upon and rolled out is a complete one. At least to the extent that I have been able to confirm. It is no longer possible to access memory prior to macOS boot. The mac is now one of the most secure platforms with regards to this specific attack vector.
Update:
This issue is classified as: CVE-2016-7585
Anyone including, but not limited to, your colleagues, the police, the evil maid and the thief will have full access to your data as long as they can gain physical access - unless the mac is completely shut down. If the mac is sleeping it is still vulnerable.
Just stroll up to a locked mac, plug in the Thunderbolt device, force a reboot (ctrl+cmd+power) and wait for the password to be displayed in less than 30 seconds! Check out the demo video below:
How is this possible?
At the very core of this issue there are two separate issues.
The first issue is that the mac does not protect itself against Direct Memory Access (DMA) attacks before macOS is started. EFI which is running at this early stage enables Thunderbolt allowing malicious devices to read and write memory. At this stage macOS is not yet started. macOS resides on the encrypted disk - which must be unlocked before it can be started. Once macOS is started it will enable DMA protections by default.
The second issue is that the the FileVault password is stored in clear text in memory and that it's not automatically scrubbed from memory once the disk is unlocked. The password is put in multiple memory locations - which all seems to move around between reboots, but within a fixed memory range.
This makes it easy to just plug in the DMA attack hardware and reboot the mac. Once the mac is rebooted the DMA protections that macOS previously enabled are dropped. The memory contents, including the password, is still there though. There is a time window of a few seconds before the memory containing the password is overwritten with new content.
 |
| The PCILeech DMA attack hardware attached to a mac victim. |
After the PCILeech hardware is connected just run the mac_fvrecover command on the attacker computer.
 |
| Retrieving the FileVault password with PCILeech. The correct password is DonaldDuck. |
In Details
The password, when entered, is stored in memory as unicode. Every 2nd byte will be zero if a password consisting only of ascii characters is used. Enter a "random" phrase, not naturally occurring in memory, at the password prompt. In this example the phrase eerrbbnn is used. In memory this is stored as 6500650072007200620062006e006e. Search for this using PCILeech and you'll notice that the phrase is stored in multiple memory locations as per the example below.
 |
| Searching the mac memory for the test phrase eerrbbnn. |
After finding the memory locations it's possible to have a look at it. One might have to re-attach the attack device to the mac if the first read fails.
If the locations found are checked out the password will be clearly visible. In addition to this other signatures that may be scanned for are also found, such as phd0 at the beginning of the memory page read.
 |
| The phrase is clearly visible at the memory location. |
Can I try it out myself?
Yes - Absolutely! Download PCILeech from Github and purchase the hardware. Password recovery have been tested and found to work on multiple macbooks and macbook airs (all with Thunderbolt 2). The attack is not tested on more recent macs with USB-C.
Password recovery may fail if the user uses special (non ascii) characters in the password. In those cases a memory dump will be saved so that it can be manually searched for the password.
Please note that trying this on other macs than your own might not be legal.
Other Notes
Recovering the password is just one of the things that are possible unless the security update is applied. Since EFI memory can be overwritten it is possible to do more evil ...
The disclosure timeline is as follows:
- End of July: Issue found.
- August 5th: PCILeech presented and released at DEF CON 24. (FileVault issue not mentioned).
- August 15th: Apple notified.
- August 16th: Apple confirmed issue and asked to hold off disclosure.
- December 13th: Apple released macOS 10.12.2 which contains the security update. At least for some hardware - like my MacBook Air.
The solution Apple decided upon and rolled out is a complete one. At least to the extent that I have been able to confirm. It is no longer possible to access memory prior to macOS boot. The mac is now one of the most secure platforms with regards to this specific attack vector.
Update:
This issue is classified as: CVE-2016-7585
Comments
Post a Comment