Interesting Article: "Forensics software can be hacked"

Seems like a lot of hot air really - if this were something that defence lawyers were going to jump on, I would think that court cases would have gone something like this

"So you examined the image on a machine running Windows XP ?"

"Yes, I did"

"Isn't it possible that flaws in the OS could allow that machine to be compromised if connected to a network ?"

"It isn't connected to a network …"

"Yes or No ?"

"Yes"

"Defence rests …"

They have discovered about a dozen bugs that could be used to crash the programs

Anecdotal evidence suggests that Encase crashes daily without any help from attackers. )
….. and what of the OS that runs the programs?

Surely it's a prerequisite that _Any_ machine used in a forensic investigation must run in a sanitized environment, in that all software is verified as original, and proper controls are in place to ensure nothing can be introduced to the system that could subvert the process. ie virii trojan, spyware, malware, internet, etc etc.

This has little to do with the susceptibility of the forensic program to crash by whatever means.

Article looks little more than journalistic vapour. Brown smelling vapour at that twisted

kern

I noticed that Larry Gill wrote a reply to the authors of this research on the Bugtraq mailing list. You can read it at this address http//www.securityfocus.com/archive/1/474727/30/0/threaded

A few points that come to mind when reading it.

Point one I sort of agree with, apart from the proposal that you just have the option of doing an image of the physical drive. Sometimes you might not want to do that (maybe imaging RAID) so just providing this as a solution, even though I would almost always acquire the physical device, isn't really satisfactory. Besides, I've written disk parsing software in the past and admit that even partition tables can be a pain to get 100% right in all cases, but that's no excuse. Partition tables are much simpler to parse than file systems, and this is probably an easy fix. Assuming that a corrupted or inconsistent partition table would render the host inoperable is also a weak argument. For example, Brian Carrier mentions (I think in his book) a bit of surprise at being able to create a third entry in the extended partition (http//dftt.sourceforge.net/test1/index.html), but Windows mounts it correctly. If you write software that strictly adheres to standards and assumes that more fault-tolerant Operating Systems won't cope, expect bugs.

From the limited detail, I guess point 2 deals with "preview mode" as I could see no other reason why a piece of acquisition software should need to read the file system during imaging. Again, it is mentioned that the corrupted file system wouldn't work, but I know from experience that you can do all sorts of weird things with the beast that is NTFS and still have it work to some degree.

It does slightly trouble me that most of the replies revolve around saying that a user wouldn't possibly do such a thing. For example

3. Corrupted Microsoft Exchange database crashes EnCase during multi-threaded search/analysis concurrent to acquisition

Response 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.

I don't know, it seems like just the sort of thing that some people would do (click-happy, "gotta find the evidence!"). Assuming that a user should know how intense the processing for that scenario is a pretty weak argument and is easy to correct in code by deferring types of processing until a later time in the acquisition process.

I've got to pass on point 4 until I see the presentation because it lacks detail in the post. I would say that I hope that the displayed error is meaningful, so that an analyst might be able to diagnose what is wrong.

Points 5 and 6 deal with something that should never happen in the first place, and should have been caught in testing. They are both errors which are either a result of infinite loops or resource exhaustion (like zip-bombs which are how old?) and all it takes is a little bit of coding best practice such as loop detection to fix. This is interesting though

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.

I'd like to see an example of the infinite loop in Encase to see if it would look obvious that something nefarious is going on, or if Encase is just having problems. What he says about incriminating evidence is a little scary - I read it to mean that even though the data was never found you should assume the worst, much like if you found a blob of encrypted data on a disk. What happens if the NTFS driver has a problem and creates such a loop itself? Just thought I'd point it out.

On point 6

The simple workaround to this problem is to not ?expand all? subdirectories, and to instead expand a portion of the subdirectories

Again, this shouldn't be an issue and to say that users shouldn't use certain functionality of the UI even though they are provided access to it isn't really a good response. It should be highlighted that it is a temporary workaround (although he does say they will look into it and fix if required).

I understand that Larry is just doing some damage control in the light of rather public statements presented in the run up to Blackhat, and that they are looking into some of the problems. He does mention that people on Encase courses are taught how to deal with problems like this, although I only recall being told that if you find the software crashing on a particular image you can send it off to Guidance and they'll try to replicate and fix the bug. This is a good response, but not desirable if you are on a short deadline.

To conclude, it again boils down to the fact that people should not rely on a single tool for their job. I know people have said this numerous times before, but it is worth cross checking the results with other pieces of software. Encase crashes on acquisition? Use something like DD to do the job. If you have a problem with a nested directory structure, try checking it out in FTK (although I've found bugs that occur across multiple pieces of software, most of the time cross-checking would solve the problems).

Oh, and it's good to see that the Sleuth Kit is fixed already -)

Tom

Oh, and it's good to see that the Sleuth Kit is fixed already -)

I'm not doubting it, but where is this documented please?

<i>They have discovered about a dozen bugs that could be used to crash the programs…</i>

Okay, great. Anyone with a EnCase dongle and membership on the user's forum knows that this is already the case, without bugs. Not to bash GSI or EnCase, as other apps have similar issues, but really…this is <b>hardly</b> news.

<i>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.</i>

FYI, fellas…AF techniques do <b>not</b> constitute "hacking forensics tools". Sorry.

I tend to agree with some of the follow-on comments…if you're good enough to even be considering these techniques, I'd think that you'd be more interested in not leaving tracks. These kinds of techniques are more along the lines of "yes, I was here, but I'm going to try to blow up/subvert/cast doubt on your forensic application". Overall, this a bad idea…forensic analysts tend to have other tools and in particular processes at their disposal, so things like this really don't do much more than cause FUD for those who don't actually <b>do</b> forensic analysis. For those that do, articles like this simply make them revisit and verify their processes.

Harlan

While I agree with the idea that forensics and data cataloging software should be written with security in mind, I don't see how I'd make hay out of these. A half decent attorney on the prosecuting side would do a redirect examination to bolster their expert.

I still think the best way to nail an expert is to get them to overstate their findings or knowledge, then use your expert to beat them up.

http//isecpartners.com/files/iSEC-Breaking_Forensics_Software-Slides.BH2007.pdf