Anti-Tampering Technical White Paper Version 1.6 Copyright Notice Due to a policy of continuous product development and refinement, Safend reserves the right to alter the specifications and descriptions outlined in this publication without giving prior notice of any kind. In addition, no part of this publication, taken as a whole or separately, shall be deemed to be part of any contract for equipment or services. Safend retains the sole proprietary rights to all information contained in this document. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by any means, including but not limited to: electronic, mechanical, magnetic, photocopy, recording, or otherwise, in use now or in the future, without prior written consent from Safend. February 2006 – Copyright ©2006 Safend Table of Contents Introduction ................................................................................................................... 1 Policy Protection........................................................................................................... 1 Log Protection............................................................................................................... 2 Uninstall Password....................................................................................................... 2 Strong One-Time Password Mechanism..................................................................... 2 Policy Tampering .......................................................................................................... 3 Integrity Check .............................................................................................................. 3 Policy Enforcement....................................................................................................... 3 Safend – Proprietary and Confidential Safend – Proprietary and Confidential 1 Introduction To achieve true endpoint security, a solution needs to be virtually impossible to circumvent, disable, or uninstall. The solution needs to enforce the security policies set by the system administrators, without fail. As opposed to anti-virus or gateway security solutions – where the IT department and users share the common goal of protecting the network from harm – endpoint security often involves limiting users' freedom of action. With this misalignment between organization and end-user goals, it is possible that users may try to circumvent the endpoint security solution – sometimes with malicious intent, and sometimes simply in an effort to continue using favored devices such as MP3 players, flash drives and so on. Therefore, every endpoint security product must take into account that its attacker has full physical access to the host it is defending. Unfortunately, in the Windows operating system, if an attacker has physical access to the computer, he is not far from gaining local administrator privileges 1 . Once this occurs, the attacker can tamper with the product: change policies, prevent log submission, partially or entirely remove the product, etc., thus in effect removing the protection. Due to the many opportunities a local administrator has to interrupt the workings of the protection system and decrease network security, Safend has developed an extensive set of anti-tampering features formulated to enable the organization's IT department to regain control of endpoint security. In addition, Safend examines each of its products' features during the design process, implementing designs that provide defense from malicious users with physical access to the organization's computers. A fundamental principle in security stipulates that a truly secure system is one that relies on strong, known security protocols rather than on proprietary protocols. In adherence to this concept, Safend Protector's design employs cryptography in many of its features. In addition, a generic mechanism has been constructed to protect the OS definitions that keep Safend Protector up and running. This white paper will address various anti-tampering concerns and review the multitude of solutions incorporated into Safend Protector. Policy Protection The endpoint security policy is a valuable resource for an attacker. If an attacker succeeds in accessing the policy, he virtually "owns" the machine. He can set his own uninstall password and use it to uninstall the endpoint security application, remove logs for certain types of devices, allow all devices to be connected and more. This is why Safend Protector's policy is signed by the Safend Management Server's 2 private key and written to an isolated location to which only Safend administrators have access. The public key used to validate the legitimacy of a policy transferred to the Safend Protector client, is given to the Safend Protector during the client installation and cannot be changed thereafter. This restriction is written in the Safend Protector client itself, ensuring that an attacker will not be able to change the public key that is used by the client in order to validate the policy, and then use his own public/private key pair to write and sign his own policy. 1 There are many tools that enable an attacker to change the local administrator's password using an alternate OS. A summary of these tools can be found in Daniel Petri's essay (http://www.petri.co.il/forgot_administrator_password.htm) on the subject. 2 The term "Safend Management Server" refers to Safend Protector v3.0 and up. In previous versions, the management is standalone and the keys are located in an SMC file. Safend – Proprietary and Confidential 2 Log Protection The Safend Protector logs are an essential tool for the Safend administrator. Vital logs are sent from Safend Protector to the Safend Management Server whenever a user violates a policy. An intelligent attacker attempting to violate the policy would probably do so when offline from the network, so that logs would not be immediately sent. The attacker could then try to locate the local logs and delete them, leaving the administrator unaware of the policy violation. To hinder such attempts, Safend Protector keeps track of the exact number of logs that it has written and sends a log sequence number to the Safend Management Server in every log event. If an attacker has deleted one or more events, the Safend Management Server will detect that events are missing and deduce that the user has tampered with Safend Protector. Log events are written in such a way as to ensure that even if the user gains access to their local storage, he can never read them. Safend uses asymmetric cryptography to encrypt logs so that the key stored in the Safend Management Server is required in order to read the logs that reside in the Safend Protector client. Uninstall Password If a user wants to uninstall Safend Protector, it is not sufficient that he be a member of the local administrators group (as is common for many applications). An additional password is required that is known only to the organization's Safend administrator. If a user needs to suspend Safend Protector for any reason, and the system administrator wishes to grant this temporary suspension, a one-time password mechanism 3 is utilized so that the user will not be able to suspend the protection of the system for longer than authorized by the administrator (see next section). Strong One-Time Password Mechanism Safend's one-time password feature allows a user to suspend the Safend Protector protection for a short period of time after entering a special temporary suspension password. When an administrator provides a user with such a password, he doesn't want the user to be able to reuse the same password, whether to suspend the protection on that same computer or to compromise other computers with the same security policy. In the design of this feature, Safend implemented a slight variation of a recognized cryptographic protocol known as OTP (RFC 2289). This design utilizes a known protocol whose security has been researched and checked by many experts worldwide. This approach is preferable to implementing an ad-hoc system that may have unknown security flaws. The strength of this protocol lies in the fact that all the information that may compromise the security of the Safend Protector client resides within the Safend Management Server and is not kept locally. This means that even if a user monitors every command that his CPU runs and knows all the data that its local Safend Protector knows, he cannot generate a good suspension password. The one-time password is kept only in the Safend Management Server and cannot be reproduced using the client data alone. Another strong security aspect of the protocol used is that even when provided with a password for a specific temporary suspension period, an attacker cannot change the suspension period without asking for a separate password. 3 Introduced in Safend Protector v3.0 Safend – Proprietary and Confidential 3 Policy Tampering A user's attempt to tamper with the stored policy will not afford him any advantages. If the policy's signature does not correlate with the policy at hand (in other words, when a user has changed the policy but was unable to update the policy's signature because he does not possess the Safend Management Server's private key) then the enforced policy remains the same as it was prior to the tampering attempt. If an attacker tampers with the policy, his attempts will lead him further down the path to a complete restriction policy in which all devices are blocked. The most restrictive policy is Safend Protector's last resort. If tampering persists, a full endpoint lock-down will be activated. Integrity Check Safend Protector consists of multiple components. Some components reside in User Mode (the tray icon handler is an example) while others are in Kernel Mode. In order to check that the protection system is unimpaired and has not been tampered with, Safend Protector validates the authenticity of all running components. This is done by using asymmetric cryptography. Only Safend can create authentic code that will run as part of the Safend Protector system. In addition to the code checking, if tampering is detected Safend Protector will fix any definition that needs to be fixed in Windows in order for it to operate properly. The system checks itself constantly. Policy Enforcement In addition to the anti-tampering elements described above, Safend Protector also features strong enforcement capabilities. Policy enforcement is performed as close to the hardware as possible. Safend Protector filters the communication with the bus devices (for example the USB host controller, PCMCIA card, etc.) and from this communication infers what the user is trying to do. Safend Protector logs the activities and blocks unauthorized activities or attacks. Filtering device communications, an action similar to that implemented by a firewall, minimizes Safend Protector core's OS dependency and bolsters its shield against OS-specific attacks. Finally, it is important to note is that all of Safend Protector's policy enforcement is implemented according to documented and recommended "best practices". For example, Safend Protector does not perform any type of API hooking for either the enforcement or the anti-tampering features.