When a problem is staring us in the face, yet we cannot see it |

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.

EnCase, in our opinion is one of the top digital forensic tools. It consolidates and automates multiple facets of our forensic work.

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

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.

Our consternation is blind trust of examiners in solutions because someone "said so", and the lack of following often touted standard operating procedures (SOP).

Writing a SOP down how each workstation should be wiped and rebuilt or re-imaged but not following such SOP is a failure of the forensicators.

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.

Problem 1:

EnCase 7 has the feature to associate file extensions and file signatures with viewers, specifically in three ways.

Files can be viewed through EnCase, through a user defined Installed Viewer, or through Windows.

In case of Windows selection, the file is passed to the host operating system, the examiner's workstation. Microsoft Windows interprets the file as a normal Windows Explorer double-click, and launches the associated application.

By default EnCase has about 360 file types associated with Windows as viewer. Of these, there are over a dozen which can contain scripts, and executable code. The image to the right shows Windows Compiled HTML Help file as example. It is the same file type we used for our demonstration on the video.

Problem 2:

Clicking on fields, objects, files, and windows throughout a single version of EnCase and across versions of EnCase is inconsistent.

In some places double-left mouse click is required, while in others a single-left mouse click is sufficient.

In our experience, users tend to double-click across the entire system, be it from habit or simple to "make sure it does it".

When users wish to select, or set focus to a file in the Table Pane, they often double-left mouse click on the file.

We want to note that this is not inherently an EnCase taught behavior. Microsoft Windows Explorer uses double-left click to enter a folder or directory, while single-left click to place focus on file.

Demonstration:

We have tested the following from EnCase 7.08 through 7.12.

In our demonstration we use a Microsoft Windows Compiled HTML Help file.

As noted earlier, there are multitude of options, but .chm files are very quick to craft, and easily understand.

The example:

launches a CMD window, and

creates a batch file ( Dropperbadness.cmd ) with one line of code

) with one line of code launches a second CMD window, and

appends to the above batch file a new line of code.

The final batch file is executed, creating a local user "Badness" as a local administrator.

It launches a PowerShell window, which in turn

executes a program ( C:\Windows\System32\calc.exe ).

These commands run at the launching application's access level. Since they are launched through EnCase they have, at least local administrator privileges.

The batch file, by default will be where the EnCase.exe file is located.

(Command shell creating user account on forensic workstation.)

Youtube video of the demonstration.

An E01 image file is provided with various distracting files, and the enticing Air-gapped-attack.chm file.

Warning - DO NOT double click the Air-gapped-attack.chm file in the image through EnCase 7 (or through any system), unless you are okay with the consequences.

MD5 checksum: 82d393845b3433f6ee703af7ac0da905

SHA1 checksum: 9c094ca9054edcad3f99d60b17294cef4bba7204

Mitigating solution:

Change all file type associations in EnCase to EnCase or a dummy Installed Viewer.

Recommendations:

EnCase should question the examiner if they really want to launch a file, if it is launched through Windows association.

More consistency across the application for clicking and double-clicking requirements would reduce or eliminate such user errors.