[unisog] Password auditing

Dave Dittrich dittrich at u.washington.edu
Fri Jul 1 04:37:52 GMT 2005

> >This time I have an idea for automated auditing of UNIX
> >password (it may be extended to windows, I don't know).
> The obvious drawback to all this (as you have pointed out!) is that a copy
> of the password file resides on the audit server, and you need to set up an
> account on the audited server with access to read the password file.

You don't necessarily have to have a copy of a *valid* password file.
Just use a good dictionary of common words, known compromised
passwords, dictionaries that attackers use, etc.  E.g., there is an
ssh dictionary attack program that has some 50,000 passwords in it.
I've seen hacker sites with common dictionaries.  There is the
dictionary used by john the ripper.  And anyone who investigates
sniffers gets another list of passwords that should *never* be used
again, but users often do.  (I know of one instance where someone
recycled a set of 7 passwords.  One year after having a sniffed
password, this person got around to cycling back and within two weeks
the account was used again!)

> If the main idea is to prevent easy breakins through the use of default
> accounts, why not have a database of known default account/passwords, and
> then periodically try to log in (via telnet, ssh, mysql, SMB...) on known
> hosts using these accounts?  This would catch instances of software being
> installed with default passwords.  The benefit would be that you can start
> testing new servers or devices immediately without having to set up the .ssh
> keys and so on.  You could even test devices such as routers or switches,
> where you cannot obtain a password file to test.

That is a very good way to go.  Using the dictionaries I mentioned
above, you'd have a pretty good defense as long as you ran it nearly
constantly to catch changes.  Use of any current attacker tool de jour
is always going to get as good results for you as it does for

> The drawback of this, though, would be that every server would get a fairly
> large log of failed logins, and this may cause some over-enthusiastic
> servers to lock accounts, depending on how often you run the scan.

Don't they already have this problem from attackers?  It always amazed
me that admins would complain about the security operations group
doing scans, password checks, etc., when I could do a quick sniff on
their network and show them that it was *already* happening by
attackers several times per day!  Dictionary attacks on passwords
are common today on SMB, SSH... Its OK if the attackers do it and
you don't know it, but its not OK if authorized security folks do it
when you do know?  (Wasn't that a Seinfeld episode? ;)

Dave Dittrich                           Information Assurance Researcher,
dittrich at u.washington.edu               The iSchool
http://staff.washington.edu/dittrich    University of Washington

PGP key      http://staff.washington.edu/dittrich/pgpkey.txt
Fingerprint  FE97 0C57 0843 F3EB 49A1  0CD0 8E0C D0BE C838 CCB5

More information about the unisog mailing list