Post Process

Everything to do with E-discovery & ESI

Archive for the ‘Guidance Software’ Category

Forensically Sound?

Posted by rjbiii on July 28, 2007

According to ISec Partners, Inc., forensic software (specifically, EnCase and The Sleuth Kit) that many forensics teams use is not as secure as it ought to be. From a post on D’Technology Weblog:

The San Francisco security company has spent the past six months investigating two forensic investigation programs, Guidance Software Inc.’s EnCase, and an open-source product called The Sleuth kit. They have discovered about a dozen bugs that could be used to crash the programs or possibly even install unauthorized software on an investigator’s machine, according to Alex Stamos, a researcher and founding partner with Isec Partners.

Researchers have been hacking forensics tools for years, but have traditionally focused on techniques that intruders could use to cover their tracks and thwart forensic investigations. The Isec team has taken a different tack, however, creating hacking tools that can be used to pound the software with data, looking for flaws.

ISec has yet to divulge the exact nature of the flaws, but will reveal some details at the upcoming Black Hat convention in Las Vegas. The Black Hat website says that the Isec discussion will make these points:

  • Forensic software vendors are not paranoid enough. Vendors must operate under the assumption that their software is under concerted attack.
  • Vendors do not take advantage of the protections for native code that platforms provide, such as stack overflow protection, memory page protection), safe exception handling, etc.
  • 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.
  • 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.

Along with this information is the announcement that:

We will release several new file and file system fuzzing tools that were created in support of this research, as well as demonstrate how to use the tools to create your own malicious hard drives and files.

Some of you may have seen an earlier article concerning anti-forensic tools that are already widely used. From that article:

The investigator (who could only speak anonymously) wonders aloud what other networks are right now being controlled by criminal enterprises whose presence is entirely concealed. Computer crime has shifted from a game of disruption to one of access. The hacker’s focus has shifted too, from developing destructive payloads to circumventing detection. Now, for every tool forensic investigators have come to rely on to discover and prosecute electronic crimes, criminals have a corresponding tool to baffle the investigation.

This is antiforensics. It is more than technology. It is an approach to criminal hacking that can be summed up like this: Make it hard for them to find you and impossible for them to prove they found you.

An InfoWorld article mentions that The Sleuth Kit has already patched the flaws, so those bugs will be revealed. What details concerning the deficencies found in EnCase depends much upon what actions Guidance has taken by the time of the conference.

Guidance software, in the person of Larry Gill has now publicly responded to these concerns.

As a result of this extensive testing regimen, they were able to identify six test scenarios, out of ?tens of thousands? of test scenarios run, that apparently revealed minor bugs ? in some cases for which there are straightforward workarounds ? in our EnCase® Forensic Edition software. 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 or authentication process, or the EnCase Enterprise process (i.e., the operation of the servlet code or the operation of the SAFE server). Moreover, the iss
ues 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.

(Excuse the rogue question marks, these are displayed in the response, and represents character translation issues).
One additional point of interest in Mr. Gill’s response, as noted in a slashdot post, may cause those concerned with legal issues to pause. Here is Mr. Gill’s 5th point:

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 directory?s 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.

I think it obvious that the “masking” or “cloaking” of data is not always evidence of wrongdoing. The slashdot post takes issue with such an argument in this manner:

That begs the question: if one cloaks data by encrypting it, exactly what incriminating evidence does that provide? And how important is that evidence compared to the absence of anything else found that was incriminating? Are we no longer allowed to have any secrets, even on our own systems?”

As Michael Caloyannides wrote in his book, Computer Forensics and Privacy, “[t]he right to privacy is not a ‘cover for crimes,’ as some law enforcers would assert.”

As a final thought, I would emphasis that the flaws in software is likely the least important item in any basic civil discovery process. An element of truest is imbued within the whole concept of civil discovery, and while strict forensic methodologies and tools are sometimes required, it is not typically necessary. What any discovery team should be focused on is the reasonable nature of the total process, from data collection to data processing, to document review. The processes used should reasonably be expected to find relevant documents, and initial assumptions (such as data custodians and search criteria) should undergo a verification process to ensure their effectiveness. But this is a discussion for another post.

Posted in Computer Security, Data Management, EnCase, Forensics, Guidance Software, Privacy, The Sleuth Kit | 1 Comment »