Fighting Forensics

5:50 PM -- Ever heard of antiforensics? Don't be surprised if you haven't. It's only recently received mainstream recognition, partly due to a presentation scheduled this week at Black Hat USA 2007 by three researchers from ISEC Partners.

According to a new report, researchers have uncovered bugs in both Guidance Software's Encase Forensic software and Brian Carrier's open source SleuthKit.

While Guidance Software provided a particularly lengthy explanation (some might call it an excuse) as to why these bugs may or may not be worthy of attention, Brian Carrier has already patched the bugs found in the SleuthKit. How's that for open source software support?

Antiforensics isn't a new field of study, nor is it new to Black Hat. It's been covered several times since 2003, starting with the grugq's first presentation "The Art of Defiling: Defeating Forensic Analysis on Unix File Systems" and his second presentation in 2005, "The Art of Defiling: Defeating Forensic Analysis." The 2005 Black Hat conference also featured "Catch Me If You Can: Exploiting Encase, Microsoft, Computer Associates, and the Rest of the Bunch" from James Foster and Vincent Liu of the Metasploit Project's antiforensics team.

While antiforensics has been around for several years, the ISEC research takes a new tack. It mirrors the threats we're seeing in IT security -- more and more attacks that rely on user interaction and vulnerabilities in the user's software, not exploiting network services.

Before, antiforensics used techniques to alter the filesystem to obfuscate data, or simply destroy it in order cover attacker's tracks. Now, bugs in the forensic investigator's tools can be leveraged to crash the software preventing analysis or run arbitrary code on the investigator's machine.

Impossible, you (and Guidance Software) say? Here, swallow this red pill and realize a world where forensic tools have been introduced into court as a trusted part of a forensic investigator's methodology. Those same trusted tools can now be exploited to not only hide data in the current investigation, but in future investigations as well.

In this scenario, we see the equivalent of a rootkit hijacking the filesystem's API to prevent itself from being found. The simple act of analyzing a forensic image of a filesystem would exploit the forensic tool, causing the attacker's code to execute and patching the forensic tool's binary.

It then crashes the tool's current running process and causes the investigator to rerun the tool, which loads the patched binary. The attacker's tools and tracks are now permanently hidden, or even spoofed, in order to cause misdirection and lead the investigator along a wild goose chase.

Doesn't sound all that far-fetched, does it? Wondering why you spent all that money on forensic training and tools that may not live up to their promises?

Now take the blue pill. You'll wake up feeling right as rain -- as long as you don't remember what those guys from ISEC will be demonstrating this week.

— John H. Sawyer is a security geek who works in the IT organization at the University of Florida and enjoys taking long, warm walks on the beach and riding ponies. When he's not fighting flaming, malware-infested machines or performing autopsies on fried servers, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading