Posted February 6, 2012 by Carsten & filed under Hacking & Pentesting, Hacks, Security News, Tools & Methodology.

We 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 keys. You 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:

2x Apple Thunderbolt cables (1x will suffice if you don’t plan to exploit Thunderbolt daisy chaining)
1x Sonnet Echo ExpressCard/34 Thunderbolt Adapter (or equivalent)
1x Sonnet FireWire 800 Pro ExpressCard/34
1x FireWire cable
1x LaCie Little Big Disk (or any other device with two Thunderbolt ports, only necessary if exploiting Thunderbolt daisy chaining)
1x Attack PC running Linux

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:

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.
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.
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

Background

Set-up and execution

FUD disclaimer

Caveats

Threat scenarios

Covert operations / exploiting the daisy chain

Border control

Targeted hacks against corporations

Further reading/mitigation

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

Bill

Frank

guns

guns

ka_

Satine

Nickless

Max Allan

jen

blur at

crackruckles

Alex

Trackbacks/Pingbacks

Leave a Reply