For windows: “Adam Boileau, a security consultant based in New Zealand has released a tool that can unlock Windows computers in seconds without the need for a password. By connecting a Linux machine to a Firewire port on the target machine, the tool can then modify Windows’ password protection code and render it ineffective. Boileau said he did not release the tool publicly in 2006 because ‘Microsoft was a little cagey about exactly whether Firewire memory access was a real security issue or not and we didn’t want to cause any real trouble’. But now that a couple of years have passed and the issue has not resolved, Boileau decided to release the tool on his website.”
For MacOSX: Python script which can extract username and login password from a mac running OS X tiger (going to test with leopard asap) via firewire using a linux laptop, based on great paper Hit By A Bus: Physical Access Attacks with Firewire by Adam Boileau. Once the attackers Linux laptop is connected to target machine via firewire, the password can be automaticly extracted from memory via firewire in about 10 seconds.
This hack exploits the fact that OS X keeps username and password in memory, even after a macbook is resumed from hibernation. Usin this technique a cracker can open the screen of a suspended macbook, wait until the unlock screen is displayed, plugin the linux laptop used for the attack to the firewire bus and run the password download script which extracs the password in under ten seconds.
The username and password is located in a memory page which can be identified by multiple static byte sequences. One of these sequences is a string dsAttrTypeStandard:UserShell which is located 1448 bytes from the start of the memory page. The attacker can simply iterate over every memory page and to look if this string exists 1448 bytes from the start of the memory page being iterated. Once this memory page has been identified and downloaded the script searches for string username inside this page. The actual username is a null ending string which starts at starting_offset_of_username_string + 12 bytes. The password can be found by searching string password and retrieving the actual password at starting_offset_of_password_string + 12 bytes.
This attack is very dangerous because it allows the attacker to gain access to a mac which is turned of into hibernation or suspend-to-disk mode. As Maximillian Dornseif presented in his keynote 0wned by an iPod the attacker can install Linux to a normal iPod and setup needed programs to implement a firewire memory attack. This means that the attacker needs just to carry an ipod with him, which is much less prone to attract security aware personels. Just wait for a goot moment, insert an iPod from your pocket into the target mac and login within a few seconds with the password you just extracted from the target machine memory.
EDIT: Some people have asked if similar attacks works in other operating systems. The answer is yes. I can also bypass a Windows XP SP2 login screen, just for an example. This was already proven by Adam Boileau last year (check out the link on the first chapter)
For Linux Mashine:
Maximillian Dornseif made a splash at CanSec in 2005 by hijacking Linux and OS X machines using a malicious iPod and the FireWire port. As it turns out, the “link layer” for FireWire —- OHCI, which is roughly to FireWire what Ethernet would be to 1000bTX if it included a standard programming interface —- supports direct DMA to host physical memory. You can plug a FireWire device in to a machine and read or write arbitrary physical memory locations.
Get a sense of what this looks like for an “attacker” from Maximillian’s own presentation. Then, note the table of systems “compatible” with the attack:
- OS X (supports read/write)
- FreeBSD (supports read/write)
- Linux (supports write)
- Windows 2000 (crashes)
- Windows XP (no support)
The reason Maximillian’s attack doesn’t seem to work against Windows XP is that OHCI specifies “Asynchronous Filter” and “Physical Filter” CSRs (a CSR is a hardware ioctl, by the way); if these CSRs are set to zero, the FireWire chipset will reject requests to access host physical memory. According to the spec, they default to zero. Windows doesn’t set them. So, by default, Windows disallows FireWire DMA.
I think this is pretty well known, but the attack does work against Windows (at least, pre-Vista). For instance, Adam Boileau showed that you can fake up a config ROM for yourself that, when read by the Windows host, will open up the filter CSRs. His attack basically advertises his machine as requiring DMA access, and Windows complies.
An attractive thing about both Maximillian’s and Adam’s attacks are that they’re implemented in Python; both quickly wrap the Linux or OSX FireWire APIs with Python bindings and then speak FireWire to the target with Python scripts.
I’m not particularly interested in “owning” my Windows box with FireWire, because I own my Windows box already. But I am interested in surreptitiously debugging my kernel and user processes that are aggressively rigged for anti-debugging. So I bought a $20 FireWire PCI card, and got Nate Lawson to talk me through disabling the OHCI Physical Request filters.
CSRs for PCI devices are mapped into memory; the host will typically map a block of address space just for the CSRs, which Windows will tell you about if you click on “Driver Details”; you want the smaller, 2-4k address range.
Unix and Windows ioctls have indexes or codes. In mapped memory, CSRs have offsets. The offsets we care about are 0×100 and 0×108 (the high and low 32 bits of the 64 bit AsynchronousRequestFilter) and 0×110 and 0×108 (the 64 bit PhysicalRequestFilter). Windows says my OHCI CSRs live at 0xdfbf8800 (phy addresses, not kernel virts). So I want to write 0xdfbf8900, 0xdfbf8908, 0xdfbf8910, and 0xdfbf8918; I simply want them to be 0xFFFFFFFF.
You can do this from any ring 0 code, or you can just use kd:
!dc dfbf8900 # see if they're already set
!ed dfbf8910 ffffffff
!ed dfbf8918 ffffffff # set the physical request filters
g
… and now Maximillian’s code will work against Vista (you can then disable kd with kdbgctrl.exe if you need to).
Note that a FireWire bus reset will clear these registers; the Windows OHCI driver will set the AsyncRequestFilter, but not the PhysicalRequestFilter, so you’ll need to repeat this process —- in particular, and annoyingly, every time you close your FireWire IOKit object on OSX. I got around this problem by writing a quick proxy from TCP to FireWire, which holds the object open and (so far) prevents the bus reset from getting me.
Obligatory “what does this let me do” graf? Adam and Maximillian explain it better, but the answer is, uh, anything? The FireWire chipset autonomously DMA’s host memory; if the kernel can’t keep the chipset’s CSRs configured to reject physical DMA requests, it can’t do anything to stop me from rewriting bits of the kernel or stealing crypto secrets out of memory.
