iPhone vulnerability allows data to be accessed, even when protected by a PIN

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.

Additional information about this vulnerability can be found on Bernd Marienfeldt’s Blog and Ars Technica.

Prevent residue when imaging…

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

dd if=/dev/zero of=/dev/<drive>

Have a fun and safe Memorial Day weekend!

Write Blockers – Hardware vs Software

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).
  • Reliant on underlying and complex hardware and/or software (i.e. operating systems).  Interaction between these components creates additional complexity and introduces the possibility of failure through updates, upgrades, etc.

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…

What are alternate data streams?

Alternate data streams (sometimes referred to as ADS) are a way for a user to obscure files that they don’t want appearing within a file browser or a standard DIR listing (albeit they are easily discoverable with the right tools).  ADS is specific to Windows environments, specifically on NTFS filesystems, and has been around since Windows NT (and was most likely created to provide compatibility with HFS – the old Macintosh Hierarchal File System, and not intended for malicious purposes).  From a technical standpoint, alternate data streams are possible because NTFS MFT entries (how NTFS represents and locates files on the filesystem), are each capable of containing multiple $DATA attributes and thus a single MFT entry can actually point to multiple (and possibly unrelated) streams/files.

An alternate data stream is created by the use of a semi-colon separator between the existing filename and the name you’d like to use for your alternate stream.  For example, if I wanted to create/edit a text file contained within an attached to calc.exe (and given I had the rights to modify the MFT entry associated with calc.exe), I would use the following command:

C:\Windows\System32>notepad calc.exe:hiddentext.txt

And you then would be able to edit/save to your newly created stream – as you can see, the alternate stream does not have to be of the same filetype as the discoverable file – so the possible combinations are endless.  One can even place executable files within an alternate data stream using the type command, for example:

C:\Windows\System32>type evilfile.exe > calc.exe:evilfile.exe

Running an executable located within an alternate data stream requires the use of the “start” command (notice that I need to give start a resolvable path, even when I’m in the same directory as a file):

C:\Windows\System32>start .\calc.exe:evilfile.exe

Locating an alternate data strea is straight forward and a number of tools are available that will list them, including the DIR command in Windows Vista and Windows 7 (however, the DIR command still does not list alternate data streams by default).  A sampling of the available tools include:

Additionally, as mentioned above, if you’re running a Windows Vista or Windows 7 workstation, you can run DIR with a /R flag to show the alternate data streams within your current directory.

Utilizing alternate data streams is a very basic method for evading simple forensics techniques and a quick recursive scan looking for alternative data streams can sometimes yield interesting results when dealing with a less sophisticated subject (additionally, malware sometimes uses this technique to obscure related files).  In order to ensure that you don’t miss the low-hanging fruit during your investigation, or the lurking malware, consider adding an alternate data stream discovery step to your standard forensic analysis procedure.