PsExec can be a very useful tool during incident response and live forensics work. For those that don’t know, PsExec is a tool that can be used to execute commands on a remote Windows computer andwas initially developed by Sysinternals, which is now owned by Microsoft (additional details can be found on PsExec’s webpage).

However, it seems that PsExec has one significant shortfall – when utilizing the tool one must provide administrator-level credentials for the remote PC. These credentials are passed in the clear to the remote workstation (thus exposing the credentials to anyone who happens to be “listening in”). Thankfully, there is a workaround that can prevent this exposure from occurring, which involves connecting to the $IPC share on the target workstation first (with the admin credentials), prior to executing PsExec.

Security researcher Bernd Marienfeldt recently published his findings on the general state of iPhone security and has exposed a rather significant vulnerability present in the current iterations of the iPhone. It appears that even when the iPhone is set to require a PIN (plus encryption, in the case of the 3GS), that Ubuntu 10.04 (and probably any similarly configured Linux variant) will automount the flash storage on the iPhone, even when in a “protected state.” Marienfeldt states:

I uncovered a data protection vulnerability [9], which I could reproduce on 3 other non jail broken 3GS iPhones (MC 131B, MC132B) with different iPhone OS versions installed (3.1.3-7E18 modem firmware 05.12.01 and version 3.1.2 -7D11, modem 05.11.07) , all passcode (4 digits) protected which means the vulnerability bypasses authentication for various data where people most likely rely on data protection through encryption and do not expect that authentication is not in place.

Apple has been made aware of the vulnerability and has been able to reproduce it; however, they have not given any guidance as to when a fix should be expected.

Aside from the possible malicious consequences of this vulnerability, from a forensics standpoint, the vulnerability (while it lasts), could provide a duly authorized forensics examiner the ability to possibly access stored data on a seized iPhone, even when protected by a PIN and hardware encryption (in the case of the iPhone 3GS). Remember to remove the SIM card immediately upon seizure as an iPhone can be remotely wiped (given an active data connection), which will eliminate the possibility of data recovery.

A quick hint for a lazy Friday afternoon (actually I just finished analyzing and correcting a corrupt FAT table on a forensic image, so I’m not being lazy, I’m just tired :)):

Most forensic investigators generally acquire drive images to some sort of image file (i.e. RAW, etc). However, there may come a time when you need to provide a copy of the image on an actual drive (perhaps you need to give a copy of the image to a lawyer/client that doesn’t know how to deal with RAW image files) or you may, for convenience sake, decide to acquire an image directly to a spare hard disk that you have available. In order to prevent residue that’ll send you (or another investigator) down the road chasing your own tails, make sure to zero out your target drive prior to using it as a target for imaging (unless, of course, your image fills the entire drive completely). An easy way to do this on a Linux system is (replace <drive> with your target drive identifier, once attached):

Utilizing a proven write blocker is generally important and a best practice during forensic investigations in order to ensure and prove that your actions as the investigator did not affect the original image (best evidence). Notice my use of the word “proven” in the previous section – depending on the situation, it can be very important that you utilize a tested form of write blocking technology (software or hardware) and can prove that it was functioning at the time of the image acquisition. This means that you need to develop a (or use an existing) test protocol that verifies the functionality of your write blocker of choice, and I’d personally recommend that you run and document these functional tests immediately prior to your acquisition process in order to help alleviate any concern that your process tampered with the original image. You can find some significant documentation on testing write blockers on the NIST Computer Forensics Tool Testing Program site.

Of course, now that I’ve gotten that off my chest, let’s get down to the real reason for this post – hardware versus software write blockers. There seems to not be a great deal of resources comparing these two options and also some discussion surrounding whether a software write blocker can be a proven and effective method for image acquisition. I think that the answer is: “yes, it can be effective, but consider your options.” In order to assist with the evaluation of the two options, I’ve put together a little pro’s and con’s list (please feel free to suggest additional items to be added to this list or correct any wrong assumptions I may be making):

Hardware Write Blocker

Pros

Cons

Is not reliant on an underlying operating system or software-based subsystem.

Is easier to explain and generally makes more “sense” to non-technical people.

Clear visual indication of function through physical lights/switches.

Generally provides built in interfaces to a number of storage devices (IDE, SATA, etc.).

Appears to be more accepted in the general forensics community.

An additional piece of kit to carry around with you.

An additional piece of hardware that needs to be maintained and could fail.

Generally restricted to the available storage interfaces built into the device (additional interfaces cannot be added).

Software Write Blocker

Pros

Cons

The software write blocker is directly installed on your image acquisition workstation and additional hardware is not necessary (lightens the load, one less thing to fail, etc).

Generally able to use any interface available on your imaging workstation (and any interface that could be added down the road) – prevents an additional purchase when a new storage interface is needed.

Generally still needs an external adapter of some sort to provide an interface to the drives that you are imaging (thus negating the pro of not having to carry around a physical write blocker).

Can be more difficult to explain to a non-technical person (and thus more difficult to explain that the write blocker is actually functioning, if challenged).

A software write blocker can be implemented in a number of different ways (depending on the OS being used on the acquisition workstation, etc) and the current NIST CFTT test protocols for software write blockers only specifically deal with methods utilizing the 0x13 interrupt (however, they do state within their documentation that the tests can be adapted to other implementations). Given the number of possible differing implementations of software write blockers, it is very important that the person defending the process has a good deal of knowledge on how their software write blocking is implemented. Additionally, this person should be able to easily and clearly explain how the write blocker functions and prove that it was functioning at the time of the acquisition. Of course, the same requirements apply to hardware write blockers as well – although I find that, as mentioned above, they are easier to explain and appear to be more accepted.

As you’ve probably now guessed, when considering the information above and my personal workflow, I have decided that when needing to physically acquire an image that a hardware write blocker works better for me. However, that is a personal choice and from a technical standpoint a software write blocker (or similar proven functionality) can still be an effective and convenient method for preventing writes to an image. Is there anyone out there that utilizes software write blocking as their primary protection method during image acquisition? Has it easily held up to any challenge? Please feel free to comment…