Source Code 1992 March/Source_Code_CD-ROM_Walnut_Creek_March_1992.iso/usenet/altsrcs/3/3889/README

Text File | 1991-08-23 | 20.9 KB | 591 lines

                    "Crack Version 3.2"
           A Sensible Password Checker for UNIX-


                     Alec D.E. Muffett

         Computer Unit, University College of Wales
                Aberystwyth, Wales, SY23 3DB
                       [e-mail]
                       [phone]


                          ABSTRACT

          Crack[1]  is  a  freely   available   program
     designed to find standard UNIX eight-character DES
     encrypted passwords  by  standard  guessing  tech-
     niques outlined below.  It is written to be flexi-
     ble, configurable and fast, and to be able to make
     use  of  several  networked hosts via the Berkeley
     rsh program (or similar), where possible.



1.  Intent of this program

My intentions, whilst writing this program, were

1)   To provide the average system manager  with  a  simple,
     flexible and fast tool to find passwords which would be
     easily compromised by a dictionary search.

2)   To weaken the complacency which has  developed  amongst
     many (in)?experienced UNIX systems managers about pass-
     word security. Just because the crypt() function cannot
     be  reversed  does  not  mean  that  your passwords are
     secure.  If this program helps  to  raise  the  overall
     quotient  of paranoia just one little bit, then it will
     have served its purpose and is all to the good.

I am quite certain that some childish morons out there  will
abuse  the  work that I have put into creating this program.
It's up to them how they use it, but if it's used  for  some
illegal  purpose it's not my intention, nor my fault. I hope
_________________________
  [0]
- UNIX is a trademark of Bell Laboratories.
  [1] Crack  is  available  for  anonymous   FTP   from
wuarchive.wustl.edu (128.252.135.4) in ~/packages




                      August 21, 1991





                           - 2 -


they get caught.

Crack was not designed to do anything nasty, other  than  to
attack  passwords  in  sensible order.  This is why I feel I
can post it to the net without fear of  recrimination.  This
version  of  Crack  is  supplied with a (hopefully) portable
version of fcrypt(), for speed reasons.  Fcrypt() is not yet
widely  available, but several versions have now been posted
to USENET, and with the growing ability to access  anonymous
FTP  databases like Archie, I believe that people who really
want access to such programs as fcrypt() will be able to get
them  easily.   People who need them but don't have the time
to look, on the other hand, will not get them.  This is  not
a  good thing if you are a systems manager, because it gives
the crackers an advantage.  My philosophy  is:  give  it  to
everyone, then at least the people who need it can get it.

2.  Fcrypt() Statistics

The version of fcrypt() that comes with Crack  is  some  3.4
times  faster  than the version that was originally supplied
to me, and should outperform most others which are  publicly
available.   I  haven't tried many speed-demon style tricks,
but rather I have gone for portability, elegance and simpli-
city,  where  applicable  8-).   On  a  DECStation 5000/200,
fcrypt() iterates ~550 times  per  second,  and  overall,  I
measure  this  to  be 13 times faster than standard crypt().
There are faster versions available, but  at  least  I  feel
free  to  redistrubute this version without stepping on any-
ones toes.

A final note about my motives: If you  think  that  I  am  a
moron  for  writing  and then distributing this program, and
you think that the program is in itself dangerous, I suggest
that  you  carefully  consider the fact that any moron could
have written this program.  Flames to /dev/null, please.

3.  Implementation

I have tried to make Crack as portable as  possible  without
compromising speed.  Needless to say, it is imperfect in the
this respect, but I have tried.  If you have  problems  get-
ting  Crack up, please let me know what these problems were,
and what system you were  trying  to  put  Crack  up  on.  I
believe  that  Crack will work on Xenix and various versions
of System V, but it may require a little effort if your UNIX
is not fairly modern.

There have been some nasty stories sent  back  to  me  about
problems  encountered  due to the Crack script being written
in c-shell.  Because of this, I enclose a  program  Crack.sh
which  is  a functionally equivalent script in Bourne shell,
using nohup to kick the cracker off into the background.  If
your  version of c-shell is non standard (ie: not BSDish) or



                      August 21, 1991





                           - 3 -


you are worried, you may  use  Crack.sh  in  Crack's  place.
Note,  though,  that if you want to use the network options,
you will also have to  edit  Scripts/RCrack  to  change  the
program-name  that is called on remote machines to Crack.sh.
For more on this, see below.

To use the Crack -network option, you must have  rsh,  or  a
similar  program.  rsh  is a BSD-ism which has become fairly
common on non-BSD systems.  If you don't have  it  or  some-
thing  similar,  let  me  know what you do have which might,
with a little ingenuity, do the job, and I shall see what  I
can do.  Again, have a look in Scripts/RCrack if you want to
play around.

     Note: Xenix users and some others have a rcmd pro-
     gram  instead of rsh.  I'm not sure of the correct
     syntax for this program, but it should not be hard
     to  get  it  to work.  There is a note about it in
     Scripts/RCrack

     On such System V based systems, users may also  be
     missing  the  BSD function gethostname().  If this
     is so, but you do have the  uname()  system  call,
     define  the  macro  CRACK_UNAME  in Sources/conf.h
     instead. This ought to fix the problem, but it may
     need  a little user intervention first (it depends
     where your header file for  uname()  is).   Caveat
     Emptor!

4.  Method of Password Cracking

Crack does not take the serial approach to password guessing
that  other  programs  like  the COPS password cracker does.
Rather, Crack makes two  passes  over  the  users'  password
entries.

The first pass bases its guesses  on  the  contents  of  the
gecos field (containing the users' real name), and the user-
name itself.  The first pass is fast and usually very fruit-
ful, and completes quite quickly.  You would be surprised at
the number of spods out there who  still  think  that  their
middle name, backwards and capitalised, is a good password.

The second pass is made by encrypting several  pre-processed
dictionaries  on  the  fly,  and  comparing the results with
users passwords.  Crack optimises the number of calls to the
encryption  function  by sorting the user passwords by their
encryption salt before loading,  so  that  the  dictionaries
only  have  to  be  encrypted  once for each different salt.
This generally saves about 30% of the calls you  would  have
to make to crypt().

The preprocessed dictionaries are  created  my  merging  the
source  dictionaries found in the directory DictSrc and then



                      August 21, 1991





                           - 4 -


truncating, sorting and uniq'ing the output from the prepro-
cessor.   The default dictionaries named are /usr/dict/words
which  provides  the   bulk   of   the   input   data,   and
DictSrc/bad_pws.dat  which  is meant to provide all of those
non-dictionary passwords, such as 12345678 or qwerty.[2]

If you wish to add a dictionary of your own,  just  copy  it
into  the  DictSrc directory and then delete the contents of
the Dicts directory.  Your new dictionary will be merged  in
on the next run.  Do not worry about replication of data, as
the preprocessor driver script sorts  and  uniq's  the  data
before putting it into the Dicts directory.

The formats of the output dictionaries are:

a)   Unique words that have been forced lowercase, forwards.
     These are the most common passwords you will find, thus
     they are tried first.

b)   Dictionary words which have been  artificially  plural-
     ised, because not many dictionaries contain plurals.

c)   Dictionary words which were supplied in mixed-case (eg:
     Capitalised).

d)   Dictionary words forced lowercase and backwards.

e)   Dictionary words, forced lowercase, with a  leading  or
     trailing  0  or  1  (this  may  be  extended by hacking
     Sources/crack-pp.c).

f)   Dictionary words, forced uppercase, forwards.

g)   Dictionary words, forced uppercase, backwards.

h)   Dictionary words which  were  supplied  in  mixed-case,
     backwards (eg: desilatipaC).


This choice of attack is entirely  empirical,  my  own,  and
made up on the spot.  It has also been horrendously success-
ful, and because Crack uses each of  these  dictionaries  in
turn,  it  tends to get passwords faster than a program like
the COPS password cracker which tries words  every-which-way
for each user.[3]
_________________________
  [2] Extra dictionaries (those used in Dan Klein's pa-
per,  below)  can  be  obtained  via anonymous FTP from
uunet.uu.net (192.48.96.2) as ~/pub/dictionaries.tar.Z
  [3] For more information, see "Foiling the Cracker: A
Survey of, and Improvements to, Password  Security"  by
Daniel Klein, available from major FTP sites.




                      August 21, 1991





                           - 5 -


     Optimisation  Note:  Crack  has  an   compile-time
     option,  called CRACK_SHORT_PASSWDS, which, if not
     defined, makes the dictionary  preprocessor  throw
     away  words which are less than 5 characters long.
     The reasoning for this is that many sites, with  a
     semi-sensible  passwd program, will not have pass-
     words shorter than 5 characters long.

     It is up to you whether you bother  testing  these
     short passwords, but I would recommend that you do
     so at least once, to be safe.  (Setting the option
     also  leads  to  having smaller pre-processed dic-
     tionaries.  The option,  however,  is  defined  by
     default)

5.  Installation

Crack is one of those most  unusual  of  beasties,  a  self-
installing   program.    Once  the  necessary  configuration
options have been  set,  the  executables  are  created  via
'make' by running the main shellscript.

Some people have complained about this  apparent  weirdness,
but  it has grown up with Crack ever since the earliest net-
work version, when I could  not  be  bothered  to  log  into
several  different machines with several different architec-
tures, just in order to build the binaries.

Crack needs to know where it  has  been  installed.   Please
edit the CRACK_HOME variable in the Crack shellscript to the
correct value.  This variable should be set to  an  absolute
path name (relative to ~user is OK) through which the direc-
tory containing Crack may be accessed on  all  the  machines
that Crack will be run on.

The other bit of installation you will have to do is  decide
whether you will want to use the -network option. If you do,
edit the file Sources/conf.h and  define  the  CRACK_NETWORK
symbol.  This forces Crack to create all of its output files
with an embedded hostname  (obtained  by  the  gethostname()
routine)  so that you can keep track of output from all over
the network.  If  you  have  no  gethostname()  but  have  a
uname()  system  call, you can use that instead, by defining
CRACK_UNAME in Sources/conf.h.

You will then have to generate a Scripts/network.conf  file.
This  contains  a  list  of  hostnames to rsh to, what their
binary type is (useful  when  running  a  network  Crack  on
several  different  architectures),  a  guesstimate of their
relative power (take your  slowest  machine  as  unary,  and
measure  all  others relative to it), and a list of per-host
default flags.  There is an example of such a file  provided
in the Scripts directory - take a look at it.




                      August 21, 1991





                           - 6 -


I also recommend that you play around with the  #defines  in
the  file  Sources/conf.h.   Each  switch  has  a small note
explaining its meaning.  Where I've been in doubt about  the
portability  of  certain library functions, usually I've re-
written it, so it shouldn't be much of a  problem.   Let  me
know of your problems. 8-).

6.  Crack Usage


Crack [options] [bindir] /etc/passwd [...other passwd files]

Crack -network [options] /etc/passwd [...other passwd files]


Where bindir is the optional name of the directory where you
want  the binaries installed.  This is useful where you want
to be able to run versions of  Crack  on  several  different
architectures.  If  bindir does not exist, a warning will be
issued, and the directory, created.

     Note: bindir defaults to the name generic  if  not
     supplied.

     Yellow Pages (NIS) Users: I have had some  queries
     about  how to get Crack running from a YP password
     file.  There are several methods, but by  far  the
     simplest  is  to  generate a passwd format file by
     running:-

                    ypcat passwd > passwd.yp

     and then running Crack on this file.

7.  Options

-network
     Throws Crack into network mode, in which it  reads  the
     Scripts/network.conf file, splits its input into chunks
     which are sized according to the power  of  the  target
     machine,  and  calls  rsh to run Crack on that machine.
     Options for Crack running on the target machine may  be
     supplied  on  the  command line (eg: verbose or recover
     mode), or in the network.conf file if they  pertain  to
     specific hosts (eg: nice() values).

-v   Sets verbose mode, whereby Crack will print every guess
     it is trying on a per-user basis.  This is a very quick
     way of flooding your filestore.  If  you  undefine  the
     CRACK_VERBOSE  symbol  in  Sources/conf.h, verbose mode
     will be permanently disabled.

-nvalue
     Sets the process to be nice()ed to value, so  that  the



                      August 21, 1991





                           - 7 -


     switch -n19 sets the Crack process to run at the lowest
     priority.

-rpointfile
     This is only for use  when  running  in  recover  mode.
     When  a  running  Crack  starts pass 2, it periodically
     saves  its  state  in  a  file  named  point.<pid>   or
     point.<hostname>.<pid> depending on your naming conven-
     tion (see "Installation", above).   This  file  can  be
     used  to  recover  where  you were should a host crash.
     Simply invoke Crack in exactly the same manner  as  the
     last  time,  with the addition of the -rpoint.file.name
     switch.  Crack will startup and read the file, and jump
     to  slightly  before  where  it  left  off.  If you are
     cracking a very large  password  file,  this  can  save
     oodles of time after a crash.

     If you are running a network Crack, then the  jobs
     will again be spawned onto all the machines of the
     original Crack.  The program will then check  that
     the  host  it is running on is the same as is men-
     tioned in the pointfile.  If it is  not,  it  will
     silently  die.  Thus, assuming that you supply the
     same  input  data   and   do   not   change   your
     network.conf  file,  Crack  should pick up exactly
     where it left off.  This is a bit  inelegant,  but
     it's better than nothing at the moment.

8.  Multiprocessing and parallelism

The method of error recovery outlined above causes headaches
for  users who want to do multiprocessing on parallel archi-
tectures.  Crack is in no way parallel, and because  of  the
way  it's  structured,  readind stdin from shellscript fron-
tends, it is a pain  to  divide  the  work  amongst  several
processes via fork()ing.

The hack solution to get several copies of Crack running  on
one  machine  with n processors at the moment is to run with
the CRACK_NETWORK option enabled, and insert n copies of the
entry     for     your    parallel    machine    into    the
Scripts/network.conf file. If you use the -r option in these
circumstances   however,  you  will  get  n  copies  of  the
recovered process running, only one of them  will  have  the
correct  input data.  I'm working on this.  My current solu-
tion is to save the current username in the checkpoint file,
and  test  it  on  startup,  but  doing  this may break your
recovery if you supply different input  data  (so  that  the
data  is  sorted even slightly differently).  Hohum.  If you
want to use this verify username facility, use -R  in  place
of -r.

As for not using the network.conf file to provide  multipro-
cessing, I'm working on it.



                      August 21, 1991





                           - 8 -


9.  Notes on fast crypt() implementations

The stdlib version of the crypt() subroutine  is  incredibly
slow.   It is a massive bottleneck to the execution of Crack
and on typical platforms that you get at universities, it is
rare to find a machine which will achieve more than 50 stan-
dard crypt()s per second.  On low-end diskless workstations,
you  may  expect 2 or 3 per second.  It was this slowness of
the crypt() algorithm which originally supplied much of  the
security UNIX needed.[4]

However, there are now many implementations of  faster  ver-
sions  of  crypt() to be found on the network.  The one sup-
plied with Crack v3.2 and upwards is called fcrypt().

fcrypt() was  originally  written  in  May  1986  by  Robert
Baldwin at MIT, and is a good version of the crypt() subrou-
tine.  I received a copy from Icarus Sparry at Bath  Univer-
sity,  who  had made a couple of portability enhancements to
the code.

I rewrote most of the tables and the KeySchedule  generating
algorithm  in  the original fdes-init.c to knock 40% off the
execution overhead of fcrypt()  in  the  form  that  it  was
shipped  to  me.   I inlined a bunch of stuff, put it into a
single file, got  some  advice  from  Matt  Bishop  and  Bob
Baldwin  [both  of whom I am greatly indebted to] about what
to do to the xform() routine  and  to  the  fcrypt  function
itself, and tidied up some algorithms.  I've also added more
lookup tables and reduced several formula  for  faster  use.
fcrypt()  is  now  barely recognisable as being based on its
former incarnation.

On a DecStation 5000/200, it is also ~13 times  faster  than
the  standard crypt (your mileage may vary with other archi-
tectures and compilers).  This speed puts fcrypt() into  the
"moderately fast" league of crypt implementations.  By using
fcrypt() with Crack, I extracted 135 passwords from my stan-
dard 1087 user password file in a little over 1 hour using 3
networked machines.  This is from a moderately good password
file.

Why am I saying this sort of thing ? Am I  scaremongering  ?
In a word, yes.

If a fast version of crypt() is wired into  a  program  like
Crack it can break a poorly passworded site open in minutes.
There are such programs available, eg: the "Killer  Cracker"
written  by the anonymous "Doctor Dissector", with anonymous
motives.  It comes with  a  modified  version  of  Baldwin's
_________________________
  [4] See: "Password Security, A Case History"  by  Bob
Morris & Ken Thomson, in the UNIX Programmer Docs.



                      August 21, 1991





                           - 9 -


fcrypt, as a MS-DOS executable with a GNU copyleft licence.

The point that needs to be  hammered  home  is  that  unless
something  is done, and done soon, about the general quality
of passwords on UNIX systems, then in the  near  future  our
doors  will  be  wide  open to people who have programs like
Crack and questionable motives.

10.  Solutions and Conclusions

What can be done about this form of attack ?

You must get  a  drop-in  replacement  for  the  passwd  and
yppasswd  commands; one which will stop people from choosing
bad passwords in the first place.  There  are  several  pro-
grams  to  do this; Matt Bishop's passwd+ and Clyde Hoover's
npasswd program are good examples which  are  freely  avail-
able.   Consult an Archie database for more details on where
you can get them from.

A little common-sense is all that is required to  vet  pass-
words:   I   enclose  a  module  in  the  Sources  directory
goodpass.c which I use in a modified version of the yppasswd
in order to provide some security.  It is quite heavily cus-
tomised for use in the UK, but it should be easily portable.
The routine is invoked:


           char *retval = GoodPass(char *input);


where input is the password under test, and retval  will  be
set  either to NULL (if the password is OK) or to a diagnos-
tic string which says what is wrong with the  password.   It
is far less complex than a system such as passwd+, but still
effective enough to make a password  file  withstand  Crack.
It would be nice if an organisation (such as CERT?) could be
persuaded to supply skeletons of  sensible  passwd  commands
for  the  public  good,  as  well  as an archive of security
related utilities[5] on top of the excellent COPS.  However,
for UNIX security to improve on a global scale, we will also
require pressure on the vendors, so that programs are  writ-
ten correctly from the beginning.






_________________________
  [5] COPS  is  available  for   anonymous   FTP   from
cert.sei.cmu.edu (128.237.253.5) in ~/cops




                      August 21, 1991