Debate Breaks Out over Breakable Forensics Software Charges

In a report set for Black Hat, iSEC outlines problems in software packages, while Guidance disputes the findings.

The fur is flying over a presentation, planned for Black Hat in Las Vegas Aug. 1, that security firm iSEC says will demonstrate how easy it is to break forensics software.

Forensics tools such as Guidance Softwares EnCase are used by law enforcement, enterprises and national security agencies for data recovery and investigation. As iSEC says in its presentation description, investigators use these tools for a range of functions, such as parsing dozens of different file systems, e-mail databases and dense binary file formats.

"Although the software we tested is considered a critical part of the investigatory cycle in the criminal and civil legal worlds, our testing demonstrated important security flaws within only minutes of fault injection," iSEC says.

iSEC is promising to present what it found after six months of subjecting leading forensics packages to exploitation techniques. The security firm also plans to release new file and file system fuzzing tools created specifically to put forensics software through its paces in the project.

Some of the problems iSEC claims to have uncovered are that forensics tool makers dont use protection for native code provided by platforms, including stack overflow protection and memory page protection, or safe exception handling.

"Forensic software customers use insufficient acceptance criteria when evaluating software packages. Criteria typically address only functional correctness during evidence acquisition when no attacker is present, yet forensic investigations are adversarial," iSEC says. "Methods for testing the quality of forensic software are not meaningful, public or generally adopted. Our intention is to expose the security community to the techniques and importance of testing forensics software, and to push for a greater cooperation between the customers of forensics software to raise the security standard to which such software is held."

Guidance, for one, isnt taking this lying down.


For insights on security coverage around the Web, check out Security Center Editor Larry Seltzers Weblog.

The Pasadena, Calif., forensics software maker, in response to the iSEC report—which it reviewed in advance of its general Aug. 1 release—dismissed the "minor" flaws iSEC found in six scenarios with EnCase Forensic Edition software.

"All of the testing involved intentionally corrupted target data that highlighted a few relatively minor bugs," Guidance said in a posting on BugTraq. "The issues raised do not identify errors affecting the integrity of the evidence collection or authentication process, or the EnCase Enterprise process (i.e., the operation of the servlet code or the operation of the SAFE server)."

Besides, Guidance claims, the issues raised have nothing to do with the products security, and the vendor says it "strongly [disputes] the implication that iSECs report exposes vulnerabilities or DOS vulnerabilities in its product.

"Forensic examiners will inevitably come across corrupted data on target systems from time to time; and in standard computer forensics training, including classes offered by Guidance Software, examiners are trained to account for such issues," the company said. "No software is completely crash-proof and there will always be anomalies, particularly involving extreme scenarios of corrupted target data."

BugTraq-ers are already kicking holes in Guidances protestations that the flaws found are "minor."

"By minor, you mean things like (1) where a disk image cannot be acquired or (2) that appears to cause an out-of-bounds memory operation or (3) which most likely has one hell of a race condition?" said one poster on BugTraq, in response to Guidances July 26 post.

The poster was also bemused at Guidances complaint that the exploits launched at its EnCase tool used "intentionally corrupted data"—an ironic plaint, given that "pretty much every exploit on the planet involves intentionally corrupted data."

iSEC, of San Francisco, reported on six specific problems. Guidance reiterated those problems, along with its response to each issue. As quoted from its BugTraq statement:

1. [Logical] Disk Image Cannot be Acquired With Certain Corrupted MBR Partition Table.Response: It should be no surprise to any computer forensic examiner that a logical copy of a volume may not be possible if that volume has a corrupted MBR Partition table. EnCase features an option to acquire the target media physically, rather than logically, to specifically account for this type of scenario. The authors ignored the option of acquiring the data physically. Also, by corrupting the MBR Partition table, the perpetrator would likely render his computer inoperable, which calls into question both the likelihood and feasibility of such a tactic.2. Corrupted NTFS file system crashed EnCase during acquisition.Response: The authors state that this issue appears to be caused by an attempt to read past the end of the buffer. However, EnCase features an option to de-select the automatic reading of the file system during the acquisition process. Thus, there is an easy work-around. Also, by corrupting the NTFS partitions, the perpetrator would likely render his file system dysfunctional, which calls into question both the likelihood and feasibility of such a tactic. Thus, the chances of this specific scenario occurring in the field are extremely remote; however, Guidance Software will test and, if verified, place this anomaly in its development queue to address the crashing problem in the future.3. Corrupted Microsoft Exchange database crashes EnCase during multi-threaded search/analysis concurrent to acquisitionResponse: The report discloses that this particular anomaly occurred only when every single check box was selected in the search dialogue box, including the search, hash value calculation and verify file signatures features. This means that EnCase was directed to acquire an Exchange database and perform a detailed multi-threaded search and analysis of the data at the same time. This procedure is extremely inconsistent with best practices and akin to opening several hundred files in a word processing program, which of course would cause a memory overload.4. Corrupted NTFS file systems Causes Memory ErrorResponse: As noted above, corrupted files or file systems can create challenges. The authors themselves note that the bug is minor, stating that they have not found any ill effects caused by this error condition other than an error being displayed and corrupted records not being displayed. In addition, they noted that they are unaware of any exploitable condition that arises from this error.5. EnCase Had Difficulty Reading Intentionally Corrupted NTFS File System Directory.Response: This issue involves the authors intentionally corrupting an NTFS file system to create a loop by, replacing a directory entry for a file with a reference to the directorys parent directory. Experienced forensic examiners are trained to identify such instances of data cloaking. The purposeful hiding of data by the subject of an investigation is in itself important evidence and there are many scenarios where intentional data cloaking provides incriminating evidence, even if the perpetrator is successful in cloaking the data itself. The chances of this specific scenario occurring in the field are extremely remote, but Guidance Software will test and, if verified, place this anomaly in its development queue to be addressed in the future.6. EnCase Crashes When Viewing Certain Deeply Nested Directories.Response: The authors created NTFS images with very deeply nested directories, causing EnCase to crash when it attempted to expand all deeply nested subdirectories. The simple workaround to this problem is to not expand all subdirectories, and to instead expand a portion of the subdirectories, or even just proceed directly with the searching and analysis of the acquired image. In addition, while Guidance Software maintains a robust in-house quality assurance process and strives to make our software as stable as possible, no software is completely crash-proof and there will always be anomalies, particularly involving the dramatic scenario manufactured by the authors here. In any event, Guidance Software will test and, if verified, place this anomaly in its development queue to be addressed in the future.

As of the evening of July 29, the tit-for-tat continued. The full threaded debate is here.

Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.