Black Hat 2007: Forensics software security holes revealed |
 |
By Michael S. Mimoso, Editor, Information Security magazine
02 Aug 2007 | SearchSecurity.com |
|
|
LAS VEGAS -- Vulnerabilities found in leading forensics software not only create a rich environment for denial-of-service and remote code execution exploits, but could lead a vigilant attorney to argue against the credibility of evidence collected by these tools.
Researchers from consultancy iSEC Partners presented that scenario Wednesday at Black Hat following the conclusion of a six-month study of Guidance Software's EnCase and the open source The Sleuth Kit (TSK). The findings have also been published in an iSEC Partners paper entitled, Breaking forensic software: Weaknesses in critical evidence collection.
The software, widely used in corporate circles for gathering evidence in civil and criminal litigation, or for human resource cases in-house, is susceptible to a number of nasty bugs including:
- Data hiding where the software fails to detect evidence stored in a specially crafted filesystem, essentially leaving it hidden in plain view.
- Code execution, where programming shortcomings lead to buffer, stack or heap overflows
- Denial-of-service bugs where an attacker might hide incriminating evidence in a file that repeatedly crashes the software.
ISEC tested Guidance EnCase and EnCase Enterprise -- which enable procurement of hard drive data and images over networks -- and TSK using blind fuzzing and targeted fault injection techniques.
"These products have ridiculously large attack surfaces and crash a million times," said iSEC principal partner Alex Stamos, pointing out that forensics software can read evidence stored in hundreds of file formats. "It can read anything, and that should be terrifying to people who use these products. Think about Microsoft Word; that's one format and it's had six remotely exploitable buffer overflows. The forensics problem is two orders of magnitude bigger."
Stamos was careful to point out that iSEC did not create any exploit code. "Our research indicates people should be prepared for an exploit to circle," Stamos said, adding that he's heard from several practitioners and read anecdotal evidence on message boards regarding similar experiences with the software crashing.
Guidance responded to the findings on the Bugtraq mailing list, and refused to call any of the bugs security vulnerabilities.
"All of the testing involved intentionally corrupted target data that highlighted a few relatively minor bugs. The issues raised do not identify errors affecting the integrity of the evidence collection… Moreover, the issues raised have nothing to do with the security of the product. Therefore, we strongly dispute any media reports or commentary that imply that there are any vulnerabilities or denials of service exposed by this report," Guidance said in a statement.
Chris Ridder, a fellow at Stanford Law School, said that given there aren't current exploits, theoretical assertions that perhaps evidence had been exploited would likely not get it tossed in court.
"If there are code execution exploits such that a given image might have been exploited, that changes the calculus a little bit," Ridder said. "The more likelihood of compromises circulating and the easier exploits are to do, and the less testing of these systems, now you're inching up to where evidence potentially is not being admitted."
|
|
|
|
