Updated: November 20, 2007
Status
Affected
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
scheme:
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.
Addendum
See https://support.guidancesoftware.com/node/487 for more information.
If you have feedback, comments, or additional information about this vulnerability, please send us email.