Cracking OpenVMS passwords with John the Ripper
Jean-loup Gailly
to allow cracking OpenVMS (Vax and Alpha) passwords. The patch is based on
code from Shawn Clifford, Davide Casale and Mario Ambrogetti.
The sources are in http://jl.gailly.net/security/john-VMS-patch.tar.gz
A README file is at http://gailly.net/security/john-VMS-readme.html
or in ascii at http://jl.gailly.net/security/README.VMS
This patch has been tested on x86 only and does not work yet on big endian
systems. It uses asm code for speed but a portable C version is included as
well. The asm version checks about 150,000 passwords per second on a 1 GHz
system. Password cracking is much easier on OpenVMS than on other systems
since passwords are not case sensitive and limited to alphanumeric,
'$' and '_' only.
Jean-loup Gailly
http://gailly.net/security/
Shane Smith
doubt it will be particularly effective against a properly secured VMS
system. Successive failed guesses would incur longer delays between
retries, and after a few failures it'd lock off the account. IIRC,
that's default settings out of the box, but I haven't done a fresh
install in a while so I'd welcome corrections from those with fresher
(or better) memories.
Shane
Robert Deininger
<ssm...@icius.com> wrote:
>If this is a password guesser, which your wording suggests it is, I
>doubt it will be particularly effective against a properly secured VMS
>system. Successive failed guesses would incur longer delays between
>retries, and after a few failures it'd lock off the account. IIRC,
>that's default settings out of the box, but I haven't done a fresh
>install in a while so I'd welcome corrections from those with fresher
>(or better) memories.
No, he's copying the SYSUAF to another system, guessing plaintext
passwords, hashing them, and comparing to the hashed password stored in
SYSUAF. I don't know if the hashing algoithms are correct, complete, and
up-to-date, but they look plausible.
Since the method bypasses the usual VMS login checks, it gets as many
guesses as it needs. This is a fairly old strategy for obtaining VMS
passwords, and is valid in some environments. A system manager might want
to weed out passwords that are easily guessed. It isn't a serious
security risk, since the SYSUAF isn't readable by non-prived users. (The
default protection is world:nothing for SYSUAF.)
JF Mezei
> doubt it will be particularly effective against a properly secured VMS
> system.
If the program has access to the sysuaf.dat FILE, then it can try all the
passwords it wants without arousing any suspicion by the VMS operating system
(expecially if it makes a copy of the file for its own use). Note that the
poster said that the program was a wintel one, so one would expect it would
have its own local SYSUAF.DAT.
Shane Smith
properly locked down system, so it's still of limited use to hackers.
They'd have to get in and get privs to get the file, and the program
would be fairly pointless once you'd done that.
Shane
JF Mezei
>
> True. However, access to that file would also be restricted in a
> properly locked down system, so it's still of limited use to hackers.
> They'd have to get in and get privs to get the file, and the program
> would be fairly pointless once you'd done that.
But if you have a system manager as an accomplice, he hand send you the
sysuaf.dat, you crack the boss's password and can then have "fun" on the
system, undetected and without any intrusion attempts.
This is why it is very important to have full trust in anyone with privileges
in your system.
MikeR
cracking?
1. Get DETACH/IMPERSONATE privs.
2. Use the SYS$PERSONA calls.
Mike
"JF Mezei" <jfmezei...@vl.videotron.ca> wrote in message
news:3DE48345...@vl.videotron.ca...
Shane Smith
HGLOGIN. Been there, done that, the boss in question laughed with the
rest of us. (It was a harmless little prank.)
Shane
-----Original Message-----
From: JF Mezei [mailto:jfmezei...@vl.videotron.ca]
Sent: Wednesday, November 27, 2002 12:33 AM
To: Info...@Mvb.Saic.Com
Subject: Re: Cracking OpenVMS passwords with John the Ripper
Nic Clews
>
> I have written a patch for John the Ripper http://www.openwall.com/john/
> to allow cracking OpenVMS (Vax and Alpha) passwords. The patch is based on
> code from Shawn Clifford, Davide Casale and Mario Ambrogetti.
...
> This patch has been tested on x86 only and does not work yet on big endian
> systems. It uses asm code for speed but a portable C version is included as
> well. The asm version checks about 150,000 passwords per second on a 1 GHz
> system. Password cracking is much easier on OpenVMS than on other systems
> since passwords are not case sensitive and limited to alphanumeric,
> '$' and '_' only.
Slightly optimistic Jean-loup. Before anyone has a heart attack, I'll
clarify your context and explain why I think it's optimistic.
As you point out, you need access to a copy of the SYSUAF.DAT. If a
system ever got into that state from a genuine crackers' point of view,
I'd quit now and open a Burger stand (there's been enough advice here on
that already).
Secondly, a password list you hit a single user account with in the most
part cannot exist in those that are in the password dictionary (where
implemented!), and for those of us that use the password policy module
forcing the presence of non alphabetic characters and therefore _really_
'unreal' words, you'd have to slow that 150,000 guesses per second down
by generating effectively random strings of all allowable characters in
a password, versus the expected lengths (8 to 32 characters?). I don't
really believe that anyone has the storage or the time to pregenerate
such a colossal list, moving each character through all possible
combinations starting at some arbitrary length, and extending to the
maximum allowable or expected (and risking missing longer ones). The
sheer time to perform the IO alone to this list makes a mockery of the
technique. An Alpha would certainly outclass your Wintel box several
hundred fold in this department alone.
I guess the problem of porting code to different platforms is not
knowing what preconditions can be applied to passwords, and in the case
of OpenVMS, we've been quite blessed with an array of security options,
native to the operating system, when when properly implemented, even a
determined hacker would switch to a softer target and use anything
learnt to resume an otherwise fruitless attack on the OpenVMS box. All
the more reason to allow an OpenVMS box to manage the secrets, rather
than some other system with the water tightness of a teabag. Even taking
that into account, sex, sodium pentathol and large amounts of cash are
probably more viable alternatives in the 'social engineering' stakes.
However, there may be those that need a wake-up call, and your port of
the cracker and what it _can_ do, should hopefully inspire a system
manager to check their environment. As stated its prime purpose is to
detect weak passwords, and if you as a system manager found yourself in
this position, I'd go stock up on burgers right now. Complacency is the
biggest threat of all.
(Nice site by the way.)
--
Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences
nclews at csc dot com
Jan C. Vorbrüggen
> systems. It uses asm code for speed but a portable C version is included as
> well. The asm version checks about 150,000 passwords per second on a 1 GHz
> system. Password cracking is much easier on OpenVMS than on other systems
> since passwords are not case sensitive and limited to alphanumeric,
> '$' and '_' only.
However, VMS's use of a salt in the encrpytion process makes it impossible
to attack all passwords in a given file simultaneously. If you're just
targetting one specific user, that doesn't make a difference, of course.
Jan
Tomasz Dryjanski
of
> cracking?
> 1. Get DETACH/IMPERSONATE privs.
> 2. Use the SYS$PERSONA calls.
Or you may even change the user's password temporarily.
Some years ago I wrote a program capable of storing a hashed password,
and then restoring it back.
There is no much fun to break-in to a system you have administrative rights
to. ;)
T. D.
Larry Kilgallen
> If you have a system manager as an accomplice, why go to all the trouble of
> cracking?
> 1. Get DETACH/IMPERSONATE privs.
> 2. Use the SYS$PERSONA calls.
3. Please don't top-post.
4. The vulnerability to such a tool is when people have access to
unencrypted backup tapes. At some shops that is easier to achieve
than privileged access to the running system.
David Webb
>If this is a password guesser, which your wording suggests it is, I
>doubt it will be particularly effective against a properly secured VMS
>system. Successive failed guesses would incur longer delays between
>retries, and after a few failures it'd lock off the account. IIRC,
>that's default settings out of the box, but I haven't done a fresh
>install in a while so I'd welcome corrections from those with fresher
>(or better) memories.
>
>Shane
>
access to the sysuaf file (and copied it to a (intel) system) where he can run
John the ripper against it.
I don't know very much about John The Ripper but would assume you provide it
with a wordlist (dictionary of words) which John the Ripper then hashes with
all possible salts and compares against the hashes in the filched sysuaf.
If a hacker has gained access to the sysuaf then you have bigger problems than
the fact they can run John the Ripper.
David Webb
VMS and Unix team leader
CCSS
Middlesex University
Bob Koehler
> doubt it will be particularly effective against a properly secured VMS
> system. Successive failed guesses would incur longer delays between
> retries, and after a few failures it'd lock off the account. IIRC,
> that's default settings out of the box, but I haven't done a fresh
> install in a while so I'd welcome corrections from those with fresher
> (or better) memories.
The stated purpose of John the Ripper is to improve UNIX security.
If you're still using a world readable password file on a UNIX system
you sure better use something like this. If your using VMS or a
shadow password file on UNIX, this may help.
Our UNIX system admins run a similar tool all the time.
David Webb
>> If you have a system manager as an accomplice, why go to all the trouble
>of
>> cracking?
>> 1. Get DETACH/IMPERSONATE privs.
>> 2. Use the SYS$PERSONA calls.
>
>Or you may even change the user's password temporarily.
>Some years ago I wrote a program capable of storing a hashed password,
>and then restoring it back.
DCL.
David Webb
VMS and Unix team leader
CCSS
Middlesex University
David Mathog
jl...@gailly.OmitThisWord.net (Jean-loup Gailly) wrote:
> I have written a patch for John the Ripper http://www.openwall.com/john/
> to allow cracking OpenVMS (Vax and Alpha) passwords. The patch is based on
> code from Shawn Clifford, Davide Casale and Mario Ambrogetti.
Which is nice but of little relevance to VMS security. Only a priv'd user
should be able to read SYSUAF.DAT, and if that user has evil intentions
then the system is already compromised - there's no need to crack
the password file. This contrasts with many (most?) Unix systems, where
everybody can read the encrypted password file.
Regards,
David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
Georges A. Tomazi
David -
On Wed, 27 Nov 2002 08:27:48 -0800, David Mathog <mat...@caltech.edu>
wrote:
[...]
>This contrasts with many (most?) Unix systems, where
>everybody can read the encrypted password file.
That's not anymore true. Most if not all current Unix systems use now
the shadow file (Solaris, Irix, Linux, OpenBSD, NetBSD, etc...).
Georges
--
Georges A. Tomazi - g...@sunwizard.net
Robert Deininger
(Larry Kilgallen) wrote:
>4. The vulnerability to such a tool is when people have access to
> unencrypted backup tapes. At some shops that is easier to achieve
> than privileged access to the running system.
Good point.
Hoff Hoffman
:From: jl...@gailly.OmitThisWord.net
:[mailto:jl...@gailly.OmitThisWord.net]
:Sent: Tuesday, November 26, 2002 3:11 PM
:To: Info...@Mvb.Saic.Com
:Subject: Cracking OpenVMS passwords with John the Ripper
..
:I have written a patch for John the Ripper http://www.openwall.com/john/
:to allow cracking OpenVMS (Vax and Alpha) passwords. The patch is based
:on code from Shawn Clifford, Davide Casale and Mario Ambrogetti.
Password-guessing tools and dictionary attacks have been around for
eons, and OpenVMS has mechanisms that can help reduce the exposure
to even poorly-chosen user passwords.
In particular, the OpenVMS breakin evasion mechanisms.
This breakin evasion security mechanism is enabled and operating by
default on all recent OpenVMS releases.
That said, password-cracking tools -- whether this one or other of
the various options -- can be quite valuable as security auditing
tools for the system manager. In particular, these tools permit
the system manager to look for weak user passwords.
:The sources are in http://jl.gailly.net/security/john-VMS-patch.tar.gz
:A README file is at http://gailly.net/security/john-VMS-readme.html
:or in ascii at http://jl.gailly.net/security/README.VMS
The correct addresses appear to be:
http://www.teaser.fr/~jlgailly/security/
http://www.openwall.com/john/
:... The asm version checks about 150,000 passwords per second on a 1
:GHz system. Password cracking is much easier on OpenVMS than on other
:systems since passwords are not case sensitive and limited to alphanumeric,
:'$' and '_' only.
Most any password-based mechanism does and will provide poor security
on any platform -- an increase in the size of the character set does
clearly increase the time required for a password match, but if the
nefarious user has a copy of your hashed password or your password
database, you are already in trouble. The match is only a matter of
time, and as the computing cycles available increase, the time to a
matching hash will decreate.
Passwords are case-sensitive and a variety of characters are permitted
as part of external authentication. And you can also implement your
own hashing scheme, if so interested.
The OpenVMS approach is to restrict access to the hashed values as
stored in SYSUAF, and to use a salt value to reduce exposure to attacks
based on the use of pre-generated password tables. Further, OpenVMS
is moving to external authentication, as this permits each site to
provide smartcards or scanners or other technologies, technologies
that are more modern and more secure alternatives to the traditional
text-based password scheme.
If folks here are interested in improving security, consider porting
the John the Ripper "proactive password strength checking module" stuff
or something similar into the LGI callouts. Other approaches involve
enabling and using generated passwords though -- again -- text passwords
are pretty weak as authentication schemes go. (Though the implementation
of an elvish-language password generator was a cute hack.)
Ask The Wizard topics (4612) and (7813) will be of interest here -- the
former is one of the character set discussions, I might add, one of the
previous times that this particular discussion has arisen.
And Jean-loup, the correct DEFINE command is:
"define sysuaf myuaf.dat"
The DEFINE command posted at your webpage is wrong. And no, that isn't
a security hole -- simply knowing usernames is not something that is
secured on OpenVMS nor can it particularly be secure-able.
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com
Hoff Hoffman
In article <as2d1o$2kmi$1...@news2.ipartners.pl>, "Tomasz Dryjanski" <tdryjans...@hotmail.com> writes:
:> of cracking?...
..
:Or you may even change the user's password temporarily.
:Some years ago I wrote a program capable of storing a hashed password,
:and then restoring it back.
If you have general read access or unrestricted write access into
the SYSUAF database, then the system is wide-open and literally
any access and any change is possible -- you are fully privileged.
As for your password-maintaining tool, using the existing RENAME
command available within AUTHORIZE (twice) would seem far easier.
But given write-access to SYSUAF means that IMPERSONATE and other
options are also explicity available to a fully-privileged user,
why bother?
For folks joining this discussion in progress, the OpenVMS security
manual is useful -- and arguably now even required -- reading.
Dale King
> True. However, access to that file would also be restricted in a
> properly locked down system, so it's still of limited use to hackers.
> They'd have to get in and get privs to get the file, and the program
> would be fairly pointless once you'd done that.
The big problem of course is people using the same passwords on many systems.
Once a system is comprised so are the rest. Similarly, a priviliged user on one
system can generally be considered privileged on the rest, where a company
policy enforces consistent usernames accross systems.
Larry Kilgallen
>
> In article <as2d1o$2kmi$1...@news2.ipartners.pl>, "Tomasz Dryjanski" <tdryjans...@hotmail.com> writes:
> :> If you have a system manager as an accomplice, why go to all the trouble
> :> of cracking?...
> ..
> :Or you may even change the user's password temporarily.
> :Some years ago I wrote a program capable of storing a hashed password,
> :and then restoring it back.
> As for your password-maintaining tool, using the existing RENAME
> command available within AUTHORIZE (twice) would seem far easier.
But it provides more precise audits of what the attacker is doing.
Andrew Harrison SUNUK Consultancy
David Mathog wrote:
> On Tue, 26 Nov 2002 23:11:27 +0000 (UTC)
> jl...@gailly.OmitThisWord.net (Jean-loup Gailly) wrote:
>
>
>>I have written a patch for John the Ripper http://www.openwall.com/john/
>>to allow cracking OpenVMS (Vax and Alpha) passwords. The patch is based on
>>code from Shawn Clifford, Davide Casale and Mario Ambrogetti.
>
>
> Which is nice but of little relevance to VMS security. Only a priv'd user
> should be able to read SYSUAF.DAT, and if that user has evil intentions
> then the system is already compromised - there's no need to crack
> the password file. This contrasts with many (most?) Unix systems, where
> everybody can read the encrypted password file.
>
This has been untrue for years for Solaris I cannot comment
on other UNIX's.
/etc/passwd is readable by non root users but doesn't contain
users passwords.
The passwords are held in /etc/shadow and this by default
isn't readable except by root.
ls -la /etc/shadow returns
-r-------- 1 root sys 674 Nov 27 09:55 /etc/shadow
Regards
Andrew Harrison
David Webb
>
>David -
>
>On Wed, 27 Nov 2002 08:27:48 -0800, David Mathog <mat...@caltech.edu>
>wrote:
>
>[...]
>
>>This contrasts with many (most?) Unix systems, where
>>everybody can read the encrypted password file.
>
>That's not anymore true. Most if not all current Unix systems use now
>the shadow file (Solaris, Irix, Linux, OpenBSD, NetBSD, etc...).
>
Most if not all provide a shadow password or similar facility but whether it is
the default I'm not so sure.
Also I doubt whether when upgrading older systems an automatic conversion to
using shadowed passwords is performed.
I've also come across systems using shadowed passwords where for some reason
passwords ended up being setup in the /etc/passwd file and hence posed a risk
until someone noticed.
Jean-loup Gailly
obvious that if a bad guy has access to your sysuaf.dat you're in big
trouble already. I have added a sentence on http://gailly.net/security/ :
"This tool is designed for system administrators to detect users who
too often select very bad passwords, too easily guessable".
I advise system administrators who do not believe this to try
John at least once. You will be amazed to see how bad most passwords are,
and how quickly you can find most of them. Of course, make sure that
the working directory of John and all files within it are correctly
protected against read access by others.
Nic Clews writes:
> Secondly, a password list you hit a single user account with in the most
> part cannot exist in those that are in the password dictionary (where
> implemented!)
I had trouble parsing your sentence. John does much more than trying
all words from a dictionary. It has elaborate rules to generate many
variations of dictionary words, and a sophisticated incremental mode
to try non-dictionary words in optimum order. This is what makes it
the best password cracking tool.
> and for those of us that use the password policy module forcing the
> presence of non alphabetic characters and therefore _really_
> 'unreal' words, you'd have to slow that 150,000 guesses per second down
My patch is designed for the builtin OpenVMS password algorithms, not
for external modules. HP (Hoff Hoffman) indeed recommends using
algorithms other than their own, in this thread and in
http://www.openvms.compaq.com/wizard/wiz_4612.html
> I don't really believe that anyone has the storage or the time to
> pregenerate such a colossal list, moving each character through all
> possible combinations starting at some arbitrary length, and extending
> to the maximum allowable or expected (and risking missing longer
> ones). The sheer time to perform the IO alone to this list makes a
> mockery of the technique.
There is no point in generating a colossal list on disk. The VMS password
algorithms correctly take into account a salt and the user name to prevent
such attacks. But at 150,000 guesses per second it is very easy to try
*all* legal VMS passwords of 7 characters or less, working in memory only.
You can also easily try all simple variations of a small dictionary
(1 million words). John is good at generating the variations that people
actually use most of the time.
By using John, a system administrator can effectively eliminate all weak
passwords. I'm surprised that many VMS fans cannot understand the usefulness
of such a tool. (I wrote the John VMS patch for a security audit of a
large company.)
Jean-loup Gailly
http://gailly.net/security/
marco viola
> The passwords are held in /etc/shadow and this by default
> isn't readable except by root.
> ls -la /etc/shadow returns
> -r-------- 1 root sys 674 Nov 27 09:55 /etc/shadow
Not writable; interesting.
How do you add users?
Ciao
Marco
Nic Clews
However you could set the SYSUAF.DAT as /NOBACKUP and independently
secure the backup copies of SYSUAF. Or fix your tape handling procedure,
however, if it is that bad, you deserve to get all your burgers nicked.
There are far easier methods of breaking into a system that any self
respecting hacker would use, as opposed to anything mentioned in this
thread. Like I said, if anyone is allowing passwords as supplied as a
list with that cracker, mine is with lots of ketchup and onions please.
David J. Dachtera
The hard part is reconciling that to human nature.
What's a big complaint of the security people? SAME passwords on many
systems.
What's the big complauin of users? DIFFERENT passwords on many systems.
Nearly diametric opposition.
--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
David J. Dachtera
root effectively has the equivalent of BYPASS privilege. The permission
mask is more or less meaningless in such circumstance.
Georges A. Tomazi
Hi -
On Thu, 28 Nov 2002 14:22:05 +0100, marco viola <m...@mail.com> wrote:
[...]
>> ls -la /etc/shadow returns
>> -r-------- 1 root sys 674 Nov 27 09:55 /etc/shadow
>
>Not writable; interesting.
>
>How do you add users?
That's normal on Solaris. The system bypass that.
JF Mezei
> By using John, a system administrator can effectively eliminate all weak
> passwords. I'm surprised that many VMS fans cannot understand the usefulness
> of such a tool. (I wrote the John VMS patch for a security audit of a
> large company.)
Suppose you do find that your boss has a weak password. What do you do then ?
Do you go and tell him that you extracted his password and decided that it was
weak ? Wouldn't that jeoperdize the integrity of the system manager who is not
supposed to have access to user's passwords ?
He may have access to his own sysuaf.dat on that small departmental VAX, but
getting his boss's password on the vax would probably also get his password
for the IBM mainframe and email servers etc etc etc. Revealing that you can in
fact extract passowrds would jeoperdize the security of other systems in the organisation.
One would have to be very diplomatic in trying to educate the person on the
use of stronger passowrds without giving any hints that you saw their password.
Jean-François PIÉRONNE
First I would like not to argument pro/cons security based on password, only
about password guessable.
First, you agree that on a normally configure VMS system you can't read the UAF
file.
Very bad passwords is much less a problem on VMS than on many others systems,
because there is other security
which prevent you to do many try:
for example if you have a direct access, then you terminal will become suspect,
then intruder,then if I have enablethis feature the account will become disuser,
and not including dome audit alarm.
Why did you think that credit card have only a four digits code, because after
three attempts the game is over.
So what is the chance of a, for example, 6 letters passwords, to be be found if
you have only five attempt?
On some other systems, you can made as many attempt as you want, this is
fundamental different.
I don't say it is impossible, just that the probability is very very small.
The thread http://www.openvms.compaq.com/wizard/wiz_4612.html is much more about
general password security versus other methods (Kerberos, smart cards, and
biometric hardware, etc...) and not about some problem into the implementation
of the password mechanism into VMS.
I have only seen in movies people finding password after 3 attempts.
Any way, a good password is better than a bad, but a too good password is
sometime written on some paper because people can't remember it :-)
On most of VMS system I have seen, there are much important security problem.
Jean-François
Andrew Harrison SUNUK Consultancy
JF Mezei wrote:
> Jean-loup Gailly wrote:
>
>>By using John, a system administrator can effectively eliminate all weak
>>passwords. I'm surprised that many VMS fans cannot understand the usefulness
>>of such a tool. (I wrote the John VMS patch for a security audit of a
>>large company.)
>
>
>
> Suppose you do find that your boss has a weak password. What do you do then ?
> Do you go and tell him that you extracted his password and decided that it was
> weak ? Wouldn't that jeoperdize the integrity of the system manager who is not
> supposed to have access to user's passwords ?
>
You tell him, but in private so as not to make him/her look
idiotic in public.
Most major organsations have standards that they expect their
employees to follow when setting their passwords, if your
bosses password is crackable then it probably doesn't follow
your security standards.
If you don't tell him and someone breas into his account you
will be worse off then not telling him in the the first
place.
We run crack internally in Sun, written by Alex Muffett.
If you have a poorly constructed password then you get a
warning email from the security team. It doesn't distinguish
between job titles and doesn't have a CEO userid filter.
This discussion is a re-run of discussions about crack, COP's
etc.
Have a look at (kindly forwarded to me by Alex)
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=0gcHpabz1%40cs.psu.edu
The thread that follows and the views expressed there are
is pretty much reflected by the views expressed in this thread.
You will however note that the origional discussion was 11 years
ago. (Was the Apollo DN10000 arround 11 years ago, it seems longer).
Regards
Andrew Harrison
David Webb
>Jean-loup Gailly wrote:
>> By using John, a system administrator can effectively eliminate all weak
>> passwords. I'm surprised that many VMS fans cannot understand the usefulness
>> of such a tool. (I wrote the John VMS patch for a security audit of a
>> large company.)
>
the system itself (from a suitably privileged and secured account).
The idea of copying the sysuaf onto a PC to do the analysis circumvents all
the VMS mechanisms designed to protect this important file.
I seem to recall that there were some public domain native programs (from
before VMS had password dictionaries etc ie quite some time ago) which
did this. I haven't looked at them in years and hence have no idea whether
they still work.
Problems with weak passwords can be reduced by using VMS mechanisms ie
minimum password length,
password history list - to prevent reuse of passwords,
password dictionary,
inbuilt triviality checks - to stop users choosing trivial passwords such as
the account name
Together with setting appropriate LGI values so that the system takes evasive
action after the user gets the password wrong a certain number of times
ie for a certain period even if the hacker got the password correct they
would not be allowed to login - this drastically reduces the chance of a
successful brute force attack.
Increasing the characterset from which VMS passwords can be chosen probably
wouldn't really increase VMS security when these mechanisms are properly
deployed. However it would increase usability when users (as they will)
use the same password on multiple systems - this of course reduces security
to that of the least secure system.
Many companies have policies on what makes a strong password - in such an
environment either VMS is left out or the company policy is reduced to the
characterset allowed in VMS which may be entirely inappropriate for some
other less protected systems.
David Webb
VMS and Unix team leader
CCSS
Middlesex University
>
Bill Gunshannon
I used to regularly run password cracking programs against the master
password files in the department usually then informing the the user
that their password was easily determinable (often telling them what
it was, including their little tricks like "h311o" for "hello"). I
stopped doing it when common Unix eliminated the ability of the none
priveledged user to actually read the encrypted passwords and because
I never found a user who cared. They usually just changed their pass-
word to something else just as easily determined.
As to the idea that the number of possible combinations prevents this
kind of attack, while that was true when I first ran "crack" (it took
a week and broke only one or two passwords) now days, I can do the whole
password file overnight and frequently break all the passwords that are
not pure random strings of characters (which is what I issue for initial
passwords.) Remember also, on most systems there really is only one
password you need to break to compromise the system. Now imagine a lab
full of 2GHZ P3's spending the 4 day Thanksgiving weekend running a
distributed password cracking program against the SYSTEM password. Even
A totally random string is not a guarantee.
All the best.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Bill Gunshannon
David Mathog <mat...@caltech.edu> writes:
>
> Which is nice but of little relevance to VMS security. Only a priv'd user
> should be able to read SYSUAF.DAT, and if that user has evil intentions
> then the system is already compromised - there's no need to crack
> the password file. This contrasts with many (most?) Unix systems, where
> everybody can read the encrypted password file.
Once again, we compare current VMS to 20 year old Unix. I know of no
"current" version of Unix (or Linux for that matter) that allows non-
priveledged access to the encrypted passwords without the explicit
allowance of that by the Administrator. And shadow passwords have been
available as a graft on addition as far back as SunOS4. I expect I will
even put that high on the list of improvements I am making to Ultrix-11
even though I doubt anyone using it will really care. :-)
Michael Austin
>
> Shane Smith wrote:
> >
> > True. However, access to that file would also be restricted in a
> > properly locked down system, so it's still of limited use to hackers.
> > They'd have to get in and get privs to get the file, and the program
> > would be fairly pointless once you'd done that.
>
> sysuaf.dat, you crack the boss's password and can then have "fun" on the
> system, undetected and without any intrusion attempts.
>
> This is why it is very important to have full trust in anyone with privileges
> in your system.
If you have said accomplice, it is even easier using something like
SETUSER. or other similar methods.
--
Regards,
Michael Austin OpenVMS User since June 1984
First DBA Source, Inc. Registered Linux User #261163
Sr. Consultant http://www.firstdbasource.com
John E. Malmberg
> In article , Kilg...@SpamCop.net (Larry Kilgallen) wrote:
>
>> 4. The vulnerability to such a tool is when people have access to
>> unencrypted backup tapes. At some shops that is easier to achieve
>> than privileged access to the running system.
>
> Good point.
There are legitimate uses for such tools for security audits. They are
used to discover if users are using weak passwords such as setting the
system password to "XYZZY" or other obvious ones.
IIRC: There is at least one third party security audit tool that
performs this type of check.
If I have physical privileged access to a system, or the actual backup
tapes, I do not need the SYSUAF passwords to access the data.
-John
wb8...@qsl.network
Personal Opinion Only
JF Mezei
> If I have physical privileged access to a system, or the actual backup
> tapes, I do not need the SYSUAF passwords to access the data.
There may be occasions where you really want/need to have the password, and
login from a real terminal and start an application from that terminal under
that username so that all log entries are "kosher" when they start to
investigate why one hundred million dollars were transfered out of that bank...
Nic Clews
>
(Excellent points snipped)
....
>
> Increasing the characterset from which VMS passwords can be chosen probably
> wouldn't really increase VMS security when these mechanisms are properly
> deployed. However it would increase usability when users (as they will)
> use the same password on multiple systems - this of course reduces security
> to that of the least secure system.
This gets into the realms of self defeating security. If you did
increase the allowable range of characters, make them case sensitive,
etc., you stand a far higher risk of defeating the human capability to
commit usefully to memory a password, where it becomes necessary for
systems not protected with cryptography to store the password. Post-it
notes under desks are one method that I've observed.
Another I detected from observed system activity is account sharing.
Despite having own accounts, people shared, because they could not be
bothered going to helpdesk, getting their forgotten password reset after
identity verification, then stand a large chance of forgetting it again
to repeat the whole process. There were other things I saw that didn't
specifically involve weak passwords, but nonetheless provided an
opportunity for improper access.
David Webb
>David Webb wrote:
>>
>(Excellent points snipped)
>>
>> Increasing the characterset from which VMS passwords can be chosen probably
>> wouldn't really increase VMS security when these mechanisms are properly
>> deployed. However it would increase usability when users (as they will)
>> use the same password on multiple systems - this of course reduces security
>> to that of the least secure system.
>
>This gets into the realms of self defeating security. If you did
>increase the allowable range of characters, make them case sensitive,
>etc., you stand a far higher risk of defeating the human capability to
>commit usefully to memory a password, where it becomes necessary for
>systems not protected with cryptography to store the password. Post-it
>notes under desks are one method that I've observed.
>
they will set the password to be the same as for their VMS account.
The restricted set of characters allowed for VMS passwords then make their
Unix passwords too weak. A hacker who then cracks their unix password then
gets their VMS password.
Most sites will therefore set up a password policy on their unix systems
- eg every password must contain an uppercase letter, a lowercase letter a
number and a punctuation character. Such a policy will also be applied to their
windows systems. VMS will then appear to be out of step and may even be
portrayed as being insecure since "it's passwords are too weak".
Note.
Whether having such a password policy in place is actually any good or whether
as you note it just results in people writing down passwords is irrelevent
since all the security manuals say that such a policy is needed for the Unix
systems they are using.
>Another I detected from observed system activity is account sharing.
>Despite having own accounts, people shared, because they could not be
>bothered going to helpdesk, getting their forgotten password reset after
>identity verification, then stand a large chance of forgetting it again
>to repeat the whole process. There were other things I saw that didn't
>specifically involve weak passwords, but nonetheless provided an
>opportunity for improper access.
>
This is a fact of life. It doesn't matter how often you tell them not to or how
simple their passwords are they will still share accounts, write down passwords
etc if doing so makes their life just a little bit easier and they don't think
someone will find out and punish them. This is a management not a technical
issue.
Main, Kerry
Yep, has always been a problem i.e.. no matter what you do, human nature
will dictate that users will try and keep their passwords the same. In
addition, when a user leaves how do you ensure all of their accounts are
disabled on all systems? How do you know when the last time that user
logged into each of the systems they are authorized for without going
around to every system and using OS specific means to look at accounting
records?
Now, you can try to enforce different passwords, but this is like try to
stop the oldest profession in the world (red light stuff).
Another approach that I know many large shops are looking at involves
LDAP based security using a distributed directory. Hence, companies have
the capability to have a distributed directory (each system has sub-set
of that directory that is specific to them local to their system) while
at the same time centralizing security policy.
In this way, disabling a user at one location has the effect of
disabling access on all systems on all platforms. Auditing can be done
from central location.
Does it take planning ? You bet.
Can it be expensive? You bet - especially if the directory is an
additional cost per user.
What about the concern for additional security - given resent security
break-ins, hacker attacks and virus's for many platforms???
Hey, use a very secure OS as the basis for that directory.
Oh, by the way, the enterprise directory is included as part of OpenVMS
with no additional cost.
Reference:
http://www.openvms.compaq.com/commercial/eDir/edir_home.html
:-)
Regards,
Kerry Main
Senior Consultant
Hewlett-Packard (Canada) Co.
Consulting & Integration Services
Voice: 613-592-4660
Fax : 613-591-4477
Email: kerryDOTmain@hpDOTcom
(remove the DOT's and replace with "."'s)
Larry Kilgallen
> Robert Deininger wrote:
>
>> In article , Kilg...@SpamCop.net (Larry Kilgallen) wrote:
>>
>>> 4. The vulnerability to such a tool is when people have access to
>>> unencrypted backup tapes. At some shops that is easier to achieve
>>> than privileged access to the running system.
>>
>> Good point.
>
> There are legitimate uses for such tools for security audits. They are
> used to discover if users are using weak passwords such as setting the
> system password to "XYZZY" or other obvious ones.
>
> IIRC: There is at least one third party security audit tool that
> performs this type of check.
The LJK/Security approach is to tell the privileged person
how many guesses it took, but not tell them the password.
> If I have physical privileged access to a system, or the actual backup
> tapes, I do not need the SYSUAF passwords to access the data.
But for some scenarios reading the data is less of a vulnerability than
modifying it. In that case, lower physical security on the backup tapes
than the running system is still not appropriate, for reasons discussed
in this thread.
Larry Kilgallen
> Oh, by the way, the enterprise directory is included as part of OpenVMS
> with no additional cost.=20
Only on Alpha. You still have to pay extra on VAX.
Jan C. Vorbrüggen
> with no additional cost.
And Microsoft has apparently decided to re-write, from scratch, Active
Directory (its take on LDAP) because their current design has unfixable
security holes...
Jan
bri...@encompasserve.org
>> By using John, a system administrator can effectively eliminate all weak
>> passwords. I'm surprised that many VMS fans cannot understand the usefulness
>> of such a tool. (I wrote the John VMS patch for a security audit of a
>> large company.)
>
>
> Suppose you do find that your boss has a weak password. What do you do then ?
> Do you go and tell him that you extracted his password and decided that it was
> weak ? Wouldn't that jeoperdize the integrity of the system manager who is not
> supposed to have access to user's passwords ?
>
> He may have access to his own sysuaf.dat on that small departmental VAX, but
> getting his boss's password on the vax would probably also get his password
> for the IBM mainframe and email servers etc etc etc. Revealing that you can in
> fact extract passowrds would jeoperdize the security of other systems in the organisation.
Revealing that you can extract passwords would reveal the fact that
the security of those other systems was already in jeopardy.
Yes, it's no fun to be the bearer of bad news. But don't delude yourself
that you are improving security by staying silent.
> One would have to be very diplomatic in trying to educate the person on the
> use of stronger passowrds without giving any hints that you saw their password.
If you know the boss's password, keep quiet about it and are found out,
that could look bad. Tell him. Tell him flat out and without evasion.
Dancing around the truth won't make it go away.
And try to exercise due care with your list of cracked passwords.
John Briggs
Shane Smith
faster than the 2ghz P4's that Intel does produce.</nitpick mode>
It's not the speed of the machines generating the test passwords, it's
how fast the target machine will let them try and how many failures it
allows before locking off the account. If they've compromised the
machine enough to copy the sysuaf, they don't need to crack the
password. They're in already.
The only way I know of to start users caring about the guessability of
their passwords is to inconvenience them if they don't pick a good one.
When they get their account, make it clear that any guessable passwords
will be arbitrarily changed, and they'll have to come to you to find out
what it changed to. It's tough on you to start with, but they will
learn.
Shane
-----Original Message-----
From: bi...@cs.uofs.edu [mailto:bi...@cs.uofs.edu]
Sent: Friday, November 29, 2002 7:24 AM
To: Info...@Mvb.Saic.Com
Subject: Re: Cracking OpenVMS passwords with John the Ripper
In article <3DE667B9...@vl.videotron.ca>,
JF Mezei <jfmezei...@vl.videotron.ca> writes:
> Jean-loup Gailly wrote:
>> By using John, a system administrator can effectively eliminate all weak
>> passwords. I'm surprised that many VMS fans cannot understand the
usefulness
>> of such a tool. (I wrote the John VMS patch for a security audit of a
>> large company.)
>
>
> Suppose you do find that your boss has a weak password. What do you do then
?
> Do you go and tell him that you extracted his password and decided that it
was
> weak ? Wouldn't that jeoperdize the integrity of the system manager who is
not
> supposed to have access to user's passwords ?
>
> He may have access to his own sysuaf.dat on that small departmental VAX, but
> getting his boss's password on the vax would probably also get his password
> for the IBM mainframe and email servers etc etc etc. Revealing that you can
in
> fact extract passowrds would jeoperdize the security of other systems in the
organisation.
>
> One would have to be very diplomatic in trying to educate the person on the
> use of stronger passowrds without giving any hints that you saw their
password.
I used to regularly run password cracking programs against the master
password files in the department usually then informing the the user
that their password was easily determinable (often telling them what
it was, including their little tricks like "h311o" for "hello"). I
stopped doing it when common Unix eliminated the ability of the none
priveledged user to actually read the encrypted passwords and because
I never found a user who cared. They usually just changed their pass-
word to something else just as easily determined.
As to the idea that the number of possible combinations prevents this
kind of attack, while that was true when I first ran "crack" (it took
a week and broke only one or two passwords) now days, I can do the whole
password file overnight and frequently break all the passwords that are
not pure random strings of characters (which is what I issue for initial
passwords.) Remember also, on most systems there really is only one
password you need to break to compromise the system. Now imagine a lab
full of 2GHZ P3's spending the 4 day Thanksgiving weekend running a
distributed password cracking program against the SYSTEM password. Even
A totally random string is not a guarantee.
All the best.
bill