COMMAND

    PalmOS

SYSTEMS AFFECTED

    PalmOS 3.5.2 and below

PROBLEM

    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.