Protecting access to Passwords from hackers

[Warren M. Littlefield]

Hello,
Some hacker at my school was able to break into the list of all the
passwords on our Novell network. Apparently there is a way to do this. What
I'd like to know is, is there a way to prevent a hacker from doing this? How
can you make passwords more secure?

Thanks,
Warren Littlefield
sccc...@usa.net

[Kevin Vigor]

: Hello,

: Some hacker at my school was able to break into the list of all the
: passwords on our Novell network. Apparently there is a way to do this. What
: I'd like to know is, is there a way to prevent a hacker from doing this? How
: can you make passwords more secure?

There is no such list on the server (unless some system
administrator type person created it, in which case you deserve what you
got). All Netware stores is a hashed version of the password, from which
the original cannot be re-created. As Novell keeps the hash algorithm
very secret, the only way I am aware of to attack Novell security based
on the hashed numbers (which you can get from the bindery; I'm not sure
what rights are required) is to construct a dictionary of hashed common
passwords using the Novell login program and a packet sniffer to see the
hashed value (i.e. attempt to login with password AARDVARK and note the
hashed value; then if this hashed value appears in the bindery, you know
you can use AARDVARK as a password).

Since Novell imposes a wait of three seconds on any bogus login
attempt, it will take a very long time to build up a reasonable
dictionary of hash values (this could be done much more quickly if the
hash algorithm was known; presumably, one could disassemble NETX and
figure it out, though I have not tried this and do not know if Novell
has made any efforts to encrypt or obfuscate the code).

Thus, the list of hash values on the server does not represent a
reasonable security risk, though if you want to protect against a
dictionary attack, you could ensure that passwords are not English
words.

--
Kevin

[Louis The Duck]

In article <1994Aug18.1...@wicat.com>,

Kevin Vigor <ke...@elvis.wicat.com> wrote:
>: Hello,
>: Some hacker at my school was able to break into the list of all the
>: passwords on our Novell network. Apparently there is a way to do this. What
>: I'd like to know is, is there a way to prevent a hacker from doing this? How
>: can you make passwords more secure?
>

> Since Novell imposes a wait of three seconds on any bogus login
>attempt, it will take a very long time to build up a reasonable
>dictionary of hash values (this could be done much more quickly if the
>hash algorithm was known; presumably, one could disassemble NETX and
>figure it out, though I have not tried this and do not know if Novell
>has made any efforts to encrypt or obfuscate the code).
>
> Thus, the list of hash values on the server does not represent a
>reasonable security risk, though if you want to protect against a
>dictionary attack, you could ensure that passwords are not English
>words.
>
>--
> Kevin

While Novell has done a good job of securing passwords by encryption,
there is still one major hole in the system. When the password is typed
into login.exe, it remains in the keyboard buffer. If anyone has the
supervisor password, he can add a line to the system login script which
copies the keyboard buffer's contents to the server. Wait a few days,
and you have everyone's password. A few hackers at my school did that
and got over 100 passwords. This seems like a pretty big security hole
since as I see it, the idea is that if you have the Supervisor password,
you can *change* others' passwords but it is supposedly impossible to
ever find out what they actually are. That is certainly one of the
easiest ways I can think of to collect large numbers of passwords.
Packet sniffers can do it too, and it's certainly possible that one of
those was used (depending on which version of netware he is running &
which patches are installed). There isn't, to the best of my knowledge,
any way around the problem of the keyboard-buffer grabber other than
carefully checking the system login scripts and the user login scripts
(and of course securing the supervisor password!)

--
------------------------------------------------------------------------------
I hate signatures.

[Fritz Golman]

Of course, you could do the old "Trojan Horse" type of program
and write your own LOGIN.EXE (which, of course, could really log
you in except that it writes out your ID and password to a
file...)

--
Fritz Golman

[Thomas Brugger]

In article <1994Aug18.1...@wicat.com>,
Kevin Vigor <ke...@elvis.wicat.com> wrote:

>: Hello,
>: Some hacker at my school was able to break into the list of all the
>: passwords on our Novell network. Apparently there is a way to do this. What
>: I'd like to know is, is there a way to prevent a hacker from doing this? How

No, you cannot prevent this.

>: can you make passwords more secure?
>
> There is no such list on the server (unless some system
>administrator type person created it, in which case you deserve what you
>got). All Netware stores is a hashed version of the password, from which
>the original cannot be re-created. As Novell keeps the hash algorithm

Correct, the server knowns only the hashed value.

>very secret, the only way I am aware of to attack Novell security based

Object files with the encryption algorithm have been released.

>on the hashed numbers (which you can get from the bindery; I'm not sure
>what rights are required) is to construct a dictionary of hashed common

Backup the bindery. Supervisor rights or console access are required.

>passwords using the Novell login program and a packet sniffer to see the
>hashed value (i.e. attempt to login with password AARDVARK and note the

No, the hashed value is encrypted with a random number generated
by the server. NW 4.x authentication is more secure (allegedly)
and more secret.

[Gary Penrod]

Warren M. Littlefield (sccc...@usa.net) wrote:
: Hello,

: Some hacker at my school was able to break into the list of all the
: passwords on our Novell network. Apparently there is a way to do this. What
: I'd like to know is, is there a way to prevent a hacker from doing this? How
: can you make passwords more secure?

:

Let me put in my 2 cents worth here. I think that one of the better ways to
keep a hacker from entering the system (someone correct me if I'm wrong pls)
is to restrict all superuser and supervisor logins to specific nodes. It
plays hell on trying to work remotely on someone elses terminal, but if I'm
thinking correctly, the hacker should not be able to crack the password except
from the stations that they are restricted to.

I would like to entertain others opinions on this, cause I'm not an expert of
Novell administration. Would this help prevent hackers?

Gary

[Carl Fink]

gpe...@oodis01.af.mil (Gary Penrod) wrote:
[deletia]

>
> Let me put in my 2 cents worth here. I think that one of the better ways to
> keep a hacker from entering the system (someone correct me if I'm wrong pls)
> is to restrict all superuser and supervisor logins to specific nodes. It
> plays hell on trying to work remotely on someone elses terminal, but if I'm
> thinking correctly, the hacker should not be able to crack the password except
> from the stations that they are restricted to.
>
> I would like to entertain others opinions on this, cause I'm not an expert of
> Novell administration. Would this help prevent hackers?
>

I'm far from an expert, but wouldn't that still leave you
vulnerable to anyone with an Ethernet connection who can decode
packets? My site has IBM ethernet cards, whose diagnostic software
lets you see the packets fly by. With a little hacking, you could
rig a program to analyze each packet looking for the word
"supervisor" and then decode the next ones from that address,
discovering the password.
--
Pray, v.: to ask that the laws of the universe be annulled in
behalf of a single petitioner confessedly unworthy.
--"The Devil's Dictionary" by Ambrose Bierce
Carl Fink ca...@panix.com CARL.FINK (GEnie)

[Charles Cooley]

In article <333k2s$e...@access2.digex.net>,

Louis The Duck <ltd...@access.digex.net> wrote:
>
>While Novell has done a good job of securing passwords by encryption,
>there is still one major hole in the system. When the password is typed
>into login.exe, it remains in the keyboard buffer. If anyone has the
>supervisor password, he can add a line to the system login script which

^^^^^^^^^^^^^^^^^^^

>copies the keyboard buffer's contents to the server. Wait a few days,
>and you have everyone's password. A few hackers at my school did that

>and got over 100 passwords. ^^^^^^^^^^^

The most significant security hole is that your hackers had the supervisor
password.

> This seems like a pretty big security hole
>since as I see it, the idea is that if you have the Supervisor password,
>you can *change* others' passwords but it is supposedly impossible to
>ever find out what they actually are. That is certainly one of the
>easiest ways I can think of to collect large numbers of passwords.

Easiest? Probably. But you need access to the login scripts, which means
you have already broken the system security. Another response points out
that it would be almost as easy to plant a fake login program.

A real supervisor would have no need to "steal" user passwords, and since
there are ways besides modifying the login script to do so, I don't see
the problem. There is still no legitimate way for a supervisor to read
user passwords.

>Packet sniffers can do it too, and it's certainly possible that one of
>those was used (depending on which version of netware he is running &
>which patches are installed).

Packet sniffers would grab the encrypted password, not the original.

> There isn't, to the best of my knowledge,
>any way around the problem of the keyboard-buffer grabber other than
>carefully checking the system login scripts and the user login scripts

Don't forget to make sure no one has replaced the login program or is
running TSRs.

>(and of course securing the supervisor password!)

********************************

Charles Cooley

[mark.t...@infoboard.be]

> I'm far from an expert, but wouldn't that still leave you
> vulnerable to anyone with an Ethernet connection who can decode
> packets? My site has IBM ethernet cards, whose diagnostic software
> lets you see the packets fly by. With a little hacking, you could
> rig a program to analyze each packet looking for the word
> "supervisor" and then decode the next ones from that address,
> discovering the password.

yes if you are not using NCP Packet Signature. If you use this, packets are
encoded before being send over the network.

Mark

[Brett Frankenberger]

ke...@elvis.wicat.com (Kevin Vigor) writes:

>: Hello,
>: Some hacker at my school was able to break into the list of all the
>: passwords on our Novell network. Apparently there is a way to do this. What
>: I'd like to know is, is there a way to prevent a hacker from doing this? How
>: can you make passwords more secure?
>
> There is no such list on the server (unless some system
>administrator type person created it, in which case you deserve what you
>got). All Netware stores is a hashed version of the password, from which
>the original cannot be re-created. As Novell keeps the hash algorithm
>very secret, the only way I am aware of to attack Novell security based
>on the hashed numbers (which you can get from the bindery; I'm not sure
>what rights are required) is to construct a dictionary of hashed common
>passwords using the Novell login program and a packet sniffer to see the
>hashed value (i.e. attempt to login with password AARDVARK and note the
>hashed value; then if this hashed value appears in the bindery, you know
>you can use AARDVARK as a password).

I don't believe the hash algorithm is very secret ... in fact, a
program (in source code) to hash (encrypt) a password was posted here
earlier this year.

The security of the hash algorithm does not depend on its obscurity ...
Novell could send the source-code out with every release of Netware,
and it would still be impossible (as far as we know) to obtain a
plaintext password from the hashed password. Note that to hack into a
file server, though, all you need is the hashed password. (If you want
to use LOGIN.EXE, you need the plaintext password ... but if you want
to write your own login code, all you need is the hashed password.)

Also, each password is hashed with a key that is obtained in the
Bindery, but which is randomly selected for each user. It's at least
two bytes, I think, so you'd need to hash every trial password with a
bunch of different key values.

> Since Novell imposes a wait of three seconds on any bogus login
>attempt, it will take a very long time to build up a reasonable
>dictionary of hash values (this could be done much more quickly if the
>hash algorithm was known; presumably, one could disassemble NETX and
>figure it out, though I have not tried this and do not know if Novell
>has made any efforts to encrypt or obfuscate the code).

Although the three-second wait is beatable if you want to wrtie your
own client code ... you can create 200 connections to a server from one
workstation and be trying 200 passwords at once ... (Yes, I know NETX
only allows 8 connections ... that's a limitation of netx ... if you're
writing your own code, you can do whatever you want.)

> Thus, the list of hash values on the server does not represent a
>reasonable security risk, though if you want to protect against a
>dictionary attack, you could ensure that passwords are not English
>words.
--

- Brett (bre...@netcom.com)

------------------------------------------------------------------------------
... Coming soon to a | Brett Frankenberger
.sig near you ... a Humorous Quote ... | bre...@netcom.com

[Brett Frankenberger]

mark.t...@infoboard.be writes:

Passwords are encrypted before being sent over the wire. You can't
packet-capture a login and use the information you acquire to hack in.
(You *can* packet-capture a password-change and use the information
obtained there to hack in.)

Packet Siguature works to prevent the NCP Packet Forgery hack. That's
it. It does no encryption of actual data. Anything you can packet
capture without packet signature, you can capture with packet
signature. It just makes it impossible to send bogus packets that
claim to come from a workstation that they did, in fact, not come from.
(To break Packet Signature, you would need to packet-capture the most
recent time the target changed his password, and his entire corrent
session from the time he established a connection to the server.)

[Jim Henderson]

I missed the original message in this thread, but thought I'd add my $0.02
worth...

With NetWare 4, passwords are never sent over the wire - the password is used
to generate a unique authentication key specific to the workstation and the
server that are interacting. This authentication key is good for one time
only.

Issuing a SETPASS or other change of password on a 4.x server also uses an
authentication key. With NetWare 4, the password is never sent over the wire
in either plaintext or encrypted form.

Jim
--
Jim Henderson - W0/KD4LDO Internet: ji...@kd4ldo.ampr.org
NetWire Forum SysOp (NETW4X) CompuServe: 76702,1452

#include <disclaimer.h>

[Terje Mathisen]

In <334rb0$s...@sun0.urz.uni-heidelberg.de>, f...@aixterm2.urz.uni-heidelberg.de (Thomas Brugger) writes:
>In article <1994Aug18.1...@wicat.com>,
>Kevin Vigor <ke...@elvis.wicat.com> wrote:
>>: Hello,
>>: Some hacker at my school was able to break into the list of all the
>>: passwords on our Novell network. Apparently there is a way to do this. What
>>: I'd like to know is, is there a way to prevent a hacker from doing this? How
>
>No, you cannot prevent this.
>
>>: can you make passwords more secure?
>>
>> There is no such list on the server (unless some system
>>administrator type person created it, in which case you deserve what you
>>got). All Netware stores is a hashed version of the password, from which
>>the original cannot be re-created. As Novell keeps the hash algorithm
>
>Correct, the server knowns only the hashed value.
>
>>very secret, the only way I am aware of to attack Novell security based
>
>Object files with the encryption algorithm have been released.

I once spent three days reverse engineering this stuff, the resulting source
have been released on Bix, as well as the net. (Don't ask me where!)

The important stuff to note though, is that the passwords are both hashed,
with a truly one-way function (one-way because of loss of information),
and encrypted using a one-time challenge. The encryption algorithm is
not symmetrical, so you need separate code in the server to decode it.

The decryption code of SERVER.EXE could be reverse engineered as well,
this would enable you to capture encrypted passwords on the wire, and
generate the hashed version that is stored on the server. With a custom
login function, this would allow you to break in to Bindery-mode servers.

-Terje

[ted roberts]

I most certainly am not an expert either, but is it not possible to
"fake" a node address with a node parameter in the net.cfg? If so, this
would seem like an easy way around that security measure.

Ted

[Tony Walker]

In article <SeYLkWUd...@panix.com> ca...@panix.com (Carl Fink) writes:
>Path: usenet.ucs.indiana.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!panix!not-for-mail
>From: ca...@panix.com (Carl Fink)
>Newsgroups: comp.sys.novell
>Subject: Re: Protecting access to Passwords from hackers
>Date: 20 Aug 1994 12:06:19 -0400
>Organization: What, are you kidding?
>Lines: 25
>Message-ID: <SeYLkWUd...@panix.com>
>References: <scccacwl....@usa.net> <73...@oodis01.af.mil>
>NNTP-Posting-Host: panix.com

Sure, one could steal the password. Station restrictions prevent a login from
a predetermined computer and/or subnet. So, if the hacker logs in from
outside your subnet, the password will do them little good.

You could limit your logins to all subnets you work from. Then limit yourself
to one login and normal hours. This still is not perfect, but will help a
little. If your password is stolen, the hacker would need to login from a few
subnets. If the hacker were able to do that, he or she could not login while
you are connected -- you would usually be on all day any way. After you
leave, the time restrictions you have set up would prevent logins. This still
is not perfect, but it makes it harder.

Note: PPP makes it hard to use station restrictions if you want to
administrate your server remotely.

III
UU I UU
U I U Tony Walker
U I U Indiana University
UUIUU tonl...@indiana.edu
I
III

[Keith L. Breinholt]

In article <tonlwalk.1...@indiana.edu> tonl...@indiana.edu (Tony Walker) writes:
>> I'm far from an expert, but wouldn't that still leave you
>>vulnerable to anyone with an Ethernet connection who can decode
>>packets? My site has IBM ethernet cards, whose diagnostic software
>>lets you see the packets fly by. With a little hacking, you could
>>rig a program to analyze each packet looking for the word
>>"supervisor" and then decode the next ones from that address,
>>discovering the password.

Unless you have an older version of NetWare this is not likely. Each time a
password is exchanged with a server the server sends the workstation a random
password key, that key is then used to encrypt the password before sending it
back to the server. It is no likely that you will be able to decrypt the
password and reuse it and sending the same encrypted password will fail also.

>Sure, one could steal the password.

Not very likely, unless you captured both the key and the login request and
know the encryption and decryption algorithms.

Keith L. Breinholt
___________________________________________________________________________
kbre...@novell.com

"If you're not part of the solution, you're part of the probelm."
"I speak only for me...and then only occasionally."
___________________________________________________________________________

[Kevin W. Kingdon]

In article <kbreinho.3...@novell.com> kbre...@novell.com (Keith L. Breinholt) writes:
>From: kbre...@novell.com (Keith L. Breinholt)

>Subject: Re: Protecting access to Passwords from hackers

>Date: Tue, 30 Aug 1994 17:16:08 GMT

>In article <tonlwalk.1...@indiana.edu> tonl...@indiana.edu (Tony Walker) writes:
>>> I'm far from an expert, but wouldn't that still leave you
>>>vulnerable to anyone with an Ethernet connection who can decode
>>>packets? My site has IBM ethernet cards, whose diagnostic software
>>>lets you see the packets fly by. With a little hacking, you could
>>>rig a program to analyze each packet looking for the word
>>>"supervisor" and then decode the next ones from that address,
>>>discovering the password.

>Unless you have an older version of NetWare this is not likely. Each time a
>password is exchanged with a server the server sends the workstation a random
>password key, that key is then used to encrypt the password before sending it
>back to the server. It is no likely that you will be able to decrypt the
>password and reuse it and sending the same encrypted password will fail also.

Actually, the server sends a _challenge_ -- a random number -- to the client.
The client computes a (non-invertable) hash of the password and the challenge
and returns the result to the server.

>>Sure, one could steal the password.

>Not very likely, unless you captured both the key and the login request and
>know the encryption and decryption algorithms.

In fact, knowing the "key" and the response do not allow one to directly
obtain the password.

-------------
Kevin Kingdon
kkin...@novell.com

[Steve Kneizys]

Keith L. Breinholt (kbre...@novell.com) wrote:

Some sites, like ours, have VAXes and Unix boxes connected, and we feel a
little naked without the encryption/decryption algorithms on our other
packets. Would it not be easy for drivers to be written that would encrypt
and decrypt packets on the fly? Performance, performance, I know...but with
CPU bandwith so very high these days (my 8 servers are **rarely** utilized over
10% even under heavy load), and giving the net manager a choice at the
workstation end, a software solution would certainly be *much* cheaper
than upgrading an entire business or college campus over to packet
switching or scrambling.

Just a thought :)

Steve...

[Patrick Klos]

In article <kbreinho.3...@novell.com>,

Keith L. Breinholt <kbre...@novell.com> wrote:
>In article <tonlwalk.1...@indiana.edu> tonl...@indiana.edu (Tony Walker) writes:
>>Sure, one could steal the password.
>
>Not very likely, unless you captured both the key and the login request and
>know the encryption and decryption algorithms.

Technically, there is no "decryption" algorithm for the password hash. The
password is simply encrypted on both ends. When the server receives the
response from the client, it compares the results. If they match, the
client (more than likely) had the correct password.

>Keith L. Breinholt
>___________________________________________________________________________
>kbre...@novell.com

--
============================================================================
Patrick Klos Internet: kl...@mv.mv.com
Klos Technologies, Inc. Voice: (603) 424-8300
604 Daniel Webster Highway FAX: (603) 424-9300
Merrimack, New Hampshire 03054 BBS: (603) 429-0032
============================================================================

[. .]

In article <339qt0$2j...@vkhdib01.hda.hydro.com>,
Terje Mathisen <ter...@hda.hydro.com> wrote:
[.. stuff deleted ..]

>The important stuff to note though, is that the passwords are both hashed,
>with a truly one-way function (one-way because of loss of information),
>and encrypted using a one-time challenge. The encryption algorithm is
>not symmetrical, so you need separate code in the server to decode it.
>
>The decryption code of SERVER.EXE could be reverse engineered as well,
>this would enable you to capture encrypted passwords on the wire, and
>generate the hashed version that is stored on the server. With a custom
>login function, this would allow you to break in to Bindery-mode servers.

Wrong, SERVER.EXE does not decrypt the password, it just encrypts it
the same way as is is done on the workstation, if the encrypted password
that is sent over the network matches it's own calculation it supposes
you entered the correct password.

If system management is not very careful and leaves net$*.old files
in a publicly readable place, the encrypted passwords stored in them
can be used to login to the network. (You would have to write your own
login which skips half of the encryption algorithm).

willem