Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Desktops (Apple) Security Encryption OS X Operating Systems Privacy Software Apple Hardware

A $300 Device Can Steal Mac FileVault2 Passwords (bleepingcomputer.com) 88

An anonymous reader writes: Swedish hardware hacker Ulf Frisk has created a device that can extract Mac FileVault2 (Apple's disk encryption utility) passwords from a device's memory before macOS boots and anti-DMA protections kick in. The extracted passwords are in cleartext, and they also double as the macOS logon passwords. The attack requires physical access, but it takes less than 30 seconds to carry out. A special device is needed, which runs custom software (available on GitHub), and uses hardware parts that cost around $300. Apple fixed the attack in macOS 10.12.2. The device is similar to what Samy Kamker created with Poison Tap.
This discussion has been archived. No new comments can be posted.

A $300 Device Can Steal Mac FileVault2 Passwords

Comments Filter:
  • So I can go and buy a device for which the way in has already been fixed? Sounds pretty awesome to me. I know not everyone will be updated immediately, but it seems like Mac folks usually do keep up with them.
    • by Anonymous Coward

      It's even more awesome! I would have to download Flash to watch the demo video!
      The horror... the horror... the horror...

    • Yeah, I was gonna mention this requires additional hardware.

      Not only do you need to buy this $300 Thunderbolt box... you also need an unpatched Mac. And have you priced those things?

    • Re:$300...Really??? (Score:4, Informative)

      by guruevi ( 827432 ) on Thursday December 15, 2016 @09:11PM (#53494775)

      The $300 device can also do the following:

      Retrieve memory from the target system at >150MB/s.
      Write data to the target system memory.
      4GB memory can be accessed in native DMA mode.
      ALL memory can be accessed if kernel module (KMD) is loaded.
      Execute kernel code on the target system.
      Spawn system shell [Windows].
      Spawn any executable [Windows].
      Load unsigned drivers [Windows].
      Pull files [Linux, FreeBSD, Windows, macOS].
      Push files [Linux, Windows, macOS].
      Patch / Unlock (remove password requirement) [Windows, macOS].

      All of the above does not work in latest macOS and Linux, works in pretty much any older Linux or Windows version, protection feature set for Windows only available in Windows Enterprise.

    • by Anonymous Coward

      Ask how long he's been selling those boxes quietly for 3k or more. Now that the vulnerability is patched go ahead and give it away publicly while selling a new and improved box.

  • I find that when I extract passwords, I prefer to have them in cleartext than not in cleartext.

    • by radicimo ( 33693 )

      I find that when I extract passwords, I prefer to have them in cleartext than not in cleartext.

      Not exactly cleartext (but close):

      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

      Setting aside the device, just finding the exploit, cleartext or not, is an accomplishment. I'm not entirely sure all the steps one would take, but guessing it would involve starting with the supposition that a vulnerability like this might exist. Then writing a software tool to dump DMA memory very early in the boot process from EFI, prior to the OS, or perhaps concocting a remote EFI debugger. Does such a thing exist? If you have a memory dump, should be possible to perfo

      • by radicimo ( 33693 )

        The Def Con talk is quite informative regarding tools and methods ... OS X starts around 30:00 mark.

        https://www.youtube.com/watch?... [youtube.com]

        He accesses memory of a running system kernel using a variation of the pcileech and then uses Volatility to examine the dump. I guess the key is that "the FileVault password is stored in clear text in memory and that it's not automatically scrubbed from memory once the disk is unlocked." No need to do anything prior to OS load, except set a boot flag, and he's leveraging an e

  • From the article (Score:5, Informative)

    by berj ( 754323 ) on Thursday December 15, 2016 @09:15PM (#53494791)

    December 13th: Apple released macOS 10.12.2 which contains the security update. At least for some hardware - like my MacBook Air.

    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.

    So, it seems that this door has been closed as of 10.12.2

    Remains to be seen if those machines that don't support 10.12 Sierra will get patches for their latest supported macOS version, of course.

    • Are there any thunderbolt equipped Macs that don't support 10.12.2?

    • Re:From the article (Score:4, Interesting)

      by Skuld-Chan ( 302449 ) on Thursday December 15, 2016 @10:00PM (#53494957)

      Apple doesn't release security fixes for major bugs on previous OS's for the most part. As an exception and a lesson on how Apple deals with security issues - check out the history of the rootpipe exploit.

      And yes - they did eventually fix that on previous versions of the OS after security experts shamed them publicly - almost a year later. Rootpipe was one of the worst security vulnerabilities - privilege escalation - and you can see how seriously they took it.

  • s/kamker/kamkar/
  • How was that fixed?

    I guess they cannot close thunderbolt DMA access without redering it unusable to boot. Hence I suspect they just randomized the location where the password is fetched in memory. And of course they probably made sure it is erased after use. Anyone has a clue?

    • by guruevi ( 827432 ) on Thursday December 15, 2016 @10:24PM (#53495039)

      The 'hack' is prevented by enabling VT-d (basically virtualization of the PCIe devices) which prevents PCIe devices to have direct access to the hypervisor's memory.

      • I do not get it. Wasn't that supposed to happen before system boot? There is an hypervisor at work in UEFI environment?
        • by guruevi ( 827432 )

          All a hypervisor is is a program telling the processor it's a hypervisor and then it can do whatever (given off course the OS has given it such privileges to the CPU). The EFI can simply say to the CPU "hey, I'm a hypervisor, block all access to the/this memory from any attached devices" until a 'fuller' OS comes along and then it just hands whatever credentials over.

          VT-d is an extension to the x86 CPU instruction set specifically for these kinds of purposes since these days everything is virtualized and th

  • by beckett ( 27524 ) on Thursday December 15, 2016 @09:49PM (#53494923) Homepage Journal

    The device is similar to what Samy Kamker created with Poison Tap.

    how is this device similar to Poison Tap? Poison Tap used USB to mimic a network device and conduct a MITM attack harvesting cookies etc. from the outgoing network traffic on a powered computer with a web browser. Frisk's exploit uses a thunderbolt connection to dump a booting mac's memory before OSX is started.

    • They both involve plugging something into the computer. This is the new /. Your administrative assistant probably knows more about the exploit than the current overlords.
  • by Anonymous Coward

    You'll also need the $30 dongle from Apple to plug the device into the computer. This will also make the theft more conspicuous.

  • I've heard that with a skilled operator a $3 device" [screwfix.com] can be almost 100% effective.
  • Since the hardware side of this hack requires a Thunderbolt port, don't suppose there's a chance of just disabling that port altogether, is there?

    Just curious if the obvious answer is obvious, since many of us have found a use for Apple hardware, but have found little use for expensive proprietary bullshit.

    • Fill them with epoxy
      • Fill them with epoxy

        Apple is already working on that by designing hardware completely devoid of any external connections in order to sell iVulcan, the data melding tech that will only cost you $599 more (dongles not included)

  • That must have taken a lot of determination.
  • by TehHustler ( 709893 ) on Friday December 16, 2016 @10:48AM (#53497381) Homepage
    Bit confused about the disclosure timeline on this one - issue found, then presented at a conference to the public with videos recorded etc, THEN apple notified and they say "don't tell anyone yet!!!!" - but everyone had already been told at DEF CON. How does that work?

Hold on to the root.

Working...