Vulnerability
PalmOS
Affected
PalmOS 3.5.2 and below
Description
Following is based on a @stake Advisory A092600-1 by Kingpin.
PalmOS offers a built-in Security application which is used for
the legitimate user to protect and hide records from unauthorized
users by means of a password. In all basic built-in applications
(Address, Date Book, Memo Pad, and To Do List), individual records
can be marked as "Private" and will only be accessible if the
correct password is entered.
It is possible to obtain an encoded form of the password,
determine the actual password due to a weak, reversable encoding
scheme, and access a users private data. In order for this attack
to be successful, the attacker must have physical access to the
target Palm device.
The threat of physical attacks internal to a company is very real
and this advisory makes the point that security is not limited to
the network/internet arena. The private records often contain
passwords, financial data, and company confidential information.
Our experience with physical audits has revealed that most users
of Palm or other portable devices do not realize that their
private information could possibly be accessed by unauthorized
users.
During the HotSync process, the Palm device sends an encoded form
of the password over the serial, IR, or network ports to the
HotSync Manager or HotSync Network Server on the desktop. The
password is transmitted to enable the Palm Desktop program to
protect the users private records when being accessed on the
desktop machine. However, based on an encoding scheme of XOR'ing
against a constant block of data, the encoded password is easily
decoded into the actual ASCII version of the password. The
encoded block is also stored on the Palm device in the Unsaved
Preferences database, readable by any application on the Palm
device.
The transfer of a secret component (i.e. password), even if it is
encoded or obfuscated, over accessible buses (serial, IR, or
network) is a very risky design decision and is oftentimes
considered a design flaw. It is unfortunately common practice
that applications choose to simply obfuscate passwords instead of
using encryption. Without proper encryption methodologies in
place, the task of determining the secret data is greatly
simplified as shown in this research.
This advisory is an attempt to remind users and developers of the
common problem of storing secrets and the reliance on simple
obfuscation.
The password is set by the legitimate user with the Security
application. The maximum length of the ASCII password is 31
characters. Regardless of the length of the ASCII password, the
resultant encoded block is always 32 bytes. It is possible to
obtain the encoded password block in a number of ways:
() Retrieve from the "Unsaved Preferences" database on the
Palm device.
() Monitor the serial or network traffic during an actual
HotSync.
() Imitate the initial HotSync negotiation sequence in order
to obtain the password (which is transmitted by the target
device). This is demonstrated in our proof-of-concept tool
written for the PalmOS platform.
The Palm desktop software makes use of the Serial Link Protocol
(SLP) to transfer information between itself and the Palm device.
Each SLP packet consists of a packet header, client data of
variable size, and a packet footer [Palm OS Programmer's
Companion, pg. 255]. During the HotSync negotiation process, one
particular SLP packet's client data consists of a structure which
contains the encoded password block (Figure 1).
struct {
UInt8 header[4];
UInt8 exec_buf[6];
Int32 userID; // 0
Int32 viewerID; // 4
Int32 lastSyncPC; // 8
UInt8 successfulSyncDate[8]; // 12, time_t
UInt8 lastSyncDate[8]; // 20, time_t
UInt8 userLen; // 28
UInt8 passwordLen; // 29
UInt8 username[128]; // 30 -> userLen
UInt8 password[128];
};
Figure 1: Structure sent during the HotSync process which contains
the encoded password block.
Two methods are used to encode the ASCII password depending on its
length. For passwords of 4 characters or less, an index is
calculated based on the length of the password and the string is
XOR'ed against a 32-byte constant block. For passwords greater
than 4 characters, the string is padded to 32 bytes and run
through four rounds of a function which XOR's against a 64-byte
constant block. It is unknown why disparate methods were
implemented. By understanding the encoding schema used, it is
possible to essentially run the routines in reverse to decode the
password, as shown in our proof-of-concept tools. Details of each
method are described below.
Neither encoding schema make use of the username, user ID, or
unique serial number of the Palm device. A common practice often
used for copy-protection purposes is to use a unique identifier
as input into an encoding or encryption algorithm, which PalmOS
does not do. The resultant encoded password block is completely
independent of the Palm device used and makes it easier to
determine the original ASCII password from the block.
Passwords of 4 characters or less
=================================
By comparing the encoded password blocks of various short length
passwords (Figure 2), it was determined that a 32-byte constant
(Figure 3) was being XOR'ed against the ASCII password in the
following fashion:
56 8C D2 3E 99 4B 0F 88 09 02 13 45 07 04 13 44
0C 08 13 5A 32 15 13 5D D2 17 EA D3 B5 DF 55 63
Figure 2: Encoded password block of ASCII password 'test'
09 02 13 45 07 04 13 44 0C 08 13 5A 32 15 13 5D
D2 17 EA D3 B5 DF 55 63 22 E9 A1 4A 99 4B 0F 88
Figure 3: 32-byte constant block for use with passwords of length
4 characters or less
Let A_j be the jth byte of A, the ASCII password
Let B_k be the kth byte of B, the 32-byte constant block
Let C_m be the mth byte of C, the encoded password block
The starting index, i, into the constant block where the XOR'ing
should begin is calculated by the following:
i = (A_0 + strlen(A)) % 32d;
The encoded password block is then created:
C_0 = A_0 XOR B_i
C_1 = A_1 XOR B_i+1
C_2 = A_2 XOR B_i+2
C_3 = A_3 XOR B_i+3
C_4 = B_i+4
.
.
.
C_31 = B_i+31 (wrapping around to the beginning of the constant
block if necessary)
Example: 0x56 = 0x74 ('t') XOR 0x22
0x8C = 0x65 ('e') XOR 0xE9
0xD2 = 0x73 ('s') XOR 0xA1
0x3E = 0x74 ('t') XOR 0x4A
Passwords greater than 4 characters:
====================================
The encoding scheme for long length passwords (up to 31 characters
in length) is more complicated than for short length
passwords, although it, too, is reversable.
First, the ASCII string is padded to 32 bytes in the following
fashion:
Let A_j be the jth byte of A, the ASCII password
len = strlen(A);
while (len < 32)
{
for (i = len; i < len * 2; ++i)
pass[i] = pass[i - len] + len; // increment each character by len
len = len * 2;
}
Example: A_0 = 0x74 ('t')
A_1 = 0x65 ('e')
A_2 = 0x73 ('s')
A_3 = 0x74 ('t')
A_4 = 0x61 ('a')
A_5 = 0x79
A_6 = 0x6A
A_7 = 0x78
A_8 = 0x79
A_9 = 0x66
A_10 = 0x7E
.
.
.
The resultant 32-byte array, A, is then passed through four rounds
of a function which XOR's against a 64-byte constant (Figure 4):
B1 56 35 1A 9C 98 80 84 37 A7 3D 61 7F 2E E8 76
2A F2 A5 84 07 C7 EC 27 6F 7D 04 CD 52 1E CD 5B
B3 29 76 66 D9 5E 4B CA 63 72 6F D2 FD 25 E6 7B
C5 66 B3 D3 45 9A AF DA 29 86 22 6E B8 03 62 BC
Figure 4: 64-byte constant block for use with passwords greater
than 4 characters
Let B_k be the kth byte of B, the 64-byte constant block
Let m = 2, 16, 24, 8 for each of the four rounds
index = (A_m + A_m+1) & 0x3F; // 6 LSB
shift = (A_m+2 + A_m+3) & 0x7; // 3 LSB
for (i = 0; i < 32; ++i)
{
if (m == 32) m = 0; // wrap around to beginning
if (index == 64) index = 0; // wrap around to beginning
temp = B_index; // xy
temp <<= 8;
temp |= B_index; // xyxy
temp >>= shift;
A_m ^= (unsigned char) temp;
++m;
++index;
}
The resultant 32-byte encoded password block (Figure 5) does not
have any remnants of the constant block as the short length
encoding method does. Although the block appears to be "random",
it is indeed reversable with minimal computing resources as shown
in proof-of-concept tools.
18 0A 43 3A 17 7D A3 CA D7 9D 75 D2 D3 C8 A5 CF
F1 71 07 03 5A 52 4B B9 70 2D B2 D1 DF A5 54 07
Figure 5: Encoded password block of ASCII password 'testa'
Proof-of-concept tools have been written for the Windows 9x/NT and
PalmOS 3.3 and greater platforms which demonstrate the simplicity
of obtaining the encoded password block from the target device
and the weak encoding scheme used to obfuscate the password. The
PC version, "PalmCrypt", will encode and decode ASCII passwords to
encoded password blocks and vice versa. The PalmOS version,
"NotSync", will imitate the initial stages of the HotSync process
via the IR port, retrieve the encoded password block of the target
device, and decode and display the resultant ASCII password.
Source code and binaries for the proof-of-concept tools can be
found at:
http://www.atstake.com/research/advisories/2000/notsync.zip
http://www.atstake.com/research/advisories/2000/palmcrypt.zip
Successfully using NotSync requires two Palm devices: One device
running the NotSync application and the other being the target
device in which the password is desired. Facing the two devices
head-to-head, run the HotSync application on the target Palm
device and initiate an "IR to a PC/Handheld" HotSync. NotSync,
running on the other device, will obtain the legitimate user's
encoded password block, decode the password, and display the
result on the screen.
Typical usage and output for PalmCrypt is shown below:
E:\>palmcrypt
PalmOS Password Codec
kingpin@atstake.com
@stake Research Labs
http://www.atstake.com/research
August 2000
Usage: palmcrypt -[e | d] <ASCII | password block>
E:\>palmcrypt -e test
PalmOS Password Codec
kingpin@atstake.com
@stake Research Labs
http://www.atstake.com/research
August 2000
0x56 0x8C 0xD2 0x3E 0x99 0x4B 0x0F 0x88 [V..>.K..]
0x09 0x02 0x13 0x45 0x07 0x04 0x13 0x44 [...E...D]
0x0C 0x08 0x13 0x5A 0x32 0x15 0x13 0x5D [...Z2..]]
0xD2 0x17 0xEA 0xD3 0xB5 0xDF 0x55 0x63 [......Uc]
E:\>palmcrypt -d
568CD23E994B0F8809021345070413440C08135A3215135DD217EAD3B5DF
5563
PalmOS Password Codec
kingpin@atstake.com
@stake Research Labs
http://www.atstake.com/research
August 2000
0x74 0x65 0x73 0x74 [test ]
If You are wondering why consider this worthy of a "advisory" when
there has been a well known program called "No Security" that with
a click of your stylus you can wipe the password off the palm
device or in addition you can use a 3rd party program to synch
the pilot, say Jpilot and it retrieve all "private" records and
do not bother to protect them, try looking more closely at the
notsync program. This enables an auditing team or person to walk
around with their own palm pilot and, upon finding a non-guarded
palm pilot, fake the hotsync negotiation over the IR port and
retrieve the password.
Often it is much more important to retrieve the password that a
person has chosen for future use in a threat scenario than to just
go after the files on the PDA device. This is different in future
threat vectors than simply wiping the password or slurping down
the files without learning how this individual chooses to keyspace
in passwords.
If you do have access to a Palm Pilot and a HotSynch craddle, as
you need for this "exploit" to work, there is no need whatsoever
to retrieve the user's password to see his data. What you need
to do is explained in big bold letters on the Palm user's manual:
1) HotSynch
2) Hard Reset (press and hold power button while hitting reset
button, until the palm logo pops up, and then hit "down" key)
3) switch the HotSynch setting to "Desktop Overwrites Handheld"
4) HotSynch
Et voila', you got rid of the password, and you have full access
to the hidden records.
Solution
The Security application provides functionality to "turn off and
lock device". If the Palm device is turned off and locked using
this feature, the device will not be operational until the correct
password is entered. This will prevent an unauthorized user from
running applications on the device (hence preventing them from
starting the HotSync process). This workaround is only useful if
the legitimate user can be sure that the attacker hasn't attained
the system password already - simply change the password to be
sure. It may be possible to bypass the system lock-out mechanism
by entering into the PalmOS debug mode before the lock-out
features are called. This may allow an attacker to step over the
security code during a debugging session.
The use of third-party encryption solutions, such as Secure
Memopad by Certicom, which implement strong and tested
cryptological algorithms to protect the data of certain Palm
applications.
PalmOS does not believe this poses a major risk to all their users
for the following reasons :- It is not easy for someone to capture
passwords accidentally, you need to have access to the device and
access to the OS/software as well to run the hotsync and thence
capture the data. It would also need to be a malicious, funded,
attack and some data points need to be known to the attacker,
making the chances of such an attack very low, but not impossible
in everyday life.
The simple way to protect against such an attack is to use
products from Force.com to keep the device about your person, or
to use any of the security programs such as OnlyMe or SignOn to
secure access, (as improvements over the supplied software
security program) or data encryption programs such as Jaws
Technology encryptors, Securememopad from Certicom to encrypt
data, or Ntru encryption tools. PalmOS will address this issue in
the future.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
