Let Me In

A few months ago I was doing some research regarding various ways incident responders could unlock both a live and dead system for an article I was publishing in Digital Forensics Magazine entitled “Let Me In”. If you’re not a subscriber to that magazine the article essentially listed some tools (Kon-Boot, Ophcrack ,Back Track, Inception etc.) and reasons for needing to perform such tasks (EFS, FDE, need to use the proprietary software on the system to open data etc.). While it was supposed to be in an earlier issue, it got pushed back to Issue 11 - May of 2012.

There was a good amount of content I had to trim out of that article so I decided I would write up a post to further elaborate about one of the sections – unlocking a live system. When I say ‘unlock’ I am simply referring to bypassing the authentication on the Operating System (OS) level and since Windows it is still the most dominant platform on the market it will serve as the main OS discussed. So why not just follow traditional methods and image the disk to perform forensics offline? There may come a time when you are presented with a locked system and are unable to shut it down because the volatile data is imperative to your investigation, it has Full Disk Encryption (FDE) or maybe it is a critical server. Whatever the reason may be, I asked the question - “What would you do?”

Considerations

Most modern techniques for unlocking a live system rely on the IEEE 1394, or FireWire interface. FireWire is a serial bus interface which allows for fast data transfer. The reason it is able to achieve this and why we care about it for Incident Response is because FireWire provides the ability to read/write directly to a systems memory through Direct Memory Access (DMA). By doing so, we are able to bypass the systems Central Processing Unit (CPU) and OS to circumvent any restrictions which would otherwise prohibit such ability. Before just jumping into trying these techniques you should test and validate your trials to ensure you are aware of the benefits, artifacts created and possible limitations. Some of the considerations that came to my mind were:

1. Will you have physical access to the system?
2. Does the target system have Full Disk Encryption (FDE)?
3. Is there a FireWire port on the target system? If not can you insert an expansion slot (PCIe, ExpressCards etc.) as an alternative for a missing FireWire port? Will that FireWire port suffice?
4. Whether or not the 1394 stack is disabled on the target system
5. What OS and patch level does the target system has?
6. How much Random Access Memory (RAM) does the target system has?
7. Did the FireWire driver install successfully on the target system?
8. Is this forensically sound and will it hold up as acceptable/repeatable if questioned in court? Let’s remember that if we choose to unlock the system we are actively writing back to the target system, which could mean we write outside of the memory we want or cause the system to blue screen.

Unlocking a live system with Inception

While the concept of using FireWire to bypass the Windows Lock Screen has been discussed and presented since 2004, most notably Winlockpwn by Adam Boileau which used raw1394, there wasn’t a whole lot of development or maintenance of such methods. During my research into this area I came across a tool called “Fire Through the Wire Autopwn” or FTWAutopwn which provided a more stable and reliable means than previous tools, such as Winlockpwn. This was because it incorporated a new open source library called libforensic1394, which uses the new Juju FireWire stack and allows you to present a Serial Bus Protocol 2 (SBP-2) unit directory with original FireWire bus information from your machine to the target system. As previously stated, my article got pushed back an issue and as luck would have it the author of FTWautopwn changed the tool to “Inception” which is the same project just renamed and updated since my initial testings.

If you’re interested in this topic I suggest reading this paper by Freddie Witherden.

Inception is actively maintained, which means its author is constantly adding new features, bug fixes, and more reliable unlocking techniques. I exchanged a few emails with the tools author back when I was testing the original FTWAutopwn and provided some feedback such as - when there’s multiple signatures/offsets for a target, if the correct combo unlocks the system then quit and don’t continue to try other combos. After going back to this tools site recently it appears new signatures and methods have been incorporated and a couple of the things I brought up have been addressed so it’s nice to see the active maintenance.

This tool works great for Windows XP SP0-3 and Windows 7 x86 SP0-1, however, it may be a hit or miss if you are trying it on Windows x64 systems based on my testing a few months ago - but again, you might have more luck these days. The main reason you might fail at unlocking is because the method it uses relies on the signature it is patching to be at a specific offset and on 64 bit systems the offset address is less stable and more likely to change. If the signatures and offsets within the configuration file are not working for your scenario and you have some disassembly knowledge, you can load the specific msv1_0.dll version into a disassembler and determine the signature/offset combination that you need to add to Inception. Instead of re-posting how to do this, check out moonloop and astr0baby.

In Windows, the Dynamic Link Library (DLL) msv1_0.dll is the Microsoft Authentication Package, which is responsible for validating a users’ password. Within this DLL is a function called ‘MsvpPasswordValidate’ which is responsible for performing a comparison between an entered password and the correct password. Inception patches this comparison to say that the correct password was entered regardless of what or if anything was entered at all. Since this is all done in memory, the patching is not persistent and restarting the system will restore to its normal authentication (that’s if all goes well of course).

Once you have your system properly configured and DMA access to your target system, choose which target you want to unlock and if you are successful you will see a screen similar to (screenie is from FTWAutopwn):

Dumping the memory of a live system

Besides for being able to unlock a live system on the fly, the libforensic1394 library also provides a means for dumping the memory of a live system. If you take a look at the authors’ paper he provided some additional insight of how to do this. The only additional requirement missing is a little knowledge of python. While doing my research I came across another paper where a researcher was testing Mac OS Lion memory acquisition using FireWire. While he also utilized the libforensic1394 library he additionally included a PoC python script to dump the memory of a live system. This was another bit of information I passed along to @breaknenter and looks like the updated tool incorporated this feature as well (score).

Start up script

Instead of remembering what commands need to be entered, what files need to be downloaded and what packages are required I wrote a simple setup script for BackTrack to automate the process. Additionally, it was written to be used with a non-persistent system (Live CD/USB) as well as a system with a persistent configuration. In my opinion, creating a USB with persistent storage works the best but if you are going to run this type of script on a non-persistent system, Internet access is required unless the files/packages required are downloaded prior and stored on some other removable media that would then have to be configured in the script as well. Since the tool has changed and the new version has its own setup script I’m not sure if it’s worth changing my start-up script :( … I don’t believe Inception checks for the all the required files (libforensic1394 etc.) and if you’re using Inception on a distro like BackTrack I don’t think it will set the environment accordingly so if I see a need I’ll make some modifications accordingly.