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