Re: [coldsync-hackers] [PEG-T415] update

["David A. Desrosiers" <hacker at gnu-designs dot com>]

> Actually, when I was looking for the password hashes, I did a global
> search of my transaction logs.  The password doesn't appear anywhere,
> nor does its hash.  I consider this to be strange.

	Sure it does. I found this back in July 2001. It's a 16-byte hash,
and it's plaintext in the first 10 SLP packets passed. Binghamton is down,
so below is a copy of the original message. Note, this was pilot-link
specific at the time, but the code and process should still be relevant.

	Maybe this will help.

--
Date: Fri, 6 Jul 2001 20:50:16 -0700 (PDT)
From: David A. Desrosiers <hacker@gnu-designs.com>
Reply-To: pilot-unix@hcirisc.cs.binghamton.edu
To: Pilot-Unix <pilot-unix@hcirisc.cs.binghamton.edu>
Subject: Re: [pilot-unix] Palm M50x series


> With the serial cradle it works great except I can't set the password on
> my palm, so for someone info the security needs to be looked at as well.

        <evil grin>

        Ok, time to let the cat out of the bag.

        I did some testing and on May 20th, found the answer. Previously,
you could get the password from the Palm, and actually decode it, and obtain
the user's password. You can find details on that here:

        http://www.atstake.com/research/advisories/2000/a092600-1.txt

        But, in PalmOS4, you'll notice that these tools don't quite work
anymore. Kudos to Palm for tightening that up... almost.

        I took my Vx, flashed with OS4, did a sync using pi-nredir with
DLPTRACE on, trapped it into separate logfiles. Two for each sync, one right
after the other (a pair WITH a password, and another pair WITHOUT a
password). I diffed them (partial results below).

        The Palm was set with a username of 'Joe User' and the password was
set to '123' on the Palm in the following examples.

---
+SLP HDR [ 0xbe 0xef 0xed 0x03 0x03 0x02 0x00 0x41 0x08 0xeb]
+SLP RX 3->3 len=0x0041 Prot=2 ID=0x08
+PADP DATA RX FL  len=0x003d
+0000  90 01 00 00 20 37 00 00 30 39 00 00 00 00 00 00   .... 7..09......
+0010  69 1d 07 d1 05 16 00 2a 1a 00 07 d1 05 16 00 2a   i......*.......*
+0020  1a 00 09 10 4a 6f 65 20 55 73 65 72 00 20 2c b9   ....Joe User. ,.
+0030  62 ac 59 07 5b 96 4b 07 15 2d 23 4b 70            b.Y.[.K..-#Kp

+PADP DATA RX FL  len=0x003d
+0000  90 01 00 00 20 37 00 00 30 39 00 00 00 00 00 00   .... 7..09......
+0010  69 1d 07 d1 05 16 00 2a 1a 00 07 d1 05 16 00 2a   i......*.......*
+0020  1a 00 09 10 4a 6f 65 20 55 73 65 72 00 20 2c b9   ....Joe User. ,.
+0030  62 ac 59 07 5b 96 4b 07 15 2d 23 4b 70            b.Y.[.K..-#Kp
+PADP ACK TX FL  len=0x003d
---
        Look very closely at the last line of both of those packets (SLP and
PADP packets, respectively):

        The line is:

+0030  62 ac 59 07 5b 96 4b 07 15 2d 23 4b 70            b.Y.[.K..-#Kp

        Now, I simply did this:

        $ echo -n 123 | md5sum
        202cb962ac59075b964b07152d234b70

        To make it easier, let's space that out a bit:

        20 2c b9 62 ac 59 07 5b 96 4b 07 15 2d 23 4b 70

        Look familiar? Bingo!

        The sixth byte in the packet is different also, from 0x37 to 0x27,
which probably be a packet sent from the desktop to say "Hey, I'm about to
send you an MD5 password now, get ready to accept it".

        Looks like they are storing the hash in users.dat on the desktop
side, and there is a 16-byte difference there if you have a password set
(416 bytes in my file) vs. not having one set (400 bytes in the same file).

        All we now have to do is move some code into dlp.c so that it
includes a quick detection for the password being set on the device, and
then either prompt the user for the password, or just send a normal packet
without the password. You'll notice that the cvs includes two new files
(dated Fri May 25 09:22:10 2001 UTC) that will help us with this,
include/pi-md5.h and libsock/md5.c. I haven't really had the time to work on
this yet though since that time (you might recall the dependancy on them
accidentally slipped into the initial 0.9.5 release tarball).

        Judd and I spoke about this on irc a little bit back in May, and
managed to come up with a couple of exploitable areas where this could be
used malisciously.

        Palm has done a quick job of making sure nobody can get the password
as they could previously with the @stake tools, and in fact, *NOBODY* can
get the password back out of the md5 hash, it's something on the order of
340282366920938463463374607431768211456 (1<<128) possible hashes. However,
the data on the Palm is still cleartext, the data is transmitted in
cleartext over the serial port and modem and wireless connections, and the
data resides on the desktop *.DAT files in a format readable by perl and
other tools. The only place the "password" is used is to actually "initiate"
the sync. If I manually change the md5sum in users.dat, I can sync the
device as another user. If I remove the hash entirely, I can sync as *ANY*
user.  There are a few other exploits like this we found, but... you get the
idea.

        I open the floor for now for comments ...

/d


_______________________________________________
Pilot-unix mailing list
Pilot-unix@hcirisc.cs.binghamton.edu
http://hcirisc.cs.binghamton.edu/mailman/listinfo/pilot-unix
--



-- 
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.