HDTenEightyP/NetNews huggingface dataset:
From: pcl@oxford.ac.uk (Paul Leyland)
Newsgroups: alt.security
Subject: Re: Crack and exabyte libraries
Date: 24 Jul 92 14:58:41 GMT
Organization: Oxford University Computing Service, 13 Banbury Rd, Oxford, OX2
	6NN
In-reply-to: rjq@phys.ksu.edu's message of 22 Jul 92 22:04:44 GMT


In article <14km1sINN1ah@moe.ksu.ksu.edu> rjq@phys.ksu.edu (Rob Quinn) writes:

... lots of stuff deleted.

    20? Crack4.1 comes with over 240 rules in the dicts.rules file.

But not all rules generate significantly different output.  E.g. a lot
of rules throw away words; some may generate the same output as each other.


    Regarding the question of multiple passwords encrypting to the same thing,
   if people were trusting enough to share F.merged files we might find out.

I have already suggested this to AEM.  I also suggested recording the
rule and word from which the password was generated in the feedback
file.

   Any ideas on how to do that anonymously and safely? Didn't think so.

I'd be quite happy to give you password/salt pairs from which you could
regenerate the encrypted password.  Indeed, at a security talk I gave
a few weeks back, one of my slides was a list of 150-odd passwords that
Crack had guessed.  I *know* that at least two members of the audience
were looking at their ex-passwords 8-)

At our site, we run Crack regularly; we run npasswd; on those systems
which support it, we run shadow passwords; and we also disable any
account whose password is cracked.  The user then has to apply to a
sysadmin, with proof of identity, to have the account re-enabled with
a new password.

Paul
--
Paul Leyland <pcl@oxford.ac.uk>          | Hanging on in quiet desperation is
Oxford University Computing Service      |     the English way.
13 Banbury Road, Oxford, OX2 6NN, UK     | The time is come, the song is over.
Tel: +44-865-273200  Fax: +44-865-273275 | Thought I'd something more to say.
Newsgroups: alt.security
From: cp78068@csie.nctu.edu.tw (Yuh-Sheng Lee)
Subject: audit's record
Organization: National Chiao Tung University
X-Newsreader: Tin 1.1 PL3
Date: Thu, 23 Jul 1992 15:58:00 GMT


Several days ago, I finished installing auditing on Sun workstation, and I
really got some useful data it recorded. But now I meet some problem: when
the audit recorded that some file opened, I didn't know which file is opened
at all because I have no way to know from these records. What I want to ask
is how can I know the file's identity to be opened from the data that audit
records.
--
 

 =============================================================================
 Yuh-Sheng Lee ( Vincent )          | e-mail : cp78068@csie.nctu.edu.tw
 Dept. of Comp. Science & Info. Eng.| c-name :  | @ (Chinese)
 National Chiao-Tung University     |
 Hsin-Chu, Taiwan, R.O.C.           | 
 =============================================================================
Xref: sparky alt.security:4051 sci.crypt:2786
From: limes@ouroborous.Eng.Sun.COM (Greg Limes)
Newsgroups: alt.security,sci.crypt
Subject: Re: passwd security check
Date: 30 Jul 1992 18:12:22 GMT
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: ouroborous

In article <Bs7LL0.5GL@solbourne.com> imp@solbourne.com (Warner Losh) writes:
| I thought that the 01010101 was a series of bit values, rather than
| hex values.  Since they are hex values, they are indeed quite hard to
| type as characters at a Password: prompt.

How about holding down the CTRL key and hitting 'A' eight times?
From: brossard@siisun.epfl.ch (Alain Brossard EPFL-SIC/SII)
Newsgroups: alt.security
Subject: Re: CERT ADVISORY - Multiple SunOS Vulnerabilities
Date: 24 Jul 92 09:25:25 GMT
Reply-To: brossard@sic.epfl.ch
Organization: Ecole Polytechnique Federale de Lausanne

In article <g=tx##p@rpi.edu>, fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald) writes:
|> Casper H.S. Dik writes:
|> >
|> >BUGID: 1095935 
|> >	NFS server in which a client presenting a 32-bit uid in which 
|> >	the 16 low-order bits are 0 gets interpreted as root on the server.
|> 
|> Are there any operating systems available that present a 32 bit uid?

 Solaris 2.0 ...
-- 

Alain Brossard, Ecole Polytechnique Federale de Lausanne,
	SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, +41 21 693-2211
brossard@sic.epfl.ch
From: avalon@coombs.anu.edu.au (Darren Reed)
Subject: Re: CERT ADVISORY - Multiple SunOS Vulnerabilities
Organization: Computer Services Centre, Australian National University
Date: 24 Jul 92 10:51:36 GMT

fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald) writes:

>Casper H.S. Dik writes:
>>
>>BUGID: 1095935 
>>	NFS server in which a client presenting a 32-bit uid in which 
>>	the 16 low-order bits are 0 gets interpreted as root on the server.

>Are there any operating systems available that present a 32 bit uid?

>Brian

OS's arent the only things which can use NFS. How hard would it be to write
an NFS client which connected to the server using NFS ?

And if you were a hacker and knew this was a problem, would you try writing
such an NFS client ?

Given that in both cases a normal user doesnt have to bind to a priveledged
port nor access the raw socket to write such a client, i think there could
well be some problems.

darren
From: srobiner@pollux.usc.edu (Steven Robiner)
Newsgroups: alt.security
Subject: BRUTE force search (was Re: passwd security check)
Followup-To: world
Date: 23 Jul 1992 23:07:35 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: pollux.usc.edu

In article <12431@inews.intel.com> adam@gomez.intel.com (Adam Margulies ~) writes:
>In article <14mgkaINN1uq@moe.ksu.ksu.edu> rjq@phys.ksu.edu (Rob Quinn) writes:
>>In <1992Jul23.092715.1@zodiac.rutgers.edu> leichter@zodiac.rutgers.edu writes:
>>]One thing it's important to remember is that there are many passwords that
>>]hash to the same value.  Even if you and I have the same salt and the same
>>]hash value, it doesn't mean we chose the same password - though it DOES mean
>>
>>has come up a lot before, and there have been answers on both sides, but no
>>proof either way that I have seen.
>
>DES has a theorectical weakness in that for any key there are exactly 7 other keys that will
>crypt to the same string. I.E. if your password is "batman!" there exist seven other keys which
>are not "batman!" that will allow access to your account. Fortunately they are almost certainly
>extremely strange strings like "@gW #s(u", and not likely to match a human generated password.
>
>Another interesting thing about DES is that there are 8 keys that crypt to a string of
>all spaces and there are even keys that when encrypted reproduce themselves in the
>crypted output. Weird.


Talk about encryption - how about those encrypted characters after column 80?

Anyway, on to the real subject: If there are 8 keys to every hashed password,
wouldn't a brute force search actually only require 1/8 of the number
of attempts to randomly hack passwords?

In light of this fact, doesn't this make the brute force method 
much more feasible.    Oh, and one more thing - I would just like to say that if you can read this you may be able to get a job as a high paying unix programmer and travel to far away lands to meet fabulous people who may be able to realize that not every program has word wrapping.







=steve=
















rn fodder
Newsgroups: alt.security
From: ldoming@wiliki.eng.hawaii.edu (Lawrence Domingo)
Subject: Re: PIN Codes
Organization: University of Engineering, College of Engineering
Date: Tue, 28 Jul 1992 09:04:18 GMT

I've followed this thread with great interest, but still have a problem
understanding one thing...

A few times in this conversation a scheme to defraud ATMs was mentioned
whereby a person "nets" the PIN codes and account numbers of unsuspecting
ATM users by spying on them as they enter their PIN and then recovering
the receipt that they may throw away.  The person then proceeds to fab-
ricate a new card with the stolen account number and PIN and then using it
to withdraw cash from the ATM.

BUT...how do they recreate the mag strip with all the correct information
if they don't know the PVK (pin key)?  If I understand correctly, in some
systems the account number and card number are encrypted using the pin key,
and the result written to track 2 of the mag strip.  Then a pin offset, also
writtem on track 2, is used to determine the actual pin from the encrypted
value.  In another system, the account number, card number, and pin are
encrypted using the PVK as a key, and then the result written to track 2.

In both cases, one would have to know the PVK or pin-key in order to know
what should be written to the mag strip when all you have is the account
number and PIN.

So how was the scheme pulled off?

ldoming @ wiliki.eng.hawaii.edu
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: alt.security
Subject: NFS vulnerability (was Re: CERT ADVISORY - ...)
Date: 24 Jul 92 20:57:47 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


In article <1992Jul24.114806.836@fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes:
>You should configure NFS such that only clients request from a priviliged
>port are accepted. This is possible in SunOS and you should do
>this if it doesn't break things. Crackers already have programs that
>make client requests from non-root user mode with faked credentials.

Crackers also have access to workstations on which they can become root
and use any port they like.
>
>Secure NFS is the only solution in environments were clients can't be
>trusted.

Yeah, or Kerberos-protected NFS as used in MIT Athena.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
Newsgroups: alt.security
From: acyoung@rodan.acs.syr.edu (Aaron C. Young)
Subject: What's better...DECInspect or RAXCO Security ToolKit?
Originator: acyoung@rodan.acs.syr.edu
Organization: Syracuse University, Syracuse, NY
Date: Wed, 29 Jul 92 16:32:28 EDT


Hello,

I am comparing DECInspect and RAXCO Security Toolkit in hopes of
finding security software that will aid me in securing our UNIX
systems.

I have reviewed both packages and I am leaning toward picking
RAXCO's package.  For the fact that it runs on more systems and
seems to do the same as DECInspect if not more.

I'd like to here any comments from anyone who has experience with
either package.

Thanks in advance,

Aaron C. Young
Unix Systems Security Manager
Computing Services
Syracuse University
Syracuse, New York  13244
(315) 443-3995
Newsgroups: alt.security
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: CERT ADVISORY - Multiple SunOS Vulnerabilities
Date: 22 Jul 92 19:46:50 GMT

In comp.security.announce, cert-advisory-request@CERT.ORG (CERT Advisory) writes:
    >CA-92:15                        CERT Advisory
    >                                July 21, 1992
    >                    Multiple SunOS Vulnerabilities Patched
    >--------------------------------------------------------------------------

    >NFS jumbo patch upgrade, SunOS 4.1, 4.1.1, 4.1.2, all architectures

What's new with THIS jumbo patch?  Is it the same jumbo patch?

    >ICMP redirects patch upgrade, SunOS 4.1, 4.1.1, 4.1.2, all architectures
    ...
    >     allows an intruder to close existing network connections to and from
				^^^^^
    ...
    >II.  Impact
    >     A remote user may deny network services on a Sun system.
			    ^^^^

So which is it, can they close existing ones or only deny new ones?

thanks for any info,
From: jadkins@blizzard..mps.ohio-state.edu (Jeff Adkins)
Newsgroups: alt.security
Subject: Re: Cuckoo's Egg (Was: Re: Sneakers (Upcoming movie about "hackers"))
Date: 28 Jul 1992 20:21:00 GMT
Organization: Byrd Polar Research Center
NNTP-Posting-Host: blizzard.mps.ohio-state.edu

In article <1155@esl.ESL.COM> drw@esl.com (David Waters) writes:
>In article <1992Jul15.151447.4263@cdsmn.mn.org>, wells@cdsmn.mn.org (Rich Wells) writes:
>> 
>> Actually, it was made into a PBS show.  I think it may have been
>> an episode of Nova.  The author of the book (whose name completely
>> escapes me now) 'starred' in this re-creation of the book.
>
>
>It was Nova, and the episode was titled "The KGB, the CIA, the Computer,
>and Me". It was very entertaining. It might be on one of the Nova series'
>video releases.
>
>Dave

Cliff Stoll is the author. (signed copy!!)
Xref: sparky alt.security:4043 sci.crypt:2780
From: ahaley@eoe.co.uk (Andrew Haley)
Newsgroups: alt.security,sci.crypt
Subject: Re: passwd security check
Date: 30 Jul 92 09:35:42 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: Tin 1.1 PL3

imp@solbourne.com (Warner Losh) writes:
: In article <1345@eouk9.eoe.co.uk> ahaley@eoe.co.uk (Andrew Haley) writes:
: >There are weak keys (e.g. 01 01 01 01 01 01 01 01) which do no real
: >scrambling at all, and some semi weak keys which do very little.  In
: >fact, these keys are very useful for testing DES implementations.
: >You'd have to be pretty determined to get these into an ASCII
: >terminal, though.
: 
: Are you sure about this?  Assuming that your key one of the ones that
: has little protection, then it looks typable to me.  If DES uses only
: 7-bits of each byte, then the sequence that you describe would be
: ",U,U,U,U" which is pretty easy to type.  If DES used all 8-bits in
: each byte for the key, then the password would be "UUUUUUUU"  Either
: way, the password is easily typable.
: 
: Warner
: 
: 
: -- 
: Warner Losh		imp@Solbourne.COM
: Interview Horror Story #882: "It's pretty informal around here.
: Thursdays are clothing optional.."

How do you get from eight bytes of 01 hex to ",U,U,U,U"?  I don't
understand...

Andrew.
Newsgroups: alt.security,rec.arts.movies
From: manes@tandon.com (Dane Manes)
Subject: Re: Cuckoo's Egg (Was: Re: Sneakers (Upcoming movie about "hackers"))
Keywords: Cliff, Cuckoo's Egg, movie
Organization: Tandon Corporation, Moorpark, CA
Distribution: usa
Date: Fri, 24 Jul 1992 23:05:40 GMT

In article <1992Jul22.145830.364@bony1.bony.com> billg@bony1.bony.com (Bill Gripp) writes:
>
>While Christopher Lloyd is best known for his "psycho" roles (Rev Jim on
>Taxi, Doc Brown in Back to the Future, the Judge in Who Framed Roger
>Rabbit, etc. ) I have seen him do a serious role or two and he is very
>good.

Yikes!  You haven't seen _Track 29_ yet, obviously!  Just the thought of 
trains makes me shudder!

-- 
Dane Manes                  manes@tandon.com                 voice 805-378-7899
Tandon Corporation          76376.2266@compuserve.com          fax 805-529-9033
Product Support Engineer    "If it ain't broke, it hasn't been tested by Dane!"
---                                                                         ---
Xref: sparky alt.security:4060 sci.crypt:2795
From: ahaley@eoe.co.uk (Andrew Haley)
Newsgroups: alt.security,sci.crypt
Subject: Re: passwd security check
Date: 31 Jul 92 08:59:23 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: Tin 1.1 PL3

limes@ouroborous.Eng.Sun.COM (Greg Limes) writes:
: In article <Bs7LL0.5GL@solbourne.com> imp@solbourne.com (Warner Losh) writes:
: | I thought that the 01010101 was a series of bit values, rather than
: | hex values.  Since they are hex values, they are indeed quite hard to
: | type as characters at a Password: prompt.
: 
: How about holding down the CTRL key and hitting 'A' eight times?

OK, someone could do it.  They'd have to be a bit brain damaged,
that's all...  But anything's possible.

:-)

Andrew.
Newsgroups: alt.security
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: CERT ADVISORY - Multiple SunOS Vulnerabilities
Organization: FWI, University of Amsterdam
Date: Fri, 24 Jul 1992 11:48:06 GMT

avalon@coombs.anu.edu.au (Darren Reed) writes:

>fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald) writes:

>>Casper H.S. Dik writes:
>>>
>>>BUGID: 1095935 
>>>	NFS server in which a client presenting a 32-bit uid in which 
>>>	the 16 low-order bits are 0 gets interpreted as root on the server.

>>Are there any operating systems available that present a 32 bit uid?

>>Brian

>OS's arent the only things which can use NFS. How hard would it be to write
>an NFS client which connected to the server using NFS ?

>And if you were a hacker and knew this was a problem, would you try writing
>such an NFS client ?

>Given that in both cases a normal user doesnt have to bind to a priveledged
>port nor access the raw socket to write such a client, i think there could
>well be some problems.

You should configure NFS such that only clients request from a priviliged
port are accepted. This is possible in SunOS and you should do
this if it doesn't break things. Crackers already have programs that
make client requests from non-root user mode with faked credentials.

See /etc/rc.local for details on what to change. You should chose
the more secure branch in all if [ -f /etc/security/passwd.adjunct ] 
then ... else ... fi parts, unless this breaks other machines on
the net.

I would assume that this NFS bug is not serious in a environment of
well controled clients (i.e., relatively safe multi-user machines)
with NFS configured to accept only request from a priviliged port.
I don't know whether this bug defeats the root -> nobody mapping.
(this depends on whether the uid is truncated before or after the
 check for 0). If it defeats the mapping, I would apply this fix ASAP as
 it would give all clients root access.

Secure NFS is the only solution in environments were clients can't be
trusted.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
From: spencer@rise.Princeton.EDU (S. Spencer Sun)
Newsgroups: alt.security
Subject: Re: passwd security check
Date: 24 Jul 92 03:36:01 GMT
Reply-To: spencer@phoenix.princeton.edu (S. Spencer Sun)
Organization: Live Organ Transplants

In article <1992Jul22.221222.6185@Princeton.EDU>, dawagner@phoenix.Princeton.EDU (David A. Wagner) writes:
>
>	Let me restate.  Lemme call 'E(p,s)' the encryption function,
>where 'p' is the password and 's' is the salt.  The easier case asks
>if this is possible:
>
>[1]	E(p,s) =  E(q,s)		with p,q two different passwords
>
>The second (tougher) case asks if a function 'f' exists so that:
>
>[2]	f(E(p,s),s,t) = E(p,t)		with s,t two different seeds
>
>	My intuition would suggest that satisfying [2] is at least as
>hard as satisfying [1] (if DES isn't broken 1/2 ;-).  Any ideas?

It seems to me that finding function f is pretty "hard," since if such a
function existed, it would eliminate the usefulness of having different
salts.  Someone with the algorithm and an appropriate program could
first take the entire list of passwords and convert them all to the same
salt.  Dunno if this would help or not.  (Just a thought)

----------- The opinions expressed in this article are solely mine. -----------
<Insert lame attempt at disclaimer humor>
sss/PU'94 Dept of CS (spencer@phoenix.princeton.edu)/JvNCnet (spencer@jvnc.net)
Please be considerate, and don't talk during the show!  (SSSSSSHHH!)
Thank you for coming to Loews!  Sit back and relax -- enjoy the show!
Xref: sparky alt.security:4046 sci.crypt:2782
From: john@iastate.edu (John Hascall)
Newsgroups: alt.security,sci.crypt
Subject: Re: passwd security check
Date: 30 Jul 92 14:55:54 GMT
Article-I.D.: news.1992Jul30.145554.20787
Organization: Iowa State University, Ames, IA

ahaley@eoe.co.uk (Andrew Haley) writes:
}imp@solbourne.com (Warner Losh) writes:
}: In article <1345@eouk9.eoe.co.uk> ahaley@eoe.co.uk (Andrew Haley) writes:
}: >There are weak keys (e.g. 01 01 01 01 01 01 01 01) which do no real
}: Are you sure about this?  Assuming that your key one of the ones that
}: has little protection, then it looks typable to me.  If DES uses only
}: 7-bits of each byte, then the sequence that you describe would be
}: ",U,U,U,U" which is pretty easy to type.  If DES used all 8-bits in
}: each byte for the key, then the password would be "UUUUUUUU"  Either
}: way, the password is easily typable.
}How do you get from eight bytes of 01 hex to ",U,U,U,U"?  I don't
}understand...

U is 01010101 (base 2), no base was given above, so perhaps he was
confused about the base.

John
-- 
John Hascall                                       ``Live with it pink-boy!''
Project Vincent                                                              
Iowa State University Computation Center                     john@iastate.edu
Ames, IA  50011                                      515/294-9551 [fax -1717]
Newsgroups: alt.security
From: Marc VanHeyningen <mvanheyn@silky.cs.indiana.edu>
Subject: Re: passwd security check
X-Quoted: 52%
Reply-To: mvanheyn@whale.cs.indiana.edu
Organization: Computer Science Dept, Indiana University
Date: Sat, 25 Jul 1992 00:11:36 -0500

Thus said flaps@dgp.toronto.edu (Alan J Rosenthal):
>technews@iitmax.iit.edu (Kevin Kadow) writes:
>>Can somebody point me to a program that will do a security "audit" on the passwd
>>file, e.g. reporting (either in a file or as e-mail to the concerned parties)
>>when 2 or more accounts have the same password, and other "holes" that would
>>not be found by crack?
>
>apart from the big security problem others have pointed out, you can't do this
>without cracking the two individual passwords anyway, unless they were
>encrypted with the same salt (if the randomization is good, just one chance
>in 4096).

Of course, it would be easy to do it with a fascist passwd program.
Just have it check the given password against all the ones in the file,
and if it matches, it prints a message saying "Sorry, that is the same
as the password for user flaps."  That way, people wouldn't use the same
passwords, and security would be increased.

(Oh yeah, :-)
-- 
Marc VanHeyningen     mvanheyn@whale.cs.indiana.edu     MIME accepted

"James equal frothy DNA"        "Joyful Qatar headsmen."
		- my favorite anagrams of "James Danforth Quayle"
From: rja14@cl.cam.ac.uk (Ross Anderson)
Newsgroups: alt.security
Subject: Re: PIN Codes
Date: 29 Jul 92 12:10:48 GMT
Reply-To: rja14@cl.cam.ac.uk (Ross Anderson)
Organization: U of Cambridge Computer Lab, UK


In <1992Jul28.090418.854@news.Hawaii.edu>, ldoming@wiliki.eng.hawaii.edu
(Lawrence Domingo) writes:


> BUT...how do they recreate the mag strip with all the correct information
> if they don't know the PVK (pin key)?  If I understand correctly, in some
> systems the account number and card number are encrypted using the pin key,
> and the result written to track 2 of the mag strip.

Some systems do something like this.

> Then a pin offset, also writtem on track 2, is used to determine the actual 
pin from the encrypted value.

Not that I've come across. You either have an offset, or the PIN and account
number encrypted, or nothing at all except the account number and expiry date. 
It is this last type of system which is so vulnerable to crooks looking 
over the customer's shoulder.

> In both cases, one would have to know the PVK or pin-key in order to know
> what should be written to the mag strip when all you have is the account
> number and PIN.

Not quite. Offsets usually have a default value of zero as that was the IBM
way of doing things. A nontrivial proportion of customers may never have
bothered to change their PINs and so you can just write a zero offset to
the card and hope for the best.

As a result of all the posting here, I've got a fair bit of email and one
item in particular should be of interest. Last month, at a market stall in
High Wycombe, England, a stallholder was offering some pretty good bargains.
To pay with your credit or debit card, you just swiped it in his reader,
types a PIN into the portable PC to which the reader was attached, and got
a beautiful printed receipt. . .

Ross
Xref: sparky alt.security:3974 comp.security.misc:771