[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100827141631.GA7380@openwall.com>
Date: Fri, 27 Aug 2010 18:16:31 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: A puzzling hash from the past
On Fri, Aug 27, 2010 at 10:18:07AM +0200, fijam 7 wrote:
> I recently analyzed the firmware of a certain discontinued router that
> I have and managed to extract a cramfs filesystem. There, I found
> /etc/shadow with a strange hash:
>
> user:$1juTFYmn618Y:12086::99999::::
>
> To my understanding, a DES hash should have 13 characters in base64
> digits (including the salt). Any ideas why does it start with a '$'?
Yes: a program setting the password attempted to use an MD5-based crypt
hash, so it provided a salt proper for that hash type, but the system's
libc (or libcrypt) lacked the support, so it produced a DES-based crypt
hash with the invalid salt of "$1" instead.
> It appears that the firmware utilized tinylogin 0.80 and uClibc
> 0.9.26. I had a look at the source but found no clues.
Different implementations of DES-based crypt(3) process invalid salts
differently. I don't know how uClibc in particular processes them.
JtR implements one of the possible mappings, but if it's not right for
your target system (for uClibc in this case) then you need to replace
the '$' character with a "correct" one that maps to the same 6-bit
value that uClibc maps the '$' to.
Please refer to these older postings for more detail on the topic:
http://www.openwall.com/lists/john-users/2009/02/28/1
http://www.openwall.com/lists/john-users/2008/10/03/2
Both are linked from:
http://openwall.info/wiki/john/mailing-list-excerpts
* Invalid salts with traditional DES-based crypt(3) (2009/02/28)
* Invalid salts - more info on the two known mappings (2008/10/03)
Since then, I found out that FreeSec - the DES-based crypt(3) code in
use on free *BSD systems - maps all invalid salt characters simply to
all zero bits (same as the '.' character). However, this shouldn't be
relevant to your case. I mention it for the sake of completeness (for
others reading this, including via the mailing list archives).
I've recently fixed the copy of FreeSec in Owl and in PHP 5.3.2+
(submitted/committed via a PHP developer) to mimic UFC-crypt instead,
since obviously mapping all invalid salt characters to just one
equivalent character would make the common application problems worse
(for broken apps that feed those invalid salts to crypt() when setting a
new password, which I imagine is especially common for PHP scripts).
I hope this response helps, despite of the excessive detail. ;-)
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
