[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AANLkTinLwwReDukqczJSb43Ay2rJQfT7maJqP7VjCQLb@mail.gmail.com>
Date: Sat, 28 Aug 2010 15:00:39 +0200
From: fijam 7 <fijam7@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: A puzzling hash from the past
On Fri, Aug 27, 2010 at 4:16 PM, Solar Designer <solar@...nwall.com> wrote:
> 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
>
This is a most informative reply, thank you. My Google-fu must have
been weak that day :)
Regards,
JM
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.
