Episode 28 – Xerox This! – Forensic 4:cast

I just listened to your review of my blog posting from last week on my ride home yesterday. I have to say, I’m a bit disappointed by your guests take on it. Overall, I lean toward agreement with their points, and I think that the issues are more cause for concern rather than alarm, but I believe that minimizing the importance of this sort of thing would be a mistake. I have to say, listening to the commentary, that it didn’t sound as though your guests had actually read all the way through the posting. To quote from it, “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”. I think my points in the posting are both well qualified and pertinent.

I also wrote the following (possibly overenthusiastic, but well argued nonetheless) response to someone on the Guidance forums who suggested that the issue wasn’t a problem, since the demonstrated exploit didn’t cause the case evidence to be corrupted or misrepresented. (The remaining text is copied and pasted from that response.)

I got a little excited by your response. Please excuse the bold text and exclamation points, but I believe they’re warranted.

Technically, you have a point. This particular implementation of the exploit for the specified vulnerability neither corrupted nor misrepresented the evidence in the case. Further, as the exploit caused an actual crash in EnCase, you could assert that an examiner encountering this particular implementation might be alerted to possible malicious activity…

Hogwash!!!!

What part of the phrase ‘Arbitrary Code Execution’ did you fail to comprehend?

First of all, this exploit could have done anything at all to the analysis system, up to, and including simply restarting EnCase from the original case file or a recent backup of it. The local copy of the evidence could have been arbitrarily altered, especially given what was recently published by 42llc on issues with the E01 format. Admittedly, such alterations would have changed the hash of the file, but do most examiners manually recheck their E01 image hashes before and after processing? I may be doing various and sundry a disservice here, but I expect many people take the evidence image hash for granted as long as EnCase doesn’t complain about something.

Secondly, is anybody who uses the product a significant amount actually shocked when EnCase crashes? Much less expect to find some cause other than bugs in the software? I’ll admit it crashes much less frequently than it used to back in the 6.08 days, but I’ve still had it do so (non-repeatably) at least a half dozen times in the last few months.

Finally, while this particular implementation of the exploit did, in fact, cause EnCase to crash. There is no way to be certain that the crash is a guaranteed sympton of exploitation. In fact, exploitation of the exact same vulnerability in FTK (note that most believe the vulnerability to actually reside in the Outside-In library, which is probably identical between the two products) did NOT result in a crash. The generation of this sort of exception is most likely runtime dependant, and its likelihood could have probably been reduced by the presenters with more work.

Are you going to actually sit there and assert that you’re comfortable with some subject inserting data into his drive which will automatically cause the silent execution of code of his choice if/when that data is ever examined with EnCase? Please tell me you’re not saying that! While I don’t imagine it’s terribly likely, at the moment, it’s far from impossible that someone might encounter an exploit such as this that had been configured to do intelligent things on an isolated examiner station. The mind boggles at what might be accomplished on a forensic workstation connected to an internal network with any sort of internet access. Further, given subjects with funding such as could be provided by various criminal or government organizations, reconnaissance in advance could allow such malware to be custom-tailored for the environment in which it might most likely be examined.

The bottom line is that while I’m not sure this specific bug represents an immediate threat to most organizations, I do believe that as a class of vulnerability, it has a very serious probable impact on the future of our professional discipline. My expectations are:

1. That issues like this should be taken very seriously by Guidance.
2. That this particular bug should be patched within a few months at most.
3. And that Guidance will put into place a testing regime, incorporating file fuzzing, that will render a repeat of this substantially less likely.

I hope I didn’t take your eyebrows off with that…

4 responses to “Episode 28 – Xerox This!”

John McCash says:
May 6, 2010 at 12:53 pm
I just listened to your review of my blog posting from last week on my ride home yesterday. I have to say, I’m a bit disappointed by your guests take on it. Overall, I lean toward agreement with their points, and I think that the issues are more cause for concern rather than alarm, but I believe that minimizing the importance of this sort of thing would be a mistake. I have to say, listening to the commentary, that it didn’t sound as though your guests had actually read all the way through the posting. To quote from it, “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”. I think my points in the posting are both well qualified and pertinent.
I also wrote the following (possibly overenthusiastic, but well argued nonetheless) response to someone on the Guidance forums who suggested that the issue wasn’t a problem, since the demonstrated exploit didn’t cause the case evidence to be corrupted or misrepresented. (The remaining text is copied and pasted from that response.)
I got a little excited by your response. Please excuse the bold text and exclamation points, but I believe they’re warranted.
Technically, you have a point. This particular implementation of the exploit for the specified vulnerability neither corrupted nor misrepresented the evidence in the case. Further, as the exploit caused an actual crash in EnCase, you could assert that an examiner encountering this particular implementation might be alerted to possible malicious activity…
Hogwash!!!!
What part of the phrase ‘Arbitrary Code Execution’ did you fail to comprehend?
First of all, this exploit could have done anything at all to the analysis system, up to, and including simply restarting EnCase from the original case file or a recent backup of it. The local copy of the evidence could have been arbitrarily altered, especially given what was recently published by 42llc on issues with the E01 format. Admittedly, such alterations would have changed the hash of the file, but do most examiners manually recheck their E01 image hashes before and after processing? I may be doing various and sundry a disservice here, but I expect many people take the evidence image hash for granted as long as EnCase doesn’t complain about something.
Secondly, is anybody who uses the product a significant amount actually shocked when EnCase crashes? Much less expect to find some cause other than bugs in the software? I’ll admit it crashes much less frequently than it used to back in the 6.08 days, but I’ve still had it do so (non-repeatably) at least a half dozen times in the last few months.
Finally, while this particular implementation of the exploit did, in fact, cause EnCase to crash. There is no way to be certain that the crash is a guaranteed sympton of exploitation. In fact, exploitation of the exact same vulnerability in FTK (note that most believe the vulnerability to actually reside in the Outside-In library, which is probably identical between the two products) did NOT result in a crash. The generation of this sort of exception is most likely runtime dependant, and its likelihood could have probably been reduced by the presenters with more work.
Are you going to actually sit there and assert that you’re comfortable with some subject inserting data into his drive which will automatically cause the silent execution of code of his choice if/when that data is ever examined with EnCase? Please tell me you’re not saying that! While I don’t imagine it’s terribly likely, at the moment, it’s far from impossible that someone might encounter an exploit such as this that had been configured to do intelligent things on an isolated examiner station. The mind boggles at what might be accomplished on a forensic workstation connected to an internal network with any sort of internet access. Further, given subjects with funding such as could be provided by various criminal or government organizations, reconnaissance in advance could allow such malware to be custom-tailored for the environment in which it might most likely be examined.
The bottom line is that while I’m not sure this specific bug represents an immediate threat to most organizations, I do believe that as a class of vulnerability, it has a very serious probable impact on the future of our professional discipline. My expectations are:
1. That issues like this should be taken very seriously by Guidance.
2. That this particular bug should be patched within a few months at most.
3. And that Guidance will put into place a testing regime, incorporating file fuzzing, that will render a repeat of this substantially less likely.
I hope I didn’t take your eyebrows off with that…
Lee Whitfield says:
May 9, 2010 at 12:49 pm
John, I have nothing but love for you, I hope you know that. There aren’t many people that will say what they’re thinking.
I agree that it is something that needs to be addressed but I’m also unsure as to whether this attack vector will ever be used. If someone is capable enough to take advantage of this exploit then wouldn’t they just take other steps to prevent the data being read in the first place?
I would love to hear your thoughts on this.
BTW sorry it took so long to approve the comment, for some reason it was marked as spam and I didn’t see it until just now.
Ryan says:
May 28, 2010 at 4:04 pm
when can we see (…hear rather) the next episode?
Lee Whitfield says:
May 28, 2010 at 9:34 pm
Ryan,
Glad to hear from you. We’ll hopefully be recording another episode this Sunday. Sorry about the delay here but there’s a lot going on in my personal life at the moment. You can read about it on my family website here: http://whitfields.org/2010/05/16/children-and-pregnancy
I’ve got a lot going on besides this too. All will be revealed very soon…

Episode 28 – Xerox This!

4 responses to “Episode 28 – Xerox This!”

Leave a Reply to Lee Whitfield Cancel reply