EnCase 7 Anti-Foren...
 
Notifications
Clear all

EnCase 7 Anti-Forensic for Air-Gapped Examiner

11 Posts
6 Users
0 Likes
744 Views
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
Topic starter
 

Blog post on the same site that wrote about the EnCase concerns.

EnCase 7 user interface inconsistencies and file viewer configuration allows direct attack on a forensic workstation.
Some of you might remember 42.zip, a nested ZIP-bomb file, which would crash certain forensic tools after running out of memory. The following concern not only can crash the forensic workstation, but destroy the whole machine.

The combination of file type association with Windows as viewer, and the inconsistency of user interface in EnCase 7 can potentially launch malicious payloads from an evidential image.

Examiner's propensity to double-click can inadvertently launch such files, and pass the file to the examiner's workstation OS. With simple crafting the machine can be made inoperable, worse damage case information silently using previously demonstrated "concerns". (e.g. [1])

This has the potential to cause significant delays, or damage to case. In combination with our previous findings, such as the cache manipulation and the rendering folder retention, we can image serious complication.

 
Posted : 24/05/2016 9:28 pm
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

At first I was quite shocked as I thought it meant files which are previewed in the viewing pane could "escape" - but it seems that it is to do with launching files from within EnCase.

This is not really a true concern, as it is surely good practice for all examiners - to be wary of files you launch?

 
Posted : 25/05/2016 12:51 pm
(@thefuf)
Posts: 262
Reputable Member
 

Sometimes a real problem is staring at us in the face, but because we are so close to it, we are unable to recognize it. We do not believe anything what we demonstrate here is new, special or revolutionary. It is simply ignored.

Unfortunately, yes. LinEn Boot CD has issues with automatic code execution from evidentiary drives (when you boot it from USB). And many forensic Linux live distributions have similar issues too.

 
Posted : 25/05/2016 4:03 pm
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
Topic starter
 

…This is not really a true concern, as it is surely good practice for all examiners - to be wary of files you launch?

I think it is. Considering that (anecdotally) most labs do not abide by best practices, and clean the forensic workstation instances between cases and only work on a single case per instance, this can be a problem.

As they stated elsewhere, this might not be a major concern with petty crime, but nation-state and organized crime does and will invest heavily in true anti-forensics.

We also note that several tools bind the licenses to machines, thereby making wiping and rebuilding or re-imaging cumbersome at best. It is not unusual for us to see small digital forensic operations using the same machine from case to case, or with multiple cases simultaneously, and never wipe, rebuild or re-image the forensic workstation.

(emphasis added)

 
Posted : 25/05/2016 8:32 pm
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

I think it is. Considering that (anecdotally) most labs do not abide by best practices, and clean the forensic workstation instances between cases and only work on a single case per instance, this can be a problem.

As they stated elsewhere, this might not be a major concern with petty crime, but nation-state and organized crime does and will invest heavily in true anti-forensics.

We also note that several tools bind the licenses to machines, thereby making wiping and rebuilding or re-imaging cumbersome at best. It is not unusual for us to see small digital forensic operations using the same machine from case to case, or with multiple cases simultaneously, and never wipe, rebuild or re-image the forensic workstation.

(emphasis added)

But that is a problem with methodology, not with the software itself. By the same token, XWF suffers the same "Anti-forensic for Air-gapped examiner" problem because it too allows you to launch files using Windows. The article kind of mentions this in the sense that it says

Although this write-up is about an EnCase concern, the other leaders are not immune from tool validation issues.

But this is not a tool validation issue - it is a methodology issue.

I feel like this article is akin to saying "WE FOUND A SERIOUS PROBLEM WITH HDDs; they are unworkable once smothered in ice cream. DO NOT SOMETHER YOUR HDDs IN ICE CREAM!".

 
Posted : 26/05/2016 2:35 pm
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
Topic starter
 

I feel like this article is akin to saying "WE FOUND A SERIOUS PROBLEM WITH HDDs; they are unworkable once smothered in ice cream. DO NOT SOMETHER YOUR HDDs IN ICE CREAM!".

Not exactly. The problem the article points out is that too many forensicators do smother their HDDs in ice cream, and pretend that is okay.

(What kind?)

 
Posted : 26/05/2016 6:58 pm
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

I feel like this article is akin to saying "WE FOUND A SERIOUS PROBLEM WITH HDDs; they are unworkable once smothered in ice cream. DO NOT SOMETHER YOUR HDDs IN ICE CREAM!".

Not exactly. The problem the article points out is that too many forensicators do smother their HDDs in ice cream, and pretend that is okay.

(What kind?)

Ah, fair enough.

(A place in my hometown does Blood Orange ice cream. Pretty fantastic)

 
Posted : 26/05/2016 8:30 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Not exactly. The problem the article points out is that too many forensicators do smother their HDDs in ice cream, and pretend that is okay.

It seems to me that it goes even a little further, saying that many major players in the software industry manage to fill all the space around the forensicator workspace with (open) large cans of ice cream.
I.e. that for a distracted or busy forensicator it can be extremely easy to dip a hard disk in ice cream by mistake. 😯

(What kind?)

Buontalenti, a classic taste re-invented, JFYI
http//www.florenceinferno.com/the-invention-of-ice-cream-in-florence-history-and-legend/

jaclaz

 
Posted : 26/05/2016 9:39 pm
pcstopper18
(@pcstopper18)
Posts: 60
Trusted Member
 

So the gist is, as with many things in life, that convenience is not always better. I myself "refresh" my machine between cases even though the lab I work in doesn't have such a policy. My previous place of employment did which is why I suppose I have always endeavored to do so.

Fact of the matter is that this is more a user/examiner issue (including methodology). If the tools did not let you run things from within them then people would just export it out and run it locally. Same issue, same risk.

Though my lab has not reached this perspective (Yet! D ), I stress reimaging and standalone environments. That is not always desirable for some (or possible if your job is network-based), but one has to weigh the options AND risk….good proactive practice vs needed convenience.

Just my 2 cents…

 
Posted : 02/06/2016 6:42 pm
(@athulin)
Posts: 1156
Noble Member
 

But this is not a tool validation issue - it is a methodology issue.

A bit of one, a bit of the other.

A bit of tool validation Does the tool allow binaries to 'escape'? Can a mistake on the part of the analyst make that happen? If it happens, can it be traced? Deciding that it does, and under what circumstances is almost certainly a validation issue.

A bit of methodology once you know that the tool has those problems, and that they are correctly identified as risks, how have SOPs been formulated to contain them? And how are those SOPs applied and enforced?

I feel like this article is akin to saying "WE FOUND A SERIOUS PROBLEM WITH HDDs; they are unworkable once smothered in ice cream. DO NOT SOMETHER YOUR HDDs IN ICE CREAM!".

To me it looks more like We found a problem the HDDs you examine may contain malware. Saying 'don't examine HDDs that contain malware' … is not useful.

Accepting that these HDDs may be hostile, and possibly also realizing that the tools used for investigation were rarely built to be suspicious about disk contents, then threat analysis may begin.

I've handed a ISO 9660 image over to an unsuspecting analysis program, and seen it crash and burn just because the image didn't really conform to the assumed ISO 9660 rules that say that directories may not have themselves as subdirectories. If they really do … and the ISO 9660 parsing code of the tool isn't sufficiently suspicious about what it is doing … it loops, and loops, and loops … until there's ice cream all over the analyst's face.

But in the absence of tools that validate file formats or file system structures or look for anomalous content … there's little or no point in a SOP that says 'verify that the image to be analyzed won't break the analysis tool or cause anything else untoward to happen'. The problem is rather that the tool hasn't been validated handle also borderline or non-conformant structures safely. And that problem is because .. well, I hardly need to spell that out.

Don't think of polar bears.

 
Posted : 03/06/2016 12:19 am
Page 1 / 2
Share: