Notifications
Clear all

EnCase 7 concerns

12 Posts
4 Users
0 Likes
1,083 Views
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
Topic starter
 

Two blog articles

EnCase 7 Case Container Concern

EnCase 7, including EnCase Forensics, and EnCase Enterprise of all version 7 uses a combination of files and folders to store a forensic case work and details, the Case Container [Figure 1]. These files are interlinked with internally generated 16-byte long global unique identifiers (GUID). These identifiers are generated the first time the item is evaluated, be it when the items is brought into EnCase, or later, when parsed for further information. Almost all objects within the Case Container get a GUID.

Compound files, registry hives, mail stores, and certain results, when processed, the original data is copied into a parsed storage. The results are stored in reference or cache files, each with new GUID. The new GUIDs are linked back in several places within the case container. The cache files are stored in logical evidence file format (L01).

The security concern allows substituting evidence cache from a difference evidence source, by modifying the case container. No default internal or validation errors will occur. To detect such change the case would require reprocessing either in EnCase or another tool.

EnCase Forensics and Enterprise 7.x lacks security or relationship validation between case container and case cache items.

and

EnCase 7.x Evidence Leakage

EnCase 7, including EnCase Forensics and EnCase Enterprise of all version 7, uses internal viewers for several data structures, including electronic mail (e-mail), and their attachments.

When viewing e-mail records through EnCase Forensics and Enterprise 7.x, temporary files are created outside of the user-defined case folder structure. The temporary files can be full e-mails and e-mail attachments. The files remain after closing the case and the EnCase application. All cases use the same folder or subdirectory, intermingling, without any specific isolation.

 
Posted : 27/07/2015 5:26 pm
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

The first issue is somewhat of a concern and warrants further investigation - although more for the sake of detecting errors than anything else. To suggest that data might be replaced for malicious purposes seems a bit like scare-mongering.

The second "issue" is a non-event.

Exploitability

As long as the attacker has read access to the Program Files\EnCase7\Links folder..

So in this situation the attacker has full access to our OS - and we are worried about some temporary files from a case we're working on? Couldn't they, instead, just read our case notes? Our personal email which gives case details in full? *shakes head* Missing the forest for the trees IMO.

Also

Using a clean forensic workstation each and every time may also reduce or eliminate the possible evidence leakage.

Interesting methodology. Does anyone else here use a completely fresh install each time they start a case?

 
Posted : 29/07/2015 12:53 pm
pcstopper18
(@pcstopper18)
Posts: 60
Trusted Member
 

Depends on what is meant by "completely fresh install."

Many people use VMs with snapshots or have full images of the workstations which they then restore before starting a new case. The most popular of the two depends on the environment.

I know of no one who reinstalls the OS from a system/retail/OEM medium before every exam. Inefficiency to the max…

 
Posted : 31/07/2015 9:57 pm
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

..ave full images of the workstations which they then restore before starting a new case.

Really? I am astonished. What's the reasoning behind this?

 
Posted : 03/08/2015 12:47 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

@pcstopper18
Yep, definitely restoring an image as opposed to "new install", as a matter of fact it is "restoring to a condition identical to a new install".
Or use a (read only) WinFE, or possibly something similar to good ol' DeepFreeze or SteadyState, and sdelete the unallocated space.

..ave full images of the workstations which they then restore before starting a new case.

Really? I am astonished. What's the reasoning behind this?

Avoid (radically) any form of "cross-contamination" (between cases) and "external contamination" (from the case to the OS), this latter being less probable on a correctly managed case, but still theoretically possible.

Not entirely different from the wiping of disks used for storing case images, it may be overkill, but it saves time in Court
http//www.forensicfocus.com/Forums/viewtopic/p=6578391/#6578391

jaclaz

 
Posted : 03/08/2015 2:05 pm
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
Topic starter
 

In the comments there is a response to where this clean workstation comes from

Some have asked for citation of "best practice" for reimaging forensic workstations.

Watson, David, and Andrew Jones. "Digital forensics processing and procedures Meeting the requirements of ISO 17020, ISO 17025, ISO 27001 and best practice requirements." 9.8 Preparing The Forensic Workstation. p. 389 (2013).

VMs, with clean instance, or re-imaged from known setup is the same as using new build from what I can tell in the ISOs.

 
Posted : 04/08/2015 12:32 am
pcstopper18
(@pcstopper18)
Posts: 60
Trusted Member
 

Sorry, just now seeing the responses…

@Chris_Ed

Yep, what jaclaz said. I don't know that one can call it an out-and-out "issue," as it is really just a difference in perspective, legal vs technical, but when dealing with digital examinations for US criminal or even civil court as I do, "best practices" have always been to go above and beyond to wipe out the opportunities for the opposing side to question the integrity of your exam. As previously stated, the idea is to prevent cross-contamination, which is very big and real for the traditional hard sciences and easily understood as a "no-no" by juries and layman, even if digital machinations don't work quite that way or can even be avoided with good organization and case management.

If done regularly, the whole process can be automated to ones preference.

For those who do in-house digital, and incident response, it obviously doesn't matter so of course you wouldn't do that as a "best practice" unless your systems/tools/organization relied on very specific software that need to be maintained in a very specific way.

 
Posted : 08/08/2015 1:32 am
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

I am still astonished, although to be honest I'm not surprised that this might have come from The Many Armed Beast, aka ISO17025. And one person's interpretation of how to abide by those standards does not neccessarily make it Forensic Law, although I accept that if you're going over and above it might be good practice.

I have been to court at almost every level here in the UK and cross-contamination of the forensic workstation has never, ever come up - in fact I hadn't heard of it until this article, even in discussion with my peers. Interesting stuff, but it does present a bit of a question. If you are mitigating the risk of cross-contamination by reinstalling an image, do you wipe the drive first? And how do you manage multiple cases at once (maybe you don't)?
If you're using a VM, do you wipe the sectors the VM will occupy? Do you house it on a fresh, wiped HDD? Enquiring minds would like to know!

To go into detail a bit more about the second "issue" - it is irrelevant because I personally don't expect EnCase to compartmentalise data especially well, certainly when it comes to temporary files. If it is getting "confused" and presenting files as being present on E01s where they're not, that's a big issue. But that doesn't seem to be the case - the actual issue put forward related to it is this

As long as the attacker has read access to the Program Files\EnCase7\Links folder, the contents can be retrieved for all previous cases where e-mail was processed and viewed.

The exploitation has a low complexity, requiring tools built into Microsoft Windows operating system.

To me, this is the same as saying "Microsoft Outlook is not a very good mail client because if a guy has access to your local machine he might be able to read your email" or "passwords are terrible because if a guy installs a keylogger then he can access everything" or "my safe at home is insecure because if someone is actively looking over my shoulder while I lock it then they can access it". I mean, of course you will have problems if an attacker has read access to almost any part of your filesystem. This doesn't make the software inherently flawed.

If these mysterious dudes at forensium came forward and said "listen, EnCase 7 saves files in a weird place and it is possible that it re-uses them across multiple case files, so your case data might be invalid in certain situations", oh man! That is serious business indeed. But that is not the case.

P.s, on a related note - I don't get the "secrecy" around that site, either. Which is probably what lead me to being overly-fickle about the content. *rolls eyes*

 
Posted : 10/08/2015 12:14 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

As I see it, they are two separated issues.

One is a (IMHO rather "strict") implementation of ISO 17025 (or whatever senselessly applied industrial norm/standard), there is no real technical reason to re-deploy from an image, given that a number of common, normal precautions have been taken to avoid the machine to be infected, though nonetheless it is a certain way to exclude it.

To bring this on more common cases of cross-contamination in - say - hospitals, the protocol prescribes to change your latex gloves after having touched anyone and before touching anyone else, but the base idea is that any substance, virus, whatever, can spread and is transmitted by contact.

Which is of not the case of a file, particularly not for a non-executable data file, that will peacefully live its life contained in its folder unless manually or programmatically moved/copied/etc.

If you think about it a little it may even be actually counterproductive. 😯
I mean, of course extremely rare to happen in real life, let's say that by accident your forensic machine happens to catch today - say - if not a virus, any other file (let's say an update of a program) that due to some strange quirk produces an invalid result in "today's case" that goes unnoticed.
If "tomorrow" you re-image it is possible that the "strange" issue does not happen again and you are in good faith convinced that everything is cool.
If instead "tomorrow" you will be using the same OS as "today" it may happen that on the new case the quirk becomes evident and besides fixing/correcting it, you have the possibility to review the past case to check if the quirk affected it or not.

The other one is about security of the data.
Of course anyone would keep all seized hard disks and their images with great care, following a strict chain of custody and in a locked/protected area, and the same goes for the lab with protected access and what not.
But as an example if you used a laptop to examine a case, and then - let's say on your way to a new crime scene - you happen to stop to refuel and get a coffee and the laptop is stolen from your car?
Theoretically the thief would have access to traces of all the cases you had worked on that laptop since last wipe/reimage.

jaclaz

 
Posted : 10/08/2015 6:19 pm
pcstopper18
(@pcstopper18)
Posts: 60
Trusted Member
 

@Chris_Ed

Many wipe all the system drives and start fresh. This is done because there can be no question as to a contamination line of reasoning if everything was wiped and then a verified clean image was restored to the machine. I have done this regularly in my previous lab environment.

For VM environments with this rationale, yes, one would provide for a way to wipe the storage container where data being used in the examination was stored. The VM itself is of no consequence as a new instance can be created each time in a full virtual environment or a fresh copy of a custom VM be used in a non-virtual server environment.

The truth of the matter is that there are many technical reasons why some practices shouldn't matter or at least be left to one's preference provided one can explain what one does (as they should).

Not my choice, but here in the States, legal considerations are paramount in LE/Defense/Investigatory forensics. And the rationale is, we will do X because then we don't have to worry about A,B,C, and D. This is also contributed to by law enforcement being the major driver of DME for so long.

True, one person's interpretation of how to abide by the standards does not make it forensic law. This, of course, is why there can be more than one accrediting body for the ISO standards. The ISO is the base, and the accrediting body may be just there or go above and beyond. How strict one follows ISO 17205 can mean that they adopt or develop practices that are more strict than the ISO itself.

ISO 17205, as we all know, was not originally designed to accommodate digital/multimedia forensics, which, in combination with applicable legal standards (Daubert, Federal Rules of Evidence in the US for example) can be tedious to follow.

I say all of that to explain that "technically," as jaclaz has pointed out, one does not NEED to do things to that extent but it is done to completely remove the argument as a line of questioning in a court of law. This, in my opinion, is really only necessary because many practitioners do not truly learn their craft. If they did, they might take a position such that being able to explain why they did something and why there isn't any risk of contamination.

And I agree with you regarding the EnCase "issue." Its nice to be aware of, but if what was happening was different then there might be cause for alarm. If it ultimately comes down to "if an actor has physical access to your machine," it is absolutely irrelevant at that point how EnCase works because they can just use the blasted program for themselves.

 
Posted : 10/08/2015 11:19 pm
Page 1 / 2
Share: