|
|
|
|
| |
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.
Secure Computing's 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. |
| |
Credit:
The information has been provided by Kingpin of AtStake.
|
| |
Vulnerable systems:
Secure Computing e.iD Authenticator for Palm 2.0
- Palm OS 3.5.2
- Palm OS 3.3
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 less than 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 are 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/<username>/Backup directory. If a new .PDB file is pending to be loaded onto the Palm device, it is stored in the /Palm/<username>/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 that 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 be 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 that 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 (determining) 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
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
|
|
|
|
|
|
|
|
|
|
