search menu icon-carat-right cmu-wordmark

CERT Coordination Center

Guidance EnCase Enterprise uses weak authentication to identify target machines

Vulnerability Note VU#912593

Original Release Date: 2007-11-09 | Last Revised: 2007-11-20


Guidance Software's EnCase Enterprise uses IP authentication to identify target machines. An attacker may be able to provide the EnCase SAFE server with a disk image from a different machine than an investigator requested.


Guidance Software's EnCase Enterprise allows investigators to remotely acquire disk images from target systems for forensic analysis. The remote target systems may be on the same LAN or located on the Internet.

EnCase Enterprise consists of three applications:

    1. EnCase SAFE is a server that is used to authenticate users, distribute licenses, provide forensic analysis tools, and communicate with target machines running the EnCase Servlet.
    2. EnCase Servlet runs locally on target machines and allows the EnCase SAFE to create an image from the target operating system.
    3. EnCase Examiner is a local application that is installed on the investigator’s computer and provides an interface to the EnCase SAFE server.

    EnCase Enterprise Edition uses a public key encryption system to verify that the servlet is communicating with an authorized SAFE server; however, the SAFE server uses IP authentication to verify the identity of the servlet.

    Information about this vulnerability was publicly disclosed by the iSec paper "Breaking Forensics Software: Weaknesses in Critical Evidence Collection."


    An attacker may be able to supply the EnCase SAFE with a different image than the investigator requested by using ARP spoofing or other well-known network attacks.


    Guidance Encase customers should see the Guidance support portal for information about obtaining fixed software and workarounds.

    The following workarounds may mitigate this vulnerability:

      • Using IPSec or other virtual private network network technologies to provide secure communications and authentication for machines running the EnCase Servlet may mitigate this vulnerability by preventing attackers from injecting or manipulating data.
      • IDS systems capable of detecting ARP spoofing may be able to alert administrators when this attack vector is being exploited.

    Vendor Information


    Guidance Software, Inc. Affected

    Updated:  November 20, 2007



    Vendor Statement

    The vulnerability described in this issue involves an 𠇊ttacker” convincing the EnCase Enterprise environment that it is accessing a computer that it believes is the attackers system when in fact, it is a different system. This 𠇊ttack” assumes that the attacker has Administrator access to the network that he is operating on. In order to address this issue, it is necessary to provide a foundation for the authentication mechanism in the EnCase Enterprise environment. The primary defense posture for the EnCase servlet is against attack from an unauthorized process wishing to connect to the host machines servlet. Since servlets are typically deployed across a network, an attacker would wish to bypass the SAFE authentication and go directly to the servlet to gain host based information. To guard against this, the servlet must receive an introductory packet which is signed by the private key of the SAFE. Further, the servlet then hands the SAFE a session key encrypted with the SAFE's public key. Only the SAFE could then decipher the session key and be able to communicate further with the servlet. This also prevents a reply attack against the servlet.

    The next defense mechanism is to prevent an authorized user of the SAFE from communicating with a servlet that he does not have permission to access. For this reason, if the SAFE is asked to connect with an IP address or Machine Name, the SAFE ensures that the user's permissions permit connection to that address. Further, once the SAFE contacts the servlet of the target machine, the servlet replies with the machine name and IP address of the system that it is running on. It does this by directly querying the operating system. That information is also checked for validity against the SAFE users permissions. This prevents an EnCase user from side-stepping the permissions with a NAT or DNS poisoning scheme. With those mechanisms explained, let us consider the issue of authentication of the servlet. In the scenario described by iSEC, the attacker is a knowledgeable user of a network host who has administrator rights on his own machine and the network that he is operating on. He seeks to trick the SAFE into thinking that it is communicating with his "dirty" machine, when in fact, it is communicating with a "clean" machine of his choosing. To do this he poisons the DNS and routes the network traffic to the clean machine, while his dirty machine continues to be on the network at another address.

    Although this scenario is possible, actually the bad guy does not have to go through all this trouble. Since he knows that he is under investigation and has administrator rights on the network, he simply needs to setup another machine on the network to do his 𠇍irty” work. In other words, the iSEC attack is nothing more than a simple switch of computers. Remember that this attack would also work even if the investigator visited the bad-guys office at night and took a physical image of the hard drive. There is nothing to stop the bad guy from simply walking out with (or hiding) his dirty machine each night, so that the investigator will find the clean machine and image that one.

    Absent a video tape of someone using a particular computer system, Guidance Software has understood for many years that identifying the user of a computer
    requires the investigation of the data stored on that computer. We have always taught in our training classes that an investigator must look at the evidence on the system to substantiate who the true user is. This is the same whether the computer is being examined across a network or in person.

    The original report that identified this issue indicated that the EnCase Enterprise environment was vulnerable because it did not cryptographically identify the machine that it was connecting to. The report, as well as US-CERT/NIST, indicates that there is “no practical solution” or the issue is “not solvable”. This is because, based on current technology, any authentication scheme is subject to attack.

    As an example, one way to authenticate the servlet in a secure way would require you to generate a key-pair for each computer on your network, store the private key on each machine in a tamper-proof way, register the public key on a central server that could be queried in real-time for servlet authentication, and create a central registry associating users with hosts. There are many hurdles with this

    1. Most existing computers do not have the ability to store data in a tamper-proof way. Since the bad guy (in this case) has complete access to his own machine, he would easily be able to copy a file or registry key containing such a key.

    2. Most organizations do not have a central registry of users or hardware, much less one correlating the two, which is updated frequently.

    3. If a registry existed, our bad-guy could simply hack that database, instead of
    the poisoning DNS server.

    4. Generating, registering and pushing the keys to different machines would require a very centralized and secure scheme that most organizations can only dream of, especially given the number of machines that are added and removed from a large corporate or government network each day. Based on the information above, it is GSI’s position that although the reported issue does exist, it can be mitigated using the same techniques that are required to authenticate a computer that is physically taken and imaged. It is also our position that there is no practical or manageable cryptographic solution to mitigate the issue.

    Vendor Information

    The vendor has not provided us with any further information regarding this vulnerability.


    See for more information.

    If you have feedback, comments, or additional information about this vulnerability, please send us email.

    CVSS Metrics

    Group Score Vector



    iSec partners released information about this vulnerability.

    This document was written by Ryan Giobbi and Jason McCormick.

    Other Information

    CVE IDs: CVE-2007-4202
    Severity Metric: 0.90
    Date Public: 2007-08-03
    Date First Published: 2007-11-09
    Date Last Updated: 2007-11-20 18:34 UTC
    Document Revision: 34

    Sponsored by CISA.