@stake, Inc. www.atstake.com Security Advisory Advisory Name: SafeWord e.iD Palm Authenticator PIN Extraction Release Date: 12/14/2000 Application: Secure Computing SafeWord 5.1.1 with e.iD Palm Authenticator v2.0 Platform: Server software on any environment, token software on any Palm OS device, any hardware, any OS Severity: An attacker can determine the private PIN of a user's token within hours, clone the one-time-password scheme, and login as the legitimate user. Author: Kingpin [kingpin@atstake.com] Vendor Status: Vendor has released a statement discussing the issues below in the vendor response section. Reference: www.atstake.com/research/advisories/2000/a121400-1.txt Executive Summary: Secure Computing's (www.securecomputing.com) SafeWord is a user authentication and access control suite which uses various hardware and software token devices for the creation of dynamic, one-time passwords. By entering this calculated password, generated from the legitimate user's PIN and Token Key stored on the token device, the user will be granted access to the network. It is possible to retrieve all necessary data from the Palm OS device in a matter of seconds, allowing an attacker to completely clone the one-time-password scheme and login as the legitimate user. Palm OS devices are widespread in corporate environments and are now being used for password storage and soft-token mechanisms as described in this advisory. However, regardless of the fact that these devices can now provide access to critical corporate assets, they are oftentimes left unattended and unprotected. This leads to open avenues of attack. Overview: The e.iD Palm Authenticator application, which runs on a Palm device, generates the one-time-passwords for use on login. A Palm OS database file (.PDB) is created specifically for each user by the SafeWord Manager application run by the administrator on the desktop. This database file is given to the user by the administrator and loaded onto the Palm device. By gaining access to this .PDB, the legitimate user's PIN can be determined through an encrypt-and-compare procedure. Having both the .PDB and PIN number will allow an attacker to clone the token on another Palm device and generate the exact same list of one-time-passwords, called "tokencodes", as the legitimate user. Using the provided proof-of-concept tool, even the longest-length PIN can be determined in under 6.5 hours. Detailed Description: The Palm OS platform is inherently insecure and was not designed around a security framework. All applications and databases can be accessed and modified by any other application. No access control exists. In the past, tokens used to generate one-time-passwords were often tamper-evident hardware devices. These devices are difficult to reverse-engineer and will sometimes erase critical information if tampering is detected. The software token, such as the e.iD Palm Authenticator, allows the functionality of a previously secure device to be executed on an insecure platform. Methods to determine program operation is much easier in this fashion, making the software tokens less secure and causing a weak link in the security chain. The .PDB file, with a Palm database name of "sceiddb", contains an encrypted form of the user's PIN and Token Key, which are used to calculate the tokencodes. If an attacker can obtain the .PDB file, they will easily be able to determine the PIN number and generate valid tokencodes. The .PDB file can be accessed from either the legitimate user's desktop machine or Palm OS device. The Palm HotSync operation often stores a copy of the application or database, once installed on the Palm device, in the /Palm//Backup directory. If a new .PDB file is pending to be loaded onto the Palm device, it is stored in the /Palm//Install directory. The "sceiddb" database is configured, as default, to not backup to the desktop machine. However, it is possible that the user may have used a third-party solution at one time to backup all of their data. It is a simple task to enable the database to be backed up during the HotSync operation. If an attacker has temporary access to the legitimate user's Palm device, they can transfer the .PDB file to their own Palm device using the Palm OS beaming functionality, which will transfer the data via infrared. The "Beam Lock" protection bit of the database is disabled by default, which allows infrared beaming of this database to another Palm device with minimal user interaction. During normal operation, a tokencode is generated when a PIN is entered. Even if the entered PIN is incorrect, a tokencode will still be generated. However, it will be invalid. Only when the correct PIN is used will the generated tokencode be valid. With this model, it is difficult, if not impossible, for an attacker to determine what the correct PIN is. However, a feature exists in the e.iD Palm application that allows the legitimate user to change their PIN. The current PIN needs to be entered before a new PIN can be specified. If the entered PIN is invalid, a warning message will appear and the application will not allow the PIN to be changed. The application is doing an encrypt-and- compare procedure to determine if the entered PIN is indeed the correct PIN as stored in the "sceiddb" database. It was this code segment that was used to determine the PIN and is the target of this advisory. PINs can range from 2- to 8-digits in length. Regardless of the PIN length, the encrypted representation of the PIN (called the "ciphertext" and stored in the .PDB) is always 16 bytes. This 16-byte string is located from address 0x7A to 0x89. Simply open the .PDB file in a hex editor to extract the bytes. For the purposes of this example, the encryption algorithm stage is shown as a black box. Details of the process can be found in the source code for the proof-of-concept tool described in a later section. At a high-level, the entered PIN and known ciphertext are run through a function which returns a plaintext string. The plaintext returned will equal "PLNCGAHENDHHLM" if the entered PIN is correct. Otherwise, the resultant plaintext will be different. entered PIN -> algorithm -> plaintext "PLNCGAHENDHHLM" (variable) ^ (constant) | ciphertext from .PDB (16-bytes, known) An example PIN authentication routine is as follows: 1) Entered PIN number = 12345678 = 0x3132 3334 3536 3738 (If PIN length is < 8, it will be padded with a constant as shown in the source code) 2) Ciphertext from .PDB = 0xE6EF CB4E 3A8B 1AAE D5EF 2CAD 1A9D B371 3) algorithm (1, 2) -> plaintext 4) If plaintext = "PLNCGAHENDHHLM", PIN is good! By generating a PIN based on each possible combination, ranging from 00 to 99999999, and performing the encrypt-and-compare routine, the PIN can be brute-forced in short order. On a Pentium III 450MHz, all 111,111,100 possible combinations can be completed in 6.48 hours. After determining the most recent tokencode entered into the server by the legitimate user (by network sniffing, keyboard monitoring, or other means), it is a trivial task to synchronize the cloned device with the legitimate device. This is achieved by advancing through the computed tokencodes on the cloned device until it matches the most recently used tokencode. At this point, the attacker can enter in the next calculated tokencode and be granted access by the server. Temporary Solutions: 1) Enable the "Beam Lock" bit on the Palm OS device for the "sceiddb" database. Although this protection mechanism is easily bypassed using third-party applications, it will add a layer of complexity and increase the length of time needed for an attacker to obtain the database from the target device. 2) Confirm that the .PDB file is not stored on the user's desktop machine after it has been loaded onto the Palm OS device. Even though the database is set to not backup to the desktop by default, the user may have used a third-party solution to backup all of their data. A global find for *.PDB will locate all .PDB files on the user's machine. It is highly recommended that extreme caution is taken to prevent compromise of the .PDB files. 3) The user should be very aware of the physical security and location of the Palm OS device at all times. The owner of the device should not leave it unattended or loan it to a potentially untrustworthy colleague. This will prevent an attacker from retrieving the legitimate user's .PDB file (hence their PIN) from the device. 4) A longer-term solution, especially if the Palm authenticators are already deployed in existing infrastructure, would be to move to a hardware-based token, such as the SafeWord Silver 2000 or Platinum devices. These physical pieces of hardware are often more secure, because they are dedicated to one function and are often designed with tamper-evidence and tamper-response mechanisms. It is recommended, however, that any device being introduced into a live environment be fully analyzed and tested beforehand. 5) Although it is difficult to completely protect credentials and algorithms stored on a software-based device, it is recommended that vendors properly encrypt and salt credentials if they must be stored on the device. Simple obfuscation and transforms that can be reversed or brute-forced lull the user into a false sense of security and show a lack of concern about security from the vendor. The use of a salt minimizes the possibilities of a password being represented in the same fashion on multiple systems. Removing the PIN-changing functionality from the Palm OS application will remove the need to have the encrypt-and-compare routines which were targeted for this advisory. Vendor Response: @stake received the following response from Secure Computing. We appreciate their timely response and their input in scoping the issues raised in our advisory for their customers. BEGIN VENDOR COMMENTS In response to a security advisory produced by @stake, Inc. (www.atstake.com), Secure Computing is providing additional information about the vulnerabilities associated with software-based token authentication and recommendations for customers in deploying appropriate security solutions. When deploying any security system, there are often trade-offs between security and convenience. Organizations must balance the value of the information being protected with ease-of-use and cost issues to deploy a system that is appropriate for their needs. The reality is that a system that is "secure enough" and used by a large number of people, may be more valuable than a highly secure system that is only implemented by a few. Because organizations have different levels of risk, multiple solutions are needed with varying levels of security strength. Secure Computing Corporation offers multiple levels of security for user authentication including: 1) Traditional memorized passwords, which provide basic user authentication suitable for protecting low-value data; 2) Medium strength software-based authenticators, which offer protection far superior to passwords yet have the convenience of running on a device the user already has; 3) Hardware-based authenticators (also known as tokens), which provide the highest level of security, but can cost more and require the user to carry an additional security device. While there are many suitable uses for passwords, they can be easily compromised and should be used only when the value of the information at risk is low. When risks are higher, a different authentication method should be used. Software-based authenticators usually run on a general-purpose system such as a PC, palm, or handheld computer. A common example of software authentication is storing a digital certificate (and the associated private key) on a user's PC. Secure Computing's "SofToken for Palm OS" is another example, and there are a number of similar products available from several manufacturers. The secret or private key is at the heart of the authentication and must be kept confidential to preserve security. However, general-purpose computers, which host software authenticators, are designed to have their data read, traced, and analyzed by applications, utility programs and diagnostic utilities. This makes software authenticators inherently vulnerable to a number of attacks where the secret or private key can be obtained if the device or associated data is not properly safeguarded. @stake highlights this vulnerability in their security advisory. Regardless of how a key may be salted or encrypted, ultimately it must be decrypted and processed, so any utility that could be placed within the device by an attacker could potentially recover the key while it is being processed. This is generally true for all software-based authenticators. The attack described by @stake focuses on extracting the key by attacking the PIN change logic. Some software authenticators remove the PIN change logic to reduce this risk, however this does little to prevent the overall and greater vulnerability of obtaining the key during processing or by other attacks. Secure Computing feels that the added security and convenience of being able to change the PIN outweighs any benefit that might be obtained by removing this feature. Secure Computing also provides much stronger security systems and recommends them when appropriate. Hardware-based authenticators, such as the SafeWord Silver 2000 or Platinum tokens provide extremely strong protection for the secret or private keys. These systems are designed to prevent the key from being extracted by any other device, eliminating the risk of attack associated with software-based authenticators. As a reminder to our customers, the following guidelines should be observed when selecting, expanding, and implementing their user authentication system: 1) Perform an assessment to determine the value of what is at risk, and select an authentication method that is appropriate. In general, this will be memorized passwords for low-value data, software authenticators for medium-value data, and hardware authenticators for medium- to high-value data. 2) When deploying software-based authenticators, educate your user community about safeguarding the device and any associated data that might contain private keys. 3) Use attack lockout features to automatically disable an account if it is under repeated attack. 4) Conduct periodic assessments of the value of the data at risk. If the risk has increased, take steps to implement a stronger authentication system. By following these guidelines, organizations can deploy the user authentication security system that is appropriate for their needs, and not pay for more than they actually need. More information Secure Computing's products is available at www.securecomputing.com In addition the following links contain more specific information, whitepapers and solutions briefs regarding authentication and security issues: SafeWord Authenticators: http://www.securecomputing.com/index.cfm?sKey=440 SafeWord: http://www.securecomputing.com/index.cfm?sKey=187 SafeWord Plus: http://www.securecomputing.com/index.cfm?sKey=196 END VENDOR COMMENTS Proof-of-Concept Code: A proof-of-concept tool has been written for the Windows 9x/NT platform to demonstrate the ease of determining the user's PIN from the "sceiddb" .PDB file with an encrypt-and-compare procedure. Using a Pentium III 450MHz, the maximum length 8-digit PIN can be determined in under 6.5 hours. Shorter length pins can be determined in significantly less time. Based on the implementation of this proof-of-concept code, the following time metrics were calculated: PIN Length Time to calculate PIN 2 0.023 seconds 3 0.23 seconds 4 2.3 seconds 5 23.3 seconds 6 3.8 minutes 7 38.8 minutes 8 6.48 hours Source code and compiled executable for the proof-of-concept tool is available from: http://www.atstake.com/research/advisories/2000/eidextract.zip @stake Advisory Release Policy: http://www.atstake.com/research/policy/ For more advisories: http://www.atstake.com/research/advisories/ PGP Key: http://www.atstake.com/research/pgp_key.asc Copyright 2000 @stake, Inc. All rights reserved.