Posted by & filed under Hacking & Pentesting, Hacks, Security News, Tools & Methodology.

ThunderboltWe security folks often feel like we are regurgitating the same type of security issues over and over again, just in new contexts. So depending on how you look at it, this is “old new” or “new old” news. Nevertheless, I thought it would be a good idea to take it down from speculation to hard facts:

Yes, it is possible to hack a Mac through the new DisplayPort/Thunderbolt interface, exactly the same way it is possible to hack Macs and PCs through FireWire interfaces.

How? Well, as Thunderbolt expands the PCIe bus,  buying a Firewire to Thunderbolt adapter will suffice. This is the same approach as many pentesters, myself included, have used when encountering laptops without a FireWire port on pentests. Simply using PCMCIA or ExpressCards to expand the bus and add a FireWire port will do the trick. I finally got the hardware to test this out last week, and it works like a charm. Plug n’ Play FTW.

So how did I exploit my Macbook Pro? Using Inception, a tool I’m developing to exploit FireWire DMA vulnerabilities.

Inception can unlock Windows 7, Windows Vista and Windows XP as well as certain Mac OS X and Ubuntu versions using Direct Memory Access (DMA) properties of the FireWire Serial Bus Protocol-2 (SBP-2) over Thunderbolt. It can also dump physical memory contents of the victim machine over the FireWire interface, enabling reliable extraction of Mac OS X FileVault passwords and BitLocker, FileVault and Truecrypt encryption keysYou can read more about it and download it here.

By the way: This post could easily be renamed to “Hacking Macs (and soon PCs) through the Thunderbolt interface”. This is not an operating system issue, but rather an issue with the underlying hardware.

Background

For quite a few years now, attacks via Firewire / i.LINK / IEEE 1394 have been a known security issue. If you can get physical access to a machine with a FireWire port (or PCMCIA/Cardbus/ExpressCard expansion ports) you can (quote):

  • Read arbitrary RAM contents from the victim’s system.
  • Overwrite arbitrary RAM contents with whatever you want.
  • Perform many, many severe attacks based on the two issues above. Examples include grabbing a full RAM dump via Firewire (takes only a few minutes), grabbing ssh-agent keys, grabbing screen contents, modifying screen contents, bypassing login/password screens, and many, many more.
All of this is done by exploiting a “feature” of the Firewire spec (OHCI-1394) (PDF), namely that it allows read/write access to physical memory (via DMA) for external Firewire devices. Worse, as this is DMA, the CPU/OS will not even know what’s going on. Even worse, this works regardless of whether you have locked your screen with a password-protected screensaver, or xlock, or vlock, or whatever. As long as the system is running, you’re vulnerable.
As it turns out, these attacks may also be executed over Thunderbolt.

Set-up and execution

The Thunderbolt specs are not publicly available yet, but marketing material that has been released leads us to understand a few core aspects of Thunderbolt that has some interesting security implications:

  • Thunderbolt expands the PCIe bus – this is bad from a security perspective as any device that connects to the bus may use FireWire DMA on the bus to gain read/write direct access to the lower 4 GiB of host RAM, bypassing the victim processor and OS completely. In fact, Inception was designed to exploit this flaw in the IEEE 1394 FireWire standard.

Thunderbolt expands the PCIe bus

  • Thunderbolt supports daisy chaining of up to 6 devices – while this is good from a usability perspective, it means that an attacker can connect to an available port on a two-interface Thunderbolt device, and, through daisy chaining, gain the same DMA access as mentioned above to any other PC/Mac connected through the daisy chain to the same Thunderbolt device(s).

An example of Thunderbolt daisy chaining – now replace that monitor on the left with a rogue device

Let’s think about those implications for a moment. This means that using Inception, one could connect an attacking PC to a two-interface Thunderbolt device, hide the attacking PC away and stealthily steal RAM content from any PC or Mac that connects to the same Tunderbolt device. Except for possibility that the victim notices the extra Thunderbolt cable, this attack will likely go unnoticed.

To perform this attack, a few hardware components are needed:

The hardware is set up as follows:

                     Visible | Hidden
                             |
     TB                   TB |                                       FW
Mac <==> Little Big Disk <==> Sonnet Echo Adapter w/ FW ExpressCard <==> Attack PC
                             |
<==> = Connection            |
TB   = Thunderbolt           |
FW   = FireWire              |

Hotplugging a FireWire device into the Sonnet Echo device will multiplex/encapsulate the FireWire protocol within Tunderbolt signals. Ergo, all attacks that work over FireWire also works over Thunderbolt.

System information on the victim machine when connected with FireWire over Thunderbolt

As an example I’ve included sample output of the Inception tool below, where I’m using Inception’s pickpocket mode to let the tool wait until a device connects to the Thunderbolt daisy chain before dumping 4 GiB of RAM data to a local file on the attack PC. As a demonstration of what can be done with the RAM content, I’ve performed a simple strings search after my FileVault password (found and marked in red):

root@bt:~# incept --pickpocket

Inception v.0.0.6
by Carsten Maartmann-Moe <[email protected]> aka ntropy <[email protected]> 2012
Twitter: @breaknenter Web: http://breaknenter.org

For updates, visit/clone https://github.com/carmaa/inception or visit the
Inception homepage at http://breaknenter.org/projects/inception

[*] Lurking in the shrubbery waiting for a device to connect....
[*] FireWire devices on the bus (names may appear blank):
--------------------------------------------------------------------------------
[1] Vendor (ID): Apple Computer, Inc. (0xa27) | Product (ID): Macintosh (0xa)
--------------------------------------------------------------------------------
[*] Only one device present, device auto-selected as target
[*] The target seems to be a Mac, forcing override (not dumping 0x0-0xff000)
[*] Selected device: Apple Computer, Inc.
[*] Initializing bus and enabling SBP-2, please wait  1 seconds or press Ctrl+C
[*] Dumping from 0x0 to 0x100000000, a total of 4096.0 MiB
[*] Dumping memory, 4095 MiB so far
[*] Dumped memory to file memdump_0x0-0x100000000.bin
root@bt:~# strings memdump_0x0-0x100000000.bin | grep --after-context=3 managedUser | grep --after-context=1 password
password
THIS_IS_MY_PASSWORD
--
 |grep --after-context=1 password</strong>
password
root@bt:~#

I have posted a video of the attack here.

Why Apple thinks that the password should be loaded in memory in plaintext is beyond me. Remember, we also have write access to the lower 4 GiB of RAM on the victim machine, so I could also use Inception’s main mode to unlock the victim machine.

FUD disclaimer

Previous speculations to whether Thunderbolt is vulnerable to these types of attacks has been brushed aside as an attempt to spread FUD. To some extent I agree – this is not a remote attack, and it should probably not be on the top spot on most security analysts’ threat scenarios lists.

However, I strongly disagree with labeling this vulnerability as pure FUD for a number of reasons:

  1. People trust their hardware. Few expects that a seemingly benign device can behave badly. Imagine being hacked by a Thunderbolt display, a video projector or a hard drive. This is not something that an average user would suspect, and the fact that the attack is completely stealthy adds to the threat level. Physical access is an oft overlooked attack vector.
  2. Some people seem to think that physical access to a device means “game over” for security, and that one should treat a lost/misplaced device as compromised. While it is prudent to treat lost devices as compromised, I disagree about the notion that physical access equals a breach. In fact, most full-disk encryption systems are designed to protect your data in the event of a physical loss of a device. This tool is able to defeat full-disk encryption in many cases. Also, I still encounter people who is baffled over the fact that password-protecting your PC is a moot point if you’re not using full-disk encryption. Most end users (and many security experts) are not aware of the physical access vector, and often fail to account for it when planning their security approach.
  3. Lastly, some “threat actors”, such as the intelligence community, have actively planned creating devices that exploit FireWire DMA before. If you worry about foreign nations getting access to your system, this is a relevant risk for you to take into consideration.

This blog post is not intended to spread fear, but rather to educate users and enable them to make informed security decisions based on facts.

Caveats

There are some relevant caveats that you should be aware of:

  • We can only access the lower 4 GiB of RAM (due to the FireWire specs using 32 bits for addressing). Physical memory layout on machines with more than 4 GiB of RAM may further lower this limit
  • OS X Lion with FileVault enabled disables DMA when the machine is locked, however, the daisy chaining properties of Thunderbolt enables stealth attacks while the machine is unlocked. There are also ways to re-enable DMA, using user switching. See this blog post for a good overview
  • Macs with firmware (OF/EFI) password set is not vulnerable to this attack, as FireWire DMA is disabled when a OF/EFI password is set

To be vulnerable, a few key contiditons must be met:

  • The attacker needs physical access to your machine.
  • Your machine must be powered on or in stand-by mode (suspended). If you are not using full-disk encryption with a pre-boot authentication screen, you are of course vulnerable since an attacker can simply power on your machine and extract memory as soon as the OS is loaded. This also applies to BitLocker Transparent operation mode where the machine TPM chip is used to transparently load encryption keys without any pre-boot authentication.
  • FireWire SBP-2 drivers must be present and loadable.

Threat scenarios

After reading this, if you still think: ‘So what?’, here are a couple of relevant threat scenarios:

Covert operations / exploiting the daisy chain

Like discussed above, an attacker may hide the attacking device out of sight, while automatically attacking all devices that connects to the same Thunderbolt device as the attacker is connected to. This opens possibility of getting hacked by a wide range of devices. Fun weekend project: Try this at an Apple store.

Border control

Left your PC in standby mode on your business flight and had to hand it over to Chinese customs / border control? Say bye-bye to your passwords, encryption keys and any corporate secrets that you had on your software-encrypted laptop. If the government in democratic, European nations can use trojans to monitor criminal suspects, who knows what states that don’t hold privacy in high regards can do.

Targeted hacks against corporations

I’ve personally and successfully used the predecessor to Inception, FTWAutopwn, on several pentests to gain access to corporate networks. The methodology is simple:

  • Hack laptop over FireWire and dump memory, gain Local Administrator access
  • Dump cached credentials
  • Crack cached credentials, or if already on the corporate network, pass the hash
  • Use credentials to log into corporate network over VPN
  • Use normal Windows pentest methodology (user enumeration, enterprise-wide brute-force, cached credentials / cracking, etc.) to attempt to get Domain Administrator credentials

Further reading/mitigation

While there are few options for mitigation without loss of functionality (e.g., loss of FireWire transfer speed), a good overview of DMA-attacks and mitigation options can be found here. Also, someone raised this concern as related to Thunderbolt a year ago – only to be labeled as FUD.

A good overview of the Mac OS X FireWire DMA defenses and weaknesses can be found here.

Now, if someone please could point me in the direction of a battery-powered Single Board Computer with an ExpressCard or FireWire interface…

29 Responses to “Adventures with Daisy in Thunderbolt-DMA-land: Hacking Macs through the Thunderbolt interface”

  1. ellokaykay

    As you mentioned Lion makes it more difficult to use the Firewire DMA attack and that this is also true using the thunderbolt way.
    How about the OF/EFI password? If a password is set, DMA via Firewire is disabled in general (on MacBooks). Is this also true if you go the thunderbolt way?

    Reply
    • Carsten

      Correct, setting a firmware (OF/EFI) password will disable FireWire DMA, effectively mitigating the FireWire part of this attack (and greatly reduce the speed of any FireWire disks). Good catch, and added to the caveats section above.

      It is currently unknown whether it is possible to exploit “native” Thunderbolt/Displayport the same way, and whether a firmware password would mitigate that attack.

      Reply
        • Carsten

          I agree. That is the problem with proprietary technology – Intel is keeping the specs quite close to its chest as of now, making it hard to confirm whether there are similar flaws in Thunderbolt.

          Reply
  2. Bill

    Your comments on bypassing DMA protection on Lion seem to be about CVE-2011-3215. It would be interesting to see an update to this article describing the difference between 10.7.1 and 10.7.2, and how it affects this attack vector.

    Reply
  3. guns

    “FireWire SBP-2 drivers must be present and loadable.”

    Does this mean that merely unloading the FW/TB drivers with kextunload does not protect against these DMA attacks?

    Reply
      • guns

        Sorry, I’m still unclear. If I successfully unload `com.apple.iokit.IOFireWireSBP2` on my machine, FW devices do not seem to initialize.

        Are you saying that the kernel can be made to autoload the drivers on attaching a FW device? I can certainly see this happening, but it does not seem to be the behavior with my FW devices.

        Reply
        • Carsten

          Unloading the drivers permanently will cause the attack to fail. You will of course also loose FireWire SBP-2 (and as you write, potentially overall FireWire functionality), but that may be OK for many people.

          Reply
  4. ka_

    Apparently computers with Intel “VT-d” or AMD “HyperTransport” support and activated in BIOS need IOMMU for DMA access. IOMMU appears to resolve the issues with DMA at the expense of some performance degradation and additional RAM needed for the I/O page translation tables.

    Do you manage to launch a successful Firewire/Thunderbolt attack with VT-d or HyperTransport enabled in BIOS of the target machine?

    Of course – Mac’s use EFI instead of BIOS, and it can appear as a large number of Mac’s do not support “VT-d”. I am noticing Apple list some firmware to provide VT-d support for Xserve and Mac Pro machines ( http://support.apple.com/kb/index?page=search&product=&q=vt-d&src=support_site.kbase.search.searchresults ).

    Reply
    • Carsten

      AFAIK, VT-d is dependent on OS support to enforce DMA access:

      http://software.intel.com/en-us/articles/intel-virtualization-technology-for-directed-io-vt-d-enhancing-intel-platforms-for-efficient-virtualization-of-io-devices/

      So as long as the OS doesn’t support it, there’s no enhanced security. I’ve had people reporting that even with VT-d enabled, they enjoy unrestricted DMA through FireWire.

      I don’t have access to any hardware with the intel northbridge chipset at the moment, but if somebody is willing to lend me a specimen, I’ll test. Of course, if you have a chipset yourself you could test it with Inception.

      Edit: To add to the comment, pure hypervisors such as VMware ESX/ESXi has had VT-d support for some while, but to my knowledge there are no Windows or OS X operating systems that has VT-d support. Linux does have support through KVM, but doesn’t seem to support restrictions for FireWire devices yet.

      The problem with technologies like VT-d is that while they can be used to protect against DMA attacks, it still up to the OS to protect memory. Given the historical adoption rate that we’ve seen to mitigate DMA attacks so far, I wouldn’t expect OS support to be common in the next five years.

      Reply
  5. Satine

    “now replace that monitor on the left with a rouge device”

    Why does it matter what color the device is? :-)

    Reply
  6. Nickless

    Great tool you created!
    I’ve used it a couple of times against Linux and Windows machines. Now eager to try it against a MAC. At the beginning of your article you say that you’re using a Thunderbolt to Firewire adapter to hook up your attack machine to the victim machine. The link points to a ExpressCard Thunderbolt adapter.
    Would a simple Thunderbolt to Firewire adapter (http://store.apple.com/us/product/MD464ZM/A?fnode=51) also do the trick?

    Reply
    • Carsten

      Yes, it would (the only reason I used a thunderbolt to expresscard adapter is that thunderbolt to FireWire adapters didn’t exist at that point).

      I haven’t tested that particular adapter yet, so let me know how it goes.

      Reply
  7. Max Allan

    Interesting idea. Could the DMA attack also be carried out via a disk interface like SATA? A lot of laptops (and desktops) are coming out with e-SATA connectors now. Or you could perhaps hot-swap the CDrom out of the way.

    Reply
    • Carsten

      The last time I looked at the SATA standard, it looked like it includes provisions for mitigating this type of attack.

      Reply
  8. blur at

    "OS X Lion with FileVault enabled disables DMA when the machine is locked, however, the daisy chaining properties of Thunderbolt enables stealth attacks while the machine is unlocked."in this case,inception cannot unlock the locked OS-lion even with the thunderbolt daisy chaining??

    Reply
  9. crackruckles

    Could you run this on a raspberry pi device with a usb to firewire adapter, ive just bought a pi unit and am waiting for the adapter to arrive to try it out but what are your initial thoughts as it runs linux and with a little scripting could be setup to launch as soon as it is powered on making for a powerful little attack box.

    Reply
    • Carsten

      Sorry, you are probably going to be disappointed. See the troubleshooting section at the tool homepage.

      To get DMA you need a FireWire controller (hardware) on the attacking side. No USB to FireWire adapter I have seen has this, and it wouldn’t really make sense as FireWire and USB is fundamentally different technologies in terms of architecture. It is possible to send USB packets over FireWire, but not FireWire data over USB.

      Reply
  10. James

    Could Inception be used to carry out a DMA attack directly using Thunderbolt peer-to-peer (using a cable like this http://store.apple.com/us/product/MD861ZM/A/apple-thunderbolt-cable-20-m)? As you point out, FireWire uses 32 bit addressing, so one is limited to the lower 4 GB of memory. I know the Thunderbolt specs have not been published, but do we know if it uses 64 bit addressing? If so, using a Thunderbolt peer-to-peer attack could give access to a full 8 GB (or much more, obviously, up to 2^64 bytes).

    Thanks!
    James

    Reply
    • Carsten

      Haven’t tested two machines with Thunderbolt against each other, but in theory it should work. However, thunderbolt is a pure encapsulation technology (for PCI), and as you point out, the specs are not out yet. Hard to predict.

      Reply
  11. Iddd

    So if I am using a full encrypted Harddrive and have set a firmware password i am safe even in standby mode? As long my macbook is not logged in (and of course a password ist set)?

    And if yes which is the better alternative to safe my mac with filevault or truecrypt?

    Reply
    • Iddd

      Ahh and one more question how is it possible to full disable the thunderbolt ports in my mac? I am not using them and if there is a security leck i would like to close that.. Is that somehow possible?

      Reply

Trackbacks/Pingbacks

  1.  Attaque DMA : ça marche aussi en Thunderbolt | Le journal du lapin
  2.  Adventures with Daisy in Thunderbolt-DMA-land: Hacking Macs through the Thunderbolt interface | Break & Enter » sil3nt
  3.  And this, boys and girls, is why when traveling any distance we shut our Macs totally down #security – dropsafe
  4.  Week 6 in Review – 2012 | Infosec Events
  5.  Firewire Security Exploit Can Compromise Thunderbolt Computers [+ OS X Fix] | Obama Pacman
  6.  Video – Hacking OS X FileVault2 over Thunderbolt with Inception | Break & Enter - Improving security by breaking it
  7.  #breakingnews Still putting your PGP-protected PC in hibernate? $300 app can hack it |
  8.  Still putting your PGP-protected PC in hibernate? $300 app can hack itQuick iPhone Apps | Quick iPhone Apps
  9.  Still putting your crypto-protected PC in hibernate? $300 app can hack it (Updated)Quick iPhone Apps | Quick iPhone Apps
  10.  Using TrueCrypt on Linux and Windows | Doug Vitale Tech Blog

Leave a Reply

  • (will not be published)