How to break forensics software

AN INTERESTING talk at Defcon was on forensics software, or more importantly how to break forensics software. The talk was given by ISEC Partners, and you can read the full white paper, and others, here.

The main theme of the talk is that forensics software does what it says, especially for the court approved versions, but they do still have weaknesses which can be exploited if you are crafty. Most of these can and will be fixed in the near future, but at least one is a design flaw, not a bug.

The main piece of software looked at was EnCase, a very common tool used by law enforcement and others. ISEC found a few flaws that could lead to evidence hiding, potential paths for code execution, evidence corruption and DOS attacks. Not all are practical , but many are theoretically possible.

ISEC tried a bunch of things to tease out the weaknesses, from the usual 'fuzzing', IE sending random crap at software to see if it blows up and then try to figure out why, to more targeted mangled data. Fuzzing is random, purposeful mangling has a bit higher success rate, but it takes much more effort.

One of the problems they found was that EnCase didn't like mangled MBRs, and from this they noticed that Linux and EnCase handled file systems in a completely different way. If you make a directory loop manually, EnCase hides all the files from that point on while Linux can see it just fine. Similarly, if you make a deeply nested directory, thousands deep with no other children, EnCase crashes. Both can be used to hide things, and both will be fixed in a near future revision.

One other potential way to hide data is to make lots of partitions, or 26 in fact. It seems that Encase can only see 25, possibly a legacy effect from the Dos lettering of file systems. Once again, this should be pretty easy to fix, but for now, it is a way to keep the good guys out of your files.

More troubling is the flaw they found in EnCase Enterprise (ECE), it is not a bug, nor can it be fixed easily. ECE is a version of the program that goes out and images drives remotely anywhere in the world, sending the data back to a repository for analysis.

ECE works by sending out a little 600k program that runs on host machines. An ECE server will then go out and check the program that was pushed out and see if it has the right keys. ISEC even believes it might check the IP it is going to as well, but that is about all it does.

The problem is that the program has the keys embedded. If you copy the binary to another machine, the new box will pass the most stringent of cryptographic checks because it 'is' the machine in question.

If you spoof the IP, a trivial thing to do, you are now the droids, umm, box, yeah box, the ECE server is looking for. In this way, you can essentially send a fake image to be analyzed and ECE will be none the wiser. It passes all the crypto checks, so it has to be right, right?

Until EnCase authenticates in other ways, the enterprise version is quite vulnerable. This will require more than a bug fix, it is a design flaw. They need to add another layer of checks to the program, and then it will be a lot safer. Moral, get a screwdriver and pull the drive just to be sure.

What ISEC demonstrated in the end is a bunch of ways to spoof and break one of the most popular forensic software packages out there. While most won't do this, and even more won't do this while the men in blue are kicking down their door, it is possible. That is all a good lawyer needs. µ