Blog: SANS Digital Forensics and Incident Response Blog

Blog: SANS Digital Forensics and Incident Response Blog

Arbitrary Code Execution on Examiner Systems via File Format Vulnerabilities

I attended ThotCon 0x1 on Friday, April 23rd, and watched a talk where the presenters disclosed and demonstrated an exploit embedded in a disk image that triggered arbitrary code execution when the same malicious file was examined using either EnCase or FTK. I'd like to talk a bit about this and it's implications, as well as a few things that we, as a community, might want to do in response.

The specific vulnerability in question appeared to actually exist in the Outside-In component, and was not triggered until the malicious file was actually viewed inside EnCase or FTK. The presenters stated that the vulnerability had been initially reported to Guidance and Access Data more than 3 versions of EnCase ago. Thinking back now, I was assuming they meant they had notified before 6.14, but it's possible that they were counting point releases.

When triggered, the exploit seemed to cause EnCase to crash silently, but FTK appeared to remain up, not that they did anything further with it after exploitation.

While this specific issue is a matter for some concern, more significant is the generic question of what other exploitable vulnerabilities may exist in commonly used forensic tools such as EnCase or FTK. Of particular concern would be any which could affect filesystem parsers, and thus might cause a payload to be automatically executed when a maliciously crafted subject image is first loaded into the tool.

I talked a bit with the presenters after their talk, and they told me that they had done relatively little to search for other vulnerabilities in either tool. They'd apparently just fuzzed shared components of FTK and EnCase (They never formally admitted that the vulnerability was in the outside-in library, but that was the consensus among the viewers.) until they found an exploitable condition. My impression was that it hadn't taken them long. They indicated their belief that there could be a plethora of other such issues in the code. I queried them regarding the possibility of such issues in the filesystem parsing code as well, and they indicated it was likely, but that they had not tested that code extensively. I didn't get into specifics, but it seems probable that they simply had better tools for fuzzing the file formats.

So what do we do, as users of these tools, as customers of the companies which produce them (or of the open source projects which generate them in some cases of the more general problem), and as forensic practitioners, to address and mitigate against this issue and others like it?

  • First, and most specifically, we need to universally view this particular bug with alarm, and call on both Guidance and Access Data to apply pressure on their common vendor to create a fix for the vulnerability which was exploited.
  • Second, and more generically, someone needs to be doing fuzzing against commonly used forensic applications. Since it's such specialized niche software, it hasn't gotten the kind of attention that's been focused on things like network-accessible Windows services to-date. The fact that the issue presented appears to have been discovered so easily suggests that this isn't currently being done by either Guidance or Access Data. As illustrated by Paul Craig's 'Hacking Scientists' presentation (audio) at Kiwicon 3 in Australia, fuzzing niche applications is an area that's now getting more attention in the industry. Once found, the issues need to be presented to the vendors, and if not promptly addressed, to the public at large. (I agree that public announcement is a debatable point, but there has to be some way to ensure that fixes for exploitable issues are appropriately prioritized.)
  • And lastly, in some environments, some forensic examination procedures or configurations may need to be modified to take into account the possibility that analyzing an image with a specific tool could cause arbitrary code to be executed on the analysis station. The following are a subset of the possible attacker actions which might need to be considered. I'm not saying these are likely today, but given the rising degree of capability in today's attackers, and the amount of money sometimes involved, I think it's probable that one or more of them will be attempted eventually, and we should do what we can to be ready for:
    • Code which seeks to actively mask specific evidence within a case.
    • Code which seeks to discredit the current analysis or the analyst performing it in some way. Perhaps hidden HTML code might be introduced into a report, which could be highlighted to indicate negligence or incompetence on the part of the investigator. Or on a network-connected workstation, a tunnel could be established to allow an attacker to perform arbitrary actions such as uploading inappropriate images to the investigator's Internet cache.
    • Code which seeks to discredit some other analysis.
    • Code which seeks to insert false evidence into this or another case
    • Code which seeks to exfiltrate data about work done on the forensic workstation where it is run. Possibly using the network, or using hidden files and/or automatic execution on inserted thumbdrives.
    • Code which seeks to delay processing of a case, perhaps by doing something as subtle as identifying a time intensive forensic operation, and inducing a crash in the application and corrupting the results after a long but variable period.
    • Code which seeks to identify an isolated forensic network (whether by scanning, or by simply piggy-backing onto normal usage) and infect other forensic workstations with itself to perform other actions as listed above.
Mitigating forensic procedure/configuration modifications could include any or all of the following, depending on your degree of concern and risk:
  • Running a host-based IPS on the analysis workstation
  • Running tools or configuring the host OS such that exploitation is more difficult. This includes measures such as enabling DEP and/or ASLR, and/or migrating to an OS which supports such measures, or more of them.
  • Maintaining forensic workstation patches & installed software versions at more current levels than might otherwise be done. Many examiners maintain their forensic workstations completely off the network, which increases the difficulty of performing updates, and may encourage the attitude that the specified systems are therefore unlikely to be compromised absent direct execution of a malicious binary. Additionally, some examiners are reluctant to upgrade their forensic tools due to the required expense.
  • Monitoring/examining forensic workstation logs for anomalies.
  • Re-imaging forensic workstations completely after each case, and only working one case at a time on each one.
  • Verifying all results across multiple completely separate forensic platforms.
As always, please feel free to leave commentary if you liked this article or want to call me on the carpet for some inaccuracy.


Posted April 27, 2010 at 12:50 PM | Permalink | Reply

Dave Hull

Great post John. Nice to hear about Thotcon, I hope I can go next year. If memory serves, this is not the first time vulnerabilities have been found in some of the forensics tools. I did a little Google searching, but my foo is failing me, but I'm pretty sure I remember reading about some researchers finding a similar flaw and discussing it at a con a few years ago. Definitely something we need to be aware of and something vendors should be attempting to eliminate.

Posted April 27, 2010 at 1:00 PM | Permalink | Reply


I already posted about this on the Guidance forums, and their response this morning was that the bug exploited in the presentation had been fixed since 6.15. I'm trying to get a confirm or deny from one of the presenters now. Stay tuned.

Posted April 27, 2010 at 2:25 PM | Permalink | Reply


I was @ the presentation as well. The bug is in fact in the viewer and not specific to any forensic tool. The bug would be triggered if you were using anything with the Outside In Viewer,

Posted April 27, 2010 at 3:01 PM | Permalink | Reply

Jon Stewart

It is good for forensic examiners to consider this vulnerability, and the general risks inherent in examining untrusted data. I think it is more a cause of alarm for examiners. Customers need to hold vendors to high standards, of course, but examiners need to appreciate the complexity of the software they use, the diversity of the data they examine, and then act accordingly. The recommendations for how examiners can mitigate this risk is a good start.

OutsideIn is... fragile. It's also the only game in town, used by content management systems, web search engines, and eDiscovery review platforms. FTK and EnCase already sandbox OutsideIn to a certain extent solely for the sake of reliability; to protect against embedded code vulnerabilities will probably require the move to a multiprocessing architecture using pipes and OutsideIn running without privileges or access to the filesystem. This is likely required for other complex parsing operations, not just OutsideIn, though DEP and ASLR certainly help. Architectural changes to complex applications like EnCase and FTK require time and attention; quick fixes shouldn't be expected, and may be riskier than leaving a particular vulnerability open. (EnCase users should be aware they can choose not to install OutsideIn, at the loss of the Transcript and Document views and indexing capability.)

Displeased with web browsers' general disregard for web standards, folks from the Web Standards Project created the ACID2 and ACID3 html rendering tests. At first, most browsers performed horribly, but the browser developers started competing to improve their scores, and now current browsers are largely compliant with accepted standards. Having a similar, independent suite of tests for forensics applications would probably be the best way to encourage forensic software vendors to address vulnerabilities and quality in general.


Posted April 27, 2010 at 3:41 PM | Permalink | Reply

Ron Weiss

John, very good points all of these. Just to point out wasn't there some sort of virus for X-ways a few years back. The need to document one's forensic system, configure it to an optimized and validated state, and then monitoring the integrity of the forensic system is becoming crucial, especially for systems conducting over the network collections. Examiners needs to keep documentation of their system as well.

Posted April 27, 2010 at 7:23 PM | Permalink | Reply

Jonathan Rajewski

Nice post! Do you know if the presentation is public?

Posted April 27, 2010 at 7:23 PM | Permalink | Reply


I've just received email from one of the presenters, confirming that the revision of EnCase in which they demonstrated the vulnerability was indeed current (( I have informed Guidance, and am awaiting their response.

Posted April 27, 2010 at 10:40 PM | Permalink | Reply

Cris Neckar

Thanks for the write-up you make some great points. We should have talked to you before our talk I guess ;)

I asked the ThotCon guys to add Greg and my e-mail addresses to the site so that people can contact us without jumping through hoops.

Posted April 28, 2010 at 1:09 AM | Permalink | Reply

Rob Lee


This is an excellent post. Honestly the implications of this are very broad. What a better way to gain access into the intelligence or information security industries best incident response teams by intentionally get caught and have the system examined via an exploited forensic tool.

It emphasizes the need for potential air-gapped or virtualized workstations for analysis. People tend to forget that you are examining potentially malicious code. All it takes is one to succeed.

Posted April 29, 2010 at 2:19 AM | Permalink | Reply

Dave Hull

Good point Rob, one that should be kept in mind by incident responders conducting investigations on live networks as well.

Posted April 28, 2010 at 2:09 PM | Permalink | Reply


This issue seems to be causing some consternation at Access Data as well. There currently appears to be some question among their people as to when, to who, and by who, this may have been reported. I've also confirmed with the presenters that, while the FTK version they exploited in the presentation was 1.81.6, they have independently verified that the current 3.1.1 is vulnerable. I'll post more updates as I hear things.

Posted April 28, 2010 at 3:33 PM | Permalink | Reply

H. Carvey

Great post...this was addressed within FTK Imager by Don Weber in the first edition of IntoTheBoxes:

Posted April 28, 2010 at 4:46 PM | Permalink | Reply


Update from the presenters. They had not noticed the April 8th FTK 3.1.1 release when they specified that the current version was vulnerable. The last version that they had tested with was, in fact, They have been in contact with Access Data, and have confirmed that the issue is fixed in 3.1.1.

Posted April 29, 2010 at 2:30 PM | Permalink | Reply

Loren Snodgrass

I'm having a hard time finding an authoritative source documenting this vulnerability in the Outside In Technology Viewer. Do we know what version(s) of the viewer are subject to the vulnerability? Can anyone point me in the right direction? TIA

Posted April 29, 2010 at 5:53 PM | Permalink | Reply

Bob walsh

Nice "post" but it would have been nice to have more technical details on what fails.

If it is an external viewer issue as H.Carvey seem to mention, its nothing impressive, if it does exploit the way Encase or FTK read a corrupted image file or case file or some specific file system structure then i would consider that it have more impact.

How would "preview" mode would be more dangerous than extracting a unknown executable and running it?


Posted April 30, 2010 at 1:19 PM | Permalink | Reply


The exploit seems to be in the Outside-In library. Harlan was talking about the preview pane in ITB, which I believe uses the same technology, but it looks like he was discussing the viewer's susceptibility to browser exploits, rather than to a possible buffer overflow issue in one of its file viewers, which is what this appears to be.

Posted April 30, 2010 at 1:27 PM | Permalink | Reply


Loren - I'd check the difference in Outside-In version between FTK and FTK 3.1.1.

Posted April 30, 2010 at 6:53 PM | Permalink | Reply


A bit of web research turned up the following link: No idea whether it's really related, but it seems likely.

Posted April 30, 2010 at 7:11 PM | Permalink | Reply


Just checked Outside-In versions in EnCase 6.16.1 (Vulnerable - and FTK 3.1.1 (Not Vulnerable -

Posted May 01, 2010 at 11:38 PM | Permalink | Reply

Cris Neckar

There is currently not a (public) CVE or other identifier associated with the issue we presented. Good guess with the iDefense disclosure but it's a different bug. The details will be discussed publicly when it has been fully addressed.

Posted May 03, 2010 at 8:18 PM | Permalink | Reply

Bob walsh it boils down to this mainly:

Post a Comment

* Indicates a required field.