[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100620141506.GA30628@openwall.com>
Date: Sun, 20 Jun 2010 18:15:06 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Issues with JtR auditing Solaris 10 Sha512 alogirthm passwords
On Sun, Jun 20, 2010 at 01:30:08AM -0400, Robert Harris wrote:
> I'm using the latest version of JtR (john-1.7.6-jumbo-3), running on
> windows. I compiled it for cygwin, all thre choices mmx,sse, and any.
JtR does not yet support SHA-crypt hashes on Windows - nor on any other
system that does not support those hashes natively, for that matter.
The README makes this clear:
---
When running on Linux distributions with glibc 2.7+, John 1.7.6+
additionally supports (and autodetects) "SHA-crypt" hashes (which are
actually used by recent versions of Fedora and Ubuntu), with optional
OpenMP parallelization (requires GCC 4.2+, needs to be explicitly
enabled at compile-time by uncommenting the proper OMPFLAGS line near
the beginning of the Makefile).
Similarly, when running on recent versions of Solaris, John 1.7.6+
supports and autodetects "SHA-crypt" and SunMD5 hashes, also with
optional OpenMP parallelization (requires GCC 4.2+ or recent Sun Studio,
needs to be explicitly enabled at compile-time by uncommenting the
proper OMPFLAGS line near the beginning of the Makefile and at runtime
by setting the OMP_NUM_THREADS environment variable to the desired
number of threads).
---
> Here is a unshadow file, called server1, its contents is from a Solaris 10
> x86 system with patch 140906-01:
>
> test:$6$MDZEL9CQ$ZentsLbLWphRB2./B0xKv1vWPY9IBknYrcD.3SlY5RamKsnzlCSC4ImT3KW
> Y8rXMbodbFA9wDrlf51DT3HgoW1:102:14::/home/test:/bin/sh
...
> Here is a unshadow file, called server1, its contents is from a Solaris 10
> x86 system with patch 140906-02:
>
> test:$6$dofn/L59$nygYCacync7RzPfYjWZ1OO6b8MZDETUzYP2SbJD0PPqXDjQ3caVlR8/O6G2
> DSMh.6X0Dzwre86QPifkEU22dW/:102:14::/home/test:/bin/sh
...
> Linux ubuntu 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:49:34 UTC 2009
> i686 GNU/Linux
...
> robert:$6$U4dzp4gvMho3$hAUA8cpTUdHnNjuMFUtiXzd0NL85RMNihshXdks/7LD5zDVseUawK
> 1JIotk5JVZoyacpHy.Vuja0b9GD2gZ0J.:14527:0:99999:7:::
I corrected/removed the extra linefeeds inside the hash encodings
(presumably those linefeeds were introduced in the e-mail message only)
and combined the three password file lines above into a single file for
my testing. Here it is, as seen on a Solaris system I will be using:
[solar@...t ~]$ cat pw-sha-rs904c
test:$6$MDZEL9CQ$ZentsLbLWphRB2./B0xKv1vWPY9IBknYrcD.3SlY5RamKsnzlCSC4ImT3KWY8rXMbodbFA9wDrlf51DT3HgoW1:102:14::/home/test:/bin/sh
test:$6$dofn/L59$nygYCacync7RzPfYjWZ1OO6b8MZDETUzYP2SbJD0PPqXDjQ3caVlR8/O6G2DSMh.6X0Dzwre86QPifkEU22dW/:102:14::/home/test:/bin/sh
robert:$6$U4dzp4gvMho3$hAUA8cpTUdHnNjuMFUtiXzd0NL85RMNihshXdks/7LD5zDVseUawK1JIotk5JVZoyacpHy.Vuja0b9GD2gZ0J.:14527:0:99999:7:::
Here's how this file may be processed with JtR on a Solaris 10 system
with 64-bit x86 CPUs (two dual-core Opterons in this case). We'll start
by extracting a clean JtR 1.7.6 tarball (no patches) and compiling John:
[solar@...t ~]$ gzip -dc john-1.7.6.tar.gz | tar xvf -
x john-1.7.6, 0 bytes, 0 tape blocks
x john-1.7.6/doc, 0 bytes, 0 tape blocks
x john-1.7.6/doc/EXAMPLES, 15156 bytes, 30 tape blocks
[...]
x john-1.7.6/src/DES_vec.pl, 958 bytes, 2 tape blocks
x john-1.7.6/README symbolic link to doc/README
[solar@...t ~]$ cd john-1.7.6/src
[solar@...t ~/john-1.7.6/src]$ make solaris-x86-64-gcc
ln -sf x86-64.h arch.h
[...]
ln -s john ../run/unique
We've successfully compiled John with gcc. Another option was to use
the Sun Studio compiler. The make target would be solaris-x86-64-cc.
In this case, the choice was arbitrary - the system had both compilers
installed and either would work. In another case, only one of the two
compilers might be present. (A quicker build may be possible with
"gmake -j4 solaris-x86-64-gcc" or the like if GNU make is installed.)
Now let's try to use John:
[solar@...t ~/john-1.7.6/src]$ cd ../run/
[solar@...t ~/john-1.7.6/run]$ ./john ../../pw-sha-rs904c
Loaded 3 password hashes with 3 different salts (generic crypt(3) [?/64])
guesses: 0 time: 0:00:00:11 63% (1) c/s: 189 trying: Robert92 - robert9999980
guesses: 0 time: 0:00:00:19 91% (1) c/s: 189 trying: 999991981 - r999992005
password (robert)
guesses: 1 time: 0:00:00:23 0% (2) c/s: 189 trying: 12345 - missy
password (test)
password (test)
guesses: 3 time: 0:00:00:24 100% (2) c/s: 189 trying: 12345 - missy
I pressed "any key" a few times to obtain those non-100% status lines
above. It could be seen that John was trying username-based passwords
first. Also, it obviously mis-parsed the shadow file line from the
Ubuntu system - that's where the attempts to use the string "99999" in
candidate passwords came from. This is because John expects an
/etc/passwd format file, not an /etc/shadow format one. You really
ought to use unshadow. Anyhow, this did not result in anything going
very wrong this time - only in a little bit of time wasted on trying
strings with "99999" instead of those with the user's full name (which
would come from /etc/passwd). Then John proceeded with "pass 2", which
is the wordlist mode, and it tried "password" soon because it's found
near the beginning of the common passwords list in password.lst.
Now let's display the results properly:
[solar@...t ~/john-1.7.6/run]$ ./john --show ../../pw-sha-rs904c
test:password:102:14::/home/test:/bin/sh
test:password:102:14::/home/test:/bin/sh
robert:password:14527:0:99999:7:::
3 password hashes cracked, 0 left
That's it. But we were only using one out of four CPU cores. Let's try
to use all four. We need to make an OpenMP-enabled build. First, clean
out the old build:
[solar@...t ~/john-1.7.6/run]$ cd ../src
[solar@...t ~/john-1.7.6/src]$ make clean
[...]
Then enable OpenMP. Since this specific system happens to have an old
version of gcc (not OpenMP-capable yet), we'll use the Sun Studio
compiler (which is recent enough in this case). We need to uncomment
one of the OMPFLAGS lines near the beginning of Makefile:
[solar@...t ~/john-1.7.6/src]$ vi Makefile
We locate the line for Sun Studio and remove the leading "#" character.
Before our edits:
# Sun Studio with OpenMP (set the OMP_NUM_THREADS env var at runtime)
#OMPFLAGS = -xopenmp
After the edits:
# Sun Studio with OpenMP (set the OMP_NUM_THREADS env var at runtime)
OMPFLAGS = -xopenmp
(the true comment remains with its "#" character, but the variable
assignment is now uncommented).
Now let's make the new build:
[solar@...t ~/john-1.7.6/src]$ make solaris-x86-64-cc
ln -sf x86-64.h arch.h
[...]
cc -c -fast -xarch=native64 -DHAVE_CRYPT -xopenmp c3_fmt.c
[...]
ln -s john ../run/unique
And let's test it:
[solar@...t ~/john-1.7.6/src]$ cd ../run/
[solar@...t ~/john-1.7.6/run]$ rm john.pot
[solar@...t ~/john-1.7.6/run]$ OMP_NUM_THREADS=4 ./john ../../pw-sha-rs904c
Loaded 3 password hashes with 3 different salts (generic crypt(3) [?/64])
guesses: 0 time: 0:00:00:02 42% (1) c/s: 672 trying: atest - TheTest
guesses: 0 time: 0:00:00:05 99% (1) c/s: 674 trying: 999991912 - 999991900
password (robert)
password (test)
password (test)
guesses: 3 time: 0:00:00:06 100% (2) c/s: 663 trying: 12345 - missy
This has completed in 6 seconds instead of 24, although with more
precise timing (used by John internally) the speedup was "only" 3.5x in
this case (189 c/s to 663 c/s). The system appeared to be under some
light load unrelated to John, though.
The "--show" option works as usual:
[solar@...t ~/john-1.7.6/run]$ ./john --show ../../pw-sha-rs904c
test:password:102:14::/home/test:/bin/sh
test:password:102:14::/home/test:/bin/sh
robert:password:14527:0:99999:7:::
3 password hashes cracked, 0 left
Now that's it. You could do it on a Linux system with glibc 2.7+ too.
The make targets to use and the OMPFLAGS line to uncomment (with recent
gcc) would be different, but overall it'd be similar. Also, setting
OMP_NUM_THREADS explicitly would be optional with gcc on Linux (all
logical CPUs would be used by an OpenMP-enabled build by default).
> Attached is a PDF document the Sun/Oracle wrote about this latest patch.
Thank you, this is very helpful.
FYI, you got pretty close to the mailing list's current message size
limit, which is set at 80 KB including headers and MIME overhead. If
you (or another list member) ever need to share a larger file, please
post a download link instead.
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.
