The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1988)
DOCUMENT: Rutgers 'Security List' for December 1988 (62 messages, 30553 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1988/12.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
From:      texbell!rpp386!scsmo1!tim@cs.utexas.edu  5-DEC-1988 17:58:27
To:        unix-wizards@sem.brl.mil
>But, in the UK at least, if you abort the 'login' attempt after the 2nd
>attempt (there is a button to do this), you get your card back, and can
>then try again immediately.  Thus you have an unlimited number of attempts.
>I have not tried this on a machine in the US.

This will work in the U.S.  Some machines will kick the card out after 3
incorrect tries.  One machine I tried 8 times, it didn't take the card, but
later after the card had been slightly mutated it took it.

I had the number changed on my card,  there was an ibm pc connected to a card
reader.  I typed in the number (on a seperate keypad) and the banker
slid the card back through the card reader.  The pc was _NOT_ connected
to anything.

>This no longer has much to do with Unix.
But it does have to do with money.  How about terminals that have card readers?

The biggest security problem is users that don't think about security problems,
They tell other users their passwords (the don't like using paths to get files)

						Tim Hogard
						tim@scsmo1.uucp
						Soil Conservation Service.
-----------[000001][next][prev][last][first]----------------------------------------------------
From:      Phil Hughes <ssc!fyl@teltone.com>  5-DEC-1988 17:59:32
To:        unix-wizards@sem.brl.mil
In article <1526@holos0.UUCP>, lbr@holos0.UUCP (Len Reed) writes:
> From article <438@amanue.UUCP>, by jr@amanue.UUCP (Jim Rosenberg):
> = Well surprise:  This exact password system is ***IN USE***!!!  In (are you
> = ready:) ***BANKS***!!!  I am not kidding.  Do you have an Automatic Teller
> = Machine card?  What does your password look like?  Every time I've been given
> = one of those things the password was just 4 digits!!!!!!!

> You have to have physical possession of the card, too, not just knowledge
> of the account number.  

Not really true.  If you are serious about ATM fraud you can buy a mag
stripe writer for about $300.  I used to work for a company that makes
automatic gas station equipment -- stick in your card, punch in your PIN
and pump gas.  We bought a card writer.  I made myself an extra EXCHANGE
card.  Sort of fun.

By the way, track 2 on the cards is the account number.  Most bank
machines either ignore or display track 1.  Rainier Bank locally puts your
name on track one and displays it on the terminal.  Rewrite track 1 and
when you enter your card you can get a nice message like:
	GOOD AFTERNOON YOU ROTTEN CROOK
on the display.  It amuses the people waiting in line behind you.

Now, for a worse story -- as of two years ago every ATM machine in a whole
state would accept a particular 4 digit number as a valid pin for every
card.  Yes, really.  I was doing testing on a controller to hook into
their network and it wasn't getting invalid PIN errors.  As it turned out
there was a bug in our software and it wasn't sending the PIN that was
being entered.  It just happened to be sending the magic PIN for the
network.  Now that was really stupid.
-- 
Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155  (206)FOR-UNIX
    uw-beaver!tikal!ssc!fyl or uunet!pilchuck!ssc!fyl or attmail!ssc!fyl
-----------[000002][next][prev][last][first]----------------------------------------------------
From:      Ralph.Hyre@ius3.ius.cs.cmu.edu  6-Dec-1988  6:34:16
To:        misc-security@rutgers.edu
>  Can the courts compel Bozo to divulge the key and method
>  of encryption of the data on the seized computer?
Bozo might be better off taking the Fifth on this one.

I though I heard about a case where a user WAS compelled to decrypt the
data.  Anyone know of any other precedents?

Since the police/DA can bring almost unlimited resources to bear
on the problem, it is VITAL that the encryption be secure.

-- 
					- Ralph W. Hyre, Jr.
Internet: ralphw@ius3.cs.cmu.edu    Phone:(412) CMU-BUGS
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
"You can do what you want with my computer, but leave me alone!8-)"
-----------[000003][next][prev][last][first]----------------------------------------------------
From:      hplabs!marki@hpiacla.hp.com (Mark Ikemoto)  6-Dec-1988  6:44:17
To:        misc-security@rutgers.edu
This is for a co-worker:

He is looking for source code of an implementation of the
Data Encryption Standard (DES).

He is looking to encrypt user passwords, account passwords, etc.,
inside of message streams that are transmitted over a LAN.  For
security reasons, he is encrypting this data, and has chosen the
DES as the standard to use for this purpose.

Anything you can provide will be helpful.  I'll route any responses
to him.

Mark
-----------[000004][next][prev][last][first]----------------------------------------------------
From:      ames!rochester!kodak!doering@ucbvax.berkeley.edu (Paul Doering)  6-Dec-1988  6:54:17
To:        security@pyrite.rutgers.edu
There are a few alternatives in the question of key-management for
encryptors on data lines. Among these are (a) management by a central
authority within the user's company, (b) dispersed management by site
administrators within the company's network, and (c) management by the
vendor of the encrypting hardware/software package.

I would appreciate opinions on the strengths and weaknesses of these
alternatives in practice.  Thanks.
-----------[000005][next][prev][last][first]----------------------------------------------------
From:      *Hobbit* <hobbit@pyrite.rutgers.edu>  6-Dec-1988  7:24:17
To:        security@pyrite.rutgers.edu
Naturally I've started to get submissions for the list, but there are some
items of interest from "long ago" [i.e. things that were still sitting around
in the incoming queue since last July] that I'd like to send out also.  So that
the readership doesn't get confused about who's answering who, I will add
the string "### OLD MSG ###" to the Subject: lines of the applicable messages.  
I will attempt to find ones apropos of the "current things" being discussed..

_H*
-----------[000006][next][prev][last][first]----------------------------------------------------
From:      jbrown@jato.jpl.nasa.gov (Jordan Brown)  7-Dec-1988 13:17:12
To:        misc-security@ames.arc.nasa.gov
This seems like a good forum to chatter about one of my pet peeves...

I've worked at a couple of places where they placed some value on
physical security.  Computer rooms were locked; desks were often
locked.  This was a real nuisance, and pointless as well.  Most desks
have locks that can be picked with a paper clip, and that's the hard way
to get into them.  The easy way is to loosen the screws holding the
center drawer up until it drops far enough to allow the latch to
release.  Takes about 30 seconds; leaves no marks.  Similar methods can
be applied to many cabinets.  Most modern office buildings have false
ceilings... unless your computer room has structural walls surrounding
it, just remove a ceiling tile from an unsecured room adjacent to the
computer room, climb into the false ceiling, and remove a tile from the
ceiling in the computer room and jump in.  Takes about 5 minutes.

Physical security is just great (it's usually easier to prove than
computer security, for sure), but if it isn't done carefully it just
wastes people's time.  Worse, it can give people a *false* sense of
security.

Relatedly... have your vendor's field service techs signed nondisclosure
agreements?  Are you sure there's nothing in your computer room that you
want to hide?  I once had a FS rep tell me that somebody had pumped him about
the contents of our computer room...  luckily he was ethical and
didn't leak anything.
-----------[000007][next][prev][last][first]----------------------------------------------------
From:      <COLEMAN@umbsky.bitnet>  7-Dec-1988 13:18:15
To:        security@pyrite.rutgers.edu
[### OLD MSG ###]

Hi,
     I've recently inherited the job of finding equipment designed to secure
manuals in a public terminal room. We've had problems in the past as our
current equipment does not allow us to lock the manuals to anything. We'll
probably be placing most of a VMS 5.0 documentation set out for the students
and we don't want to replace manuals which might be lost, damaged or stolen.

     I would appreciate hearing from any and all people who've had to deal
with something like this in the past. What products have you used and what
degree of success have you had? How easy is it to access the materials?
Does the equipment handle the standard 3 ring binder paper along with DEC's
smaller 3 ring binder manuals? Any other problems and/or notes of interest?

     Also, if other sites have different methods of giving students access
to the manual sets, what (if successful) methods have you used? Just because
we've used one system in the past doesn't mean we can't use something else
which might be better.

     Please send all responses to me. And thanks!

                               Steve Coleman
                               Computing Services
                               University of Massachusetts at Boston
                               Boston Ma 02125
                               (617) 929-7837
                               Bitnet:      COLEMAN@UMBSKY
                                            USERSERVICES@UMBSKY
-----------[000008][next][prev][last][first]----------------------------------------------------
From:      *Hobbit* <hobbit@pyrite.rutgers.edu>  9-Dec-1988  2:41:23
To:        security@pyrite.rutgers.edu
Many of you have been complaining of duplicate messages, and I know quite
well that they're being sent, and there's not a whole lot I can do about it.
Some of the running sendmail delivery processes got gunned down by mistake,
and more recently we had some problems with other machines which caused
weirdness to happen on pyrite [nfs mounts and all that].  Thus when the queue
restarted it found things waiting to be delivered and had no clue that they'd
already been taken care of, so out they went again.

I'm trying to get things smoothed out on this end but each message has many
recipients, and Sendmail apparently *isn't* checkpointing the queue like
it's supposed to, so unless a given message's delivery process is allowed to
run to completion, we lose.  Please bear with; you all have N keys...

_H*
-----------[000009][next][prev][last][first]----------------------------------------------------
From:      GREENY <MISS026@ECNCDC.BITNET>  9-Dec-1988  3:21:23
To:        <security@pyrite.rutgers.edu>
Does anyone out there know the procedure that one would have to go through to
legally be considered a locksmith?

Thanx in advance...
Bye for now but not for long
Greeny

Bitnet: miss026@ecncdc
Internet: miss026%ecncdc.bitnet@cunyvm.cuny.edu
Disclaimer: Nope....not me...I had nothing to do with it!

P.s. I'm in Illinois...
-----------[000010][next][prev][last][first]----------------------------------------------------
From:      HXWY@cornella.cit.cornell.edu  9-Dec-1988  3:31:23
To:        <SECURITY@pyrite.rutgers.edu>
I'm glad to see the news group back, because I really could have used
it this semester.  I recently finished two papers, one on blue box
fraud, and another on cellular telephony privacy, and would have
appreciated some input from the internet communitity.

How about some input as to the security of the coming digital
cellular telephone?  I realize this was a subject kinda beaten
to death a few years ago, but developments in technology have
made digital cellular a marketable reality in about 1991.  How
soon is this going to be implemented?  Can old phones be
retrofitted?  How hard is it for the hobbiest to change
his usage to receive this?  How about criminal elements, how
hard are they going to go?  Are they just going to give up on
listening to "the soap opera without words"?  Any input onto
specifics of digital cellular implementation or when this is
going to happen would be of interest (at least to me)
djf
-----------[000011][next][prev][last][first]----------------------------------------------------
From:      desmedt@csd4.milw.wisc.edu (Yvo Desmedt)  9-Dec-1988  3:41:23
To:        misc-security@uunet.uu.net
UWM WORKING GROUP ON DATA SECURITY

The UWM Working Group on Data Security will be holding bi-weekly meetings at
the University of Wisconsin-Milwaukee. The format of the meetings is informal.
The workshop committee members are:

    Professor George Davida (Chairman)         Professor Yvo Desmedt
         Telephone: (414) 229-5192           Telephone: (414) 229-6762

                           Professor Rene Peralta.
                          Telephone: (414) 229-5861

Attendees (and visitors) who wish to present papers or preliminary results
can contact one of the committee members to arrange the presentation.

Topics of discussion will include:

        Applications of Data Security      Physical Security                
        Authentication                     Privacy                          
        Computer Networks                  Protocols                        
        Computer Security                  Pseudorandom Sequences           
        Cryptography                       Secure Transactions              
        Database Security                  Signatures                       
        Key Management                     Symmetric and
        OS Security                           Asymmetric Ciphers 
                                           Trojan Horses (e.g. Viruses)     

The meetings will be on Fridays at 3:30 pm. [September 16,30: October 14,28
November 11,25: December 9. There will be no meeting December 23.] All the
meetings will be held in:
        Room EMS E129,
        The Engineering and Mathematical Sciences Building,
        3200 N. Cramer St.,
        Milwaukee, Wisconsin  53201.
        U.S.A.

For further information contact one of the committee members, or send
e-mail to:
   arpa:   uwm-crypto@uwm-cs.milw.wisc.edu
   bitnet: uwm-crypto%uwm-cs.milw.wisc.edu@wiscvm.bitnet
   csnet:  uwm-crypto@uwm.csnet
   uucp:  {seismo|nike|ucbvax|harvard|rutgers!ihnp4}!uwmcsd1!uwmeecs!uwm-crypto

The US-mail address of the committee members is:
        Dept. EE & CS
        College Of Engineering & Applied Science
        University of Wisconsin-Milwaukee
        P.O. Box 784
        Milwaukee, Wisconsin  53201.
        U.S.A.
        Telephone: (414) 229-4677
-----------[000012][next][prev][last][first]----------------------------------------------------
From:      Michael Kielsky <AGMGK@ASUACVAX>  9-Dec-1988 10:51:26
To:        security@ubvm
     I am currently in the process of developing research for a
     thesis.  The topic of this research is "Computer Security in
     the Manufacturing Environment".

     I am seeking your assistance in obtaining information
     relevant to this topic, as there currently exists no
     published data. Specifically, I would like to reach people
     in industry who have involvement in Computer Integrated
     Manufacturing (CIM), and related fields, and would be
     willing to provide me some information on their experiences
     with computer security in that environment.

     Helpful information would include policies and procedures
     (current or past), actual experiences, etc., regarding
     Computer Security (in its broadest interpretation),
     implemented specifically in the Computer Integrated
     Manufacturing (CIM) and related environments.  Suggestions
     gladly considered.

     The data obtained will be compiled and published in Spring
     1989, as my master's thesis.

     I can be contacted as follows:

         work:                       home:

             Michael Kielsky             1902 E. St. Catherine
             Sr. Software Engineer       Phoenix, AZ  85040
             TAG Software                (602) 276-4663
             5420-100 W. Camelback
             Glendale, AZ  85301
             (602) 939-3580 or 242-9401
             (602) 939-9671 (Fax)

         or via electronic mail:

             BITNET address:  AGMGK@ASUACVAX
             DECnet address:  ACVAX::AGMGK

     If you know of anyone else who might be able to help me out,
     please feel free to pass along a copy of this letter.

     Your help will be appreciated.

     Michael Kielsky
-----------[000013][next][prev][last][first]----------------------------------------------------
From:      kerchen@iris.ucdavis.edu  9-Dec-1988 11:01:27
To:        <misc-security@ucbvax.berkeley.edu>
Nick Papadakis writes:
	"The only people that have to worry about viruses are those
	that don't distribute source"  (or something close to that).

I have to strongly disagree.  Although it is much easier to put a
virus or trojan horse or both into executable files, one could also
put one into source code.  This source code could then be distributed,
with people compiling the code and running it at home with the same 
effect as a virus in an executable.  One only has to
be a little more clever in hiding the virus code amongst the
legitimate code.  Now, one might argue that all one needs to do is
look at the code, but this quickly becomes unfeasible beyond 1000 
lines of code (the limit of current automated program verification
techniques is about 1000 lines).  If a computer can only verify 
1000 lines of code, what human being is going to want to try 2000?
10000?  Indeed, distributing source is not the answer.  

punchline: I am currently researching viruses/trojan horses/etc here
at the University of California, Davis, so I would be interested in
pursuing this thread of conversation further.  If you've had 
experiences with viruses, knowledge of viruses, or anything else
which I or other interested parties might find useful, please don't
hesitate to e-mail them to this group or directly to either me
(kerchen@iris.ucdavis.edu) or my group (virus@iris.ucdavis.edu).  Any
contributions would be greatly appreciated.
 
Paul Kerchen				| kerchen@iris.ucdavis.edu
-----------[000014][next][prev][last][first]----------------------------------------------------
From:      Bernie Cosell <cosell@bbn.com>  9-Dec-1988 11:11:27
To:        misc-security@uunet.uu.net
I wonder if someone would indulge me with a mini-tutorial on why password
aging is a good thing.  It seems to be a veritable shibboleth among many of
the system administrators around here (elsewhere too, I suspect) and I find
it little more than a damn nuisance that lends virutally nothing to the
overall security of the systems involved.

I have several assumptions here: (a) the passwords are well chosen.  I have
*never* heard of anyone cracking a system with well-chosen passwords.  I'm
sure it has happened, but virtually all of the breakins I'm aware of involved
either other soft-spots in the system (e.g., the rlogin stuff) or taking
advantage of poorly-chosen passwords; (b) nobody will (or, probably, can)
cryptanalytically attack the raw password information.  (and on this, the SAs
even admit that they're not really worried about this)

When I press the SAs on just why it is that they like password aging so much,
I get a lot of hemming and hawing, and a lot of places where password aging
might slightly limit the damage due to administrative screwups (mostly having
to do with shared accounts, which are mostly bad ideas in the first place).
I can understand (and even sympathize) with the position of an SA being that
"it makes me feel more comfortable to know that my @ss is a bit covered in
case I screw up and forget to do something".  But the almost totemic way that
password aging keeps coming up over and over makes me think that there must
be _something_ more substantive to it.  Am I missing the obvious again?  tnx

   __
  /  )                              Bernie Cosell
 /--<  _  __  __   o _              BBN Sys & Tech, Cambridge, MA 02238
/___/_(<_/ (_/) )_(_(<_             cosell@bbn.com
-----------[000015][next][prev][last][first]----------------------------------------------------
From:      Ron Natalie <ron@ron.rutgers.edu>  9-DEC-1988 18:50:24
To:        unix-wizards@sem.brl.mil
The cards themselves are easily forged.  Essentially, nothing is
encoded in the stripe that you can't see on the front of the card.
Obviously criminal elements have the ability to forge this information
because well publicised cases of credit cards (which use the same technology)
exist.  When dealing with a machine, it's even easier, the card doesn't
need to look real to the eye, just have the correct data on the stripe.

Even if the PIN records at the bank are relatively secure, there are
many ways that the 4 digit number may be discovered.  Abuse of telephone
credit card numbers (which are essentially just your account number (
phone number) and a 4 digit PIN) inidicate how vulnerable that system
is.  Banks mail PINs (albeit separately from the cards) through the
use of printthrough computer envelopes.  You don't even need to open
these to get the information.   Banks should never send the PINs out.
Here we get to go to the bank to set them.  People should safeguard their
PINs.  Be careful about the guy behind you in line.   Don't write them
down, and if you get to pick your own, don't be so bloody obvious.
I guessed my wifes with little difficulty.
-----------[000016][next][prev][last][first]----------------------------------------------------
From:      Ralph.Hyre@ius3.ius.cs.cmu.edu  12-Dec-1988 23:19:36
To:        Chriz@cup.portal.com
Cc:        misc-security@rutgers.edu
[attributed in its entirety, because I feel misc.security is a more reasonable
place than sci.crypt, since it doesn't deal with encryption.  Maybe
misc.spooks is a better place:-).]

In article <9511@cup.portal.com> Chriz@cup.portal.com writes:
|One of the problems facing a securities organization is the
|methods by which one detects and investigates security breaches
|are resource intensive.   I have concentrated on the
|resource-squandering dimension of value-based spoofs, but
|there is a dimension that will save the spy agencies alot of time
|and money.  Call it my contribution to the war effort.  It's
|called a "value-audit", and instead of empirically determining
|whether a suspect has any untoward connections or activities, it
|determines whether a suspect is capable of being a traitor.
|Here's how it works:
|1. A profile of the suspect is empirically determined, by
|empathizing with the suspect.  The profile delineates the values
|by which the suspect functions.  
|2. The empathetic portrait of the suspect is used to determine the
|value excesses that the suspect is capable of.  For instance, is
|he one who aggrandizes power--would he betray his country to
|aggrandize power?  Is he one who values money--would he sell out
|for cash?  Is he one with an ax to grind? and so on.

The IRS does this already to some extent, its called block analysis.
They buy companies' mailing lists, assuming that the companies' list
target people who might have something to hide.  For example, a subscriber
to 'Boating Week' might be hiding unreported 'undergound' income in the form
of a yacht.  They might assume that Wall Street Journal readers make
more than $30K/year.  (The goverment also sells lists of names they
collect to mailing list companies, it would appear.  I may be able
to dig up an example, but I think amateur callsigns & info are made
available to various ham organizations.)

|3. With the value excesses determined by the empathetic portrait
|of the suspect, the investigative agency assumes control of his
|personal inputs and outputs.  His credit card statements become
|the product of a government computer, his electric and phone
|bills are produced by a government computer, and certain phone
|numbers, such as the phone number to the electric company are
|routed to the government.  This is so the entire entity of bills,
|phone calls, and work habits becomes a totally observable system
|which the audit trails can be carefully mapped.

I'm reluctant to give the goverment the power to 'impersonate' other
entities, there should be a principle of 'least interference' with
everyday affairs in ANY preliminary or ongoing investigation.

|4. With this in mind, a series of subtle pranks are conducted
|which test a series of potential value excesses.  At work, he may
|find that he is the only one who knows about an error on the
|books.  At home, he may find his utility bill underestimated and
|credits he doesn't deserve given to him.  He may be introduced
|through the mail to a young woman.  An unidentifable piece of
|hi-tech equipment may appear via at his doorstep, misaddressed
|to him.

I'd fix everything else, but I believe you ARE legally allowed to keep
unsoliticed packages (received by U.S. Mail).  So I'd keep the high-tech
equipment, of course :-).

|5. The point is this, a series of events spanning a period of time will
|occur forcing the man to make an effort to maintain his integrity
|and good name.  They may also be the "tip of the iceberg" type of
|events that produce more information than they impart to the man.
|In that case, it will give the man a hint that he is being
|investigated and his reaction may be judged.

This smacks of entrapment.

|6.  For an innocent man, this will be an inconvenient but barely
|noticed security check.  For a guilty man, it will be an
|unbearable series of potential disasters.  At any given point,
|the empathetic portrait of the man will yeild a series of
|possible "innocent" responses, and at any given moment a series
|of "guilty" responses.  A consecutive series of guilty responses
|would be the start of a normal investigation.

This is the same argument given for the loosening of the exclusionary rule;
I don't agree with assuming guilt over innocence.

|7.  This could be computerized, so that a number of people could
|be efficiently tested at a given moment, and thus saving the
|government alot of money.
|
|I did use this technique in a bank, once, and discovered a
|multi-million dollar tax fraud scheme which was based on the fact
|that the bankers were so busy playing internal politics, that
|nobody was minding the shop.  That was their value-excess.

This is interesting stuff, but I'd worry about OUR government using it
on its own citizens.

Comments?
--
					- Ralph W. Hyre, Jr.
Internet: ralphw@ius3.cs.cmu.edu    Phone:(412) CMU-BUGS
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
"You can do what you want with my computer, but leave me alone!8-)"
-----------[000017][next][prev][last][first]----------------------------------------------------
From:      Devon Sean McCullough <DEVON@ai.ai.mit.edu>  12-Dec-1988 23:26:25
To:        security@pyrite.rutgers.edu, risks@csl.sri.com
I'm not on either of these lists, but here's my plug for peace, freedom, and
the ITS way.  On the oldest running operating system around, no software ever
presumes to prevent any human from doing anything whatsoever, for this is a
matter to be settled between humans in traditional human ways.  You trash my
files, I break your face.  There are railings to keep the rubes from hurting
themselves but no locks.  Security in obscurity.  Daily backups and automatic
logging of important doings have kept ITS running smoothly for decades in the
face of hurricanes and high school crackers with diplomatic immunity.  We even
have a sort of neighborhood watch and apprenticeship feature, so anyone can
observe and learn about the activites of anyone else.  Write-once media such
as laserdisks afford any system the security of full backups and tamper-proof
logs without infringing on any user's freedom to do his or her work.
-----------[000018][next][prev][last][first]----------------------------------------------------
From:      mason@eddie.mit.edu (Mark Mason)  13-Dec-1988 10:20:41
To:        marki@hpiacla.hp.com@hplabs.uucp, misc-security@rutgers.edu
Bob Baldwin (baldwin@xx.lcs.mit.edu) wrote a des package th
that is (literally) 100 times faster than the unix crypt call.
It is (or at least was) available for uucp from eddie.mit.edu
in /usr/spool/uucppublic or some such.
-----------[000019][next][prev][last][first]----------------------------------------------------
From:      "R. Gary Cutbill" <CUTBILL@RPICICGD.BITNET>  13-Dec-1988 10:30:41
To:        security@pyrite.rutgers.edu
[If he's talking about standard public-key, please reply to him, not the
list.  Thanx.  _H*]

Hi, I understand that there exists a scheme for data encryption/decryption
which envolves having a public key which is the product of two "large"
prime numbers.  Can anybody tell me about how large is "large".  Obviously
this is a variable number.  I'm just looking for a range of magnitude.

-R. Gary Cutbill
Cutbill@d.cicg.rpi.edu
-----------[000020][next][prev][last][first]----------------------------------------------------
From:      lvc@cbnews.att.com (Lawrence V. Cipriani)  13-Dec-1988 10:40:41
To:        misc-security@att.att.com
Some versions of the login program (eg in UTS), the user must
enter two passwords.  One is the users password, the second
"External Security Password" (ESP) is defined by the system
admin.  The ESP is changed once a month on the systems here
with it.  Concerns about users having dumb passwords, like
abc123, are thus reduced, as the ESP is usually hard, but
rememberable.

What do people think about this?  Is it worth the trouble?
If you're writing a PD login you might consider adding this
feature (and make it optional).
-- 
Larry Cipriani, AT&T Network Systems, Columbus OH,
Path: att!cbnews!lvc    Domain: lvc@cbnews.ATT.COM
-----------[000021][next][prev][last][first]----------------------------------------------------
From:      "Michael J. Chinni, SMCAR_CCS_E" <mchinni@ardec.arpa>  13-DEC-1988 14:23:12
To:        security@pyrite.rutgers.edu
F Y I

----- Forwarded message # 1:

From: Nathaniel Ingersoll <nate@altos86.uucp>
Subject: ATM passwords (PINs)
Date: 9 Dec 88 19:58:45 GMT
To:       unix-wizards@sem.brl.mil

The way I look at it, all ATM cards (at least all the ones
I've ever run across) do not have their PIN encoded on the card.
When you do a transaction, the following events must happen:
	1) enter card
	2) enter pin
	3) select transaction
	4) success: result of action
	5) failure: notification

Now, if your PIN was encoded on the card, you could be informed of
PIN failure immediately after (2).  However, the ATM waits to
perform all data transfer until it has all necessary information,
so it probably sends whatever you entered for a PIN, your transaction
data, and whatever else, to the remote computer, which then
validates the PIN and transaction.

Make sense?
-- 
Nathaniel Ingersoll
Altos Computer Systems, SJ CA
	...!ucbvax!sun!altos86!nate
	altos86!nate@sun.com

----- End of forwarded messages
-----------[000022][next][prev][last][first]----------------------------------------------------
From:      Joe McMahon <XRJDM@scfvm.gsfc.nasa.gov>  13-Dec-1988 22:40:47
To:        security@pyrite.rutgers.edu
I'm sure that many (or most) of the subscribers to this list are aware
that there is a virus discussion list at the LISTSERV at LEHIIBM1
(TELL LISTSERV AT LEHIIBM1 SUB VIRUS-L your-name). There is also
an Internet version of this list, but I'm not sure what the
node address is, nor how to sign up on the Internat.

--- Joe M.
-----------[000023][next][prev][last][first]----------------------------------------------------
From:      zemon%pernod.DEC@decwrl.dec.com (Art Zemon)  13-Dec-1988 22:50:48
To:        security@pyrite.rutgers.edu
And a lack of real physical security virtually eliminates any
computer (i.e., on-line) security that you may have implemented.
For instance, what good are file protections if the backup tapes
are physically available to anyone in the building on weekends?
 
Unless you can guarantee physical security of the computer, its
console, the backup tapes, and the disks, and probably any
network connections, it is probably best to consider a computer
to be almost completely unsecure.  I advise people that there is
only one way to keep private information on a timesharing
computer: move the information to tape and lock the tape in a
vault.
 
    -- Art Z.
       (expressing opinions, naturally, that don't represent my employer)
-----------[000024][next][prev][last][first]----------------------------------------------------
From:      the terminal of Geoff Goodfellow <geoff@fernwood.mpk.ca.us>  13-Dec-1988 23:00:47
To:        other_list@ucbvax.berkeley.edu
PC Week Connectivity, Page C/8, December 5, 88:

Sun's New Unix To Be Its Most Tamperproof Yet

  Gearing up to meet the growing demand for securing computing envionrments,
Sun Microsystems Inc. has announced SunOS Multi-Level Secure, which company
officials claim is the most tamperproof version of its Unix operating system
to date.

...
  Developed by Sun Microsystems Federal Inc., a wholly owned Sun subsidiary
based in Washington, the secure system software runs on Sun's 3, 4 and
high-security Tempest workstations and is based on Sun's version of Unix,
which merges Berkeley 4.5 Unix with AT&T System V.

...
  SunOS MLS has provisions for securing electronic mail and ensuring that
users have the appropriate level of classification to access data.
-----------[000025][next][prev][last][first]----------------------------------------------------
From:      Phil Springer <AUPAS@ASUACAD.BITNET>  15-Dec-1988  8:22:26
To:        security@pyrite.rutgers.edu
My response to this is to put the manuals in the library and have them for
check-out wit an ID. They would be due in 1-3 hours after they are checked
out. At Arizona State, we put them behind the operators counter where they
get their printouts, and ask for ID to use them. If they don't return the
manuals, they are charged $50 regardless of the cost of the manual.

This idea seems to work well.
-----------[000026][next][prev][last][first]----------------------------------------------------
From:      <RML3362@TAMVENUS.BITNET> (Mike Litchfield 'Flashback')  15-Dec-1988  8:42:27
To:        security@pyrite.rutgers.edu
I think that since since cellular phones are infact radios broadcasting over
open airwaves and privacy laws do not apply the next big feature which will
be seen on them is a scrambler.
admittedly this is not going to stop a dedicated snoop but like most passive
security devices it will make it a bit more difficult.
-michael
RML3362@tamvenus - bitnet
RML3362@tamvenus.tamu.edu - internet
TAMU-CSC has no idea what I think or say.
nor does it care
-----------[000027][next][prev][last][first]----------------------------------------------------
From:      wstef@beta.uucp (W. Gregg Stefancik)  15-Dec-1988  9:02:27
To:        security@pyrite.rutgers.edu
According to my sources (the locksmith trade journals) very few states have
any form of licensing for locksmiths.  In the cases where licensing does exist
it usually has nothing to do with proving ones skills as a locksmith.  For
example California has a licensing requirement.  To obtain this license 
one is required to submit their fingerprints a form to the state.  From what
I understand the state runs a simple background check to make sure you are
not a "criminal."

Gregg Stefancik
Professional Locksmith
-----------[000028][next][prev][last][first]----------------------------------------------------
From:      gwyn@smoke.brl.mil (Doug Gwyn )  15-Dec-1988 20:02:30
To:        misc-security@uunet.uu.net
>Does anyone out there know the procedure that one would have to go through to
>legally be considered a locksmith?

Some locales require certification testing, others don't.

Practically speaking you should be bonded before you offer
professional security services, to insure your customers.

Check with your local police, because in many locales
"possession of burglar tools" is considered a crime.
(I disagree with such laws; it is commission of burglary
that should be the crime, not ownership of a flashlight.)
-----------[000029][next][prev][last][first]----------------------------------------------------
From:      PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet  15-Dec-1988 20:22:30
To:        security%ubvm.bitnet@Hamlet.Bitnet
>I have to strongly disagree.  Although it is much easier to put a
>virus or trojan horse or both into executable files, one could also
>put one into source code.

This was in fact attempted on a BBS used by one of the columnists for
DEC Professional; in a recent issue he describes how he nearly released
a DCL command procedure that contained an innocuous-looking command that
in fact, when symbols were translated, would erase all system files
(after ensuring that it had all necessary privileges, done earlier in an
above-board manner).  He's practising safe computing from now on.

Peter Scott (pjs%grouch@jpl-mil.jpl.nasa.gov)
-----------[000030][next][prev][last][first]----------------------------------------------------
From:      DAvid James Flory <HXWY@cornella.cit.cornell.edu>  15-Dec-1988 20:42:30
To:        SECURITY@pyrite.rutgers.edu
Found some information on digital cellular phones.  will reduce cellular calls
to a hiss so no monitoring by scanners.  Will not be doable until 1995.
Europeans are testing it.  When its implemented it will have to support two
kinds of the cellular phones, both analog and digital.  some channels will be
digital, others analog, analog will be gradually phased out.  can have up to 8
users per channel.  will use either FDMA, TDMA or CDMA (what is CDMA.  Code
Division Multiplexing means nothing to me.)  not all markets will get this in
the forseeable future.  (only the top 5 or so) found this in a paper by Dr.
Herschel Shosteck "the long range demand for cellular telephone service"
Proceedings of the National Communications Forum Volume XXXXI Book 2 pages
889-897.
djf
-----------[000031][next][prev][last][first]----------------------------------------------------
From:      tedrick@ernie.berkeley.edu (Tom Tedrick)  15-Dec-1988 21:02:30
To:        Chriz@cup.portal.com, Ralph.Hyre@ius3.ius.cs.cmu.edu
Cc:        misc-security@rutgers.edu
These ideas aren't new (KGB does things like that according to Suvurov,
and so on). Not to say it isn't interesting.

Best,

      -Tom
-----------[000032][next][prev][last][first]----------------------------------------------------
From:      simsong@athena.mit.edu  15-Dec-1988 21:22:31
To:        mason@eddie.mit.edu
Cc:        hplabs!marki@hpiacla.hp.com, misc-security@rutgers.edu
   Date: Tue, 6 Dec 88 15:54:02 EST
   From: mason@eddie.mit.edu (Mark Mason)

   Bob Baldwin (baldwin@xx.lcs.mit.edu) wrote a des package th
   that is (literally) 100 times faster than the unix crypt call.

Bob Baldwin did not write a DES package, nor does the unix crypt call
perform DES encryption.  Unix crypt runs a modified version of DES,
and it is this modification which Bob Baldwin wrote a fast package
for.  Bob's program does a direct translation to the Unix encrypted
string, possible because the Unix call throws away so much
information.  It is this discarding of information that Baldwin's
program exploits.
-----------[000033][next][prev][last][first]----------------------------------------------------
From:      "Jonathan I. Kamens" <jik@athena.mit.edu>  16-DEC-1988  2:53:42
To:        unix-wizards@sem.brl.mil
In article <5598@polya.Stanford.EDU> waters@polya.Stanford.EDU (Jim Waters) writes:

>Actually, I have a 7 digid "secret number," and I believe that 9 is the limit.
>We go to the bank to choose them, so no one else ever sees the number.

Ay, there's the rub....

My bank (BayBanks Boston) allowed me to choose a 7-digit security code
as well.  However, if you watch really closely when typing the 7-digit
code into a BayBanks machine, the screen will flash momentarily after
the fourth digit is entered.

Well, boys and girls, can you guess what that means?  Yes, that's
right, the BayBanks machine is only listening to the first four
digits!  In fact, if you press the enter key after only the first four
digits, the machine merrily accepts your PIN.

Moral of the story: are you *sure* that all seven digits of your PIN
matter to the machine?

(This really has nothing to do with unix.  Sigh.)

  Jonathan Kamens
  MIT Project Athena
-----------[000034][next][prev][last][first]----------------------------------------------------
From:      Phil Hughes <ssc!fyl@teltone.com>  16-DEC-1988  4:57:26
To:        unix-wizards@sem.brl.mil
As dumb as it may seem, here is what really happens on most ATMs (IBM
and Diebold in particular).  It is not, however, the way it works on the
system I worked on.  We figured a reader terminal was smart enough to
figure out what to do next :-)

1. You enter your card and the ATM sends the card number to the network
2. The network tells the ATM to get the PIN
3. The ATM asks for the PIN and waits.  When it gets it, it sends it
   to the network.
4. ...

You get the idea I am sure.  There is a mainframe talking over a serial
line to a bunch of extremely dumb terminals.  The good news is that the
PIN is encrypted at the ATM before it is sent and it is sent in a
different message than the card number.  This means that tapping the
communications line does not give you the necessary information to make a
bogus card and use it in another ATM.
-- 
Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155  (206)FOR-UNIX
    uw-beaver!tikal!ssc!fyl or uunet!pilchuck!ssc!fyl or attmail!ssc!fyl
-----------[000035][next][prev][last][first]----------------------------------------------------
From:      "Richard A. O'Keefe" <ok@quintus.com>  16-DEC-1988  5:00:25
To:        unix-wizards@sem.brl.mil
I had a Versatel card (Bank of America) and my PIN was 10 characters.
-----------[000036][next][prev][last][first]----------------------------------------------------
From:      "Michael J. Chinni, SMCAR_CCS_E" <mchinni@ardec.arpa>  16-DEC-1988 13:50:25
To:        security@pyrite.rutgers.edu
F Y I

From: ted@nmsu.edu
To: unix-wizards@BRL.MIL
Subject: password security

I would let all of this discussion about pin's and password protection
just slide on by, except for the fact that a friend of mine was
apparently a recent victim of an atm fraud.

The situation was that she went to the bank to make a withdrawal and
they said that her account had only $5 in it.  She objected that
according to her records she had over $700 in the account and that she
had not made any withdrawals recently.  The bank claimed that she had
made 5 withdrawals in one day for virtually the entire amount in the
account, leaving only the minimum in the account.  Upon presentation
with a written complaint, the bank checked the camera for the atm and
found that it had been blocked during the time of the withdrawals in
question.

The bank is currently standing pat on the absolute security of the atm
system and is insisting that they have no obligation to disburse any
of the questioned funds.  Combined with the recent discussion on the
net about the errors that have occurred in atm software and with the
fact that some systems store the pin (or the encrypted pin) on the
card, there is considerable doubt in my mind about whether atm's
provide even minimal levels of security.

My questions for the net are:

1) are account and pin numbers really stored on the card in such a way
that a card can be easily forged (please, no secure details, I just
need enough information to believe you).

2) how autonomous are atm machines?

3) to what degree do atm's record transactions.  I know they record
the account number and amount, but do they record erroneous pin
entries, and do they record the pin number that is actually entered?
Is there enough of an audit trail to substantiate a claim of card
forgery? 

4) are there any publicly available accounts of atm fraud, or
breakdowns in atm security? (the bug mentioned on the net recently
would classify, but did the company involved manage to sufficiently
hush up the problem so that it has effectively been pushed into the
apocrypha of computer security?)

If your reply is not suitable for public dissemination, please reply
by email, usmail or phone.  I will or will not summarize to the net
depending on the wishes of individual respondents.  I will honor
requests for anonymity, but obviously, in the current situation, I
would prefer to find experts in the field whom I can cite.

Thank you.

Ted Dunning
Computing Research Laboratory
New Mexico State University
Las Cruces, New Mexico 88003-0001
ted@nmsu.edu
(505) 646-6221
-----------[000037][next][prev][last][first]----------------------------------------------------
From:      "Michael J. Chinni, SMCAR_CCS_E" <mchinni@ardec.arpa>  20-DEC-1988 11:47:18
To:        security@pyrite.rutgers.edu
F Y I

From: Cory Kempf <cory@gloom.uucp>
Subject: Re: password security
Date: 8 Dec 88 18:02:18 GMT
To:       unix-wizards@sem.brl.mil

Has anyone ever noticed that most of the ATM machines that are out
there is the real world (at least in the US) have a vertical keypad?

Does anyone really think that it is possible (without being a contortionist)
to prevent the person behind you from seeing as you type in the PIN?

Can anyone come up with a way to make it *easier* for someone else to see
you type in your PIN?

Retorical question time...

	why do most banks NOT use horizontal keypads (as well as other
	security measures)?

GAK
+C
-- 
Cory Kempf
UUCP: encore.com!gloom!cory
	"...it's a mistake in the making."	-KT
-----------[000038][next][prev][last][first]----------------------------------------------------
From:      "Michael J. Chinni, SMCAR_CCS_E" <mchinni@ardec.arpa>  20-DEC-1988 12:00:49
To:        security@pyrite.rutgers.edu
F Y I
Date: Mon, 12 Dec 88 14:03:20 MST
From: ted@nmsu.edu
To: unix-wizards@BRL.MIL
Subject: pins and passwords

After some checking, (and one very good reference) I have found out
that in the case of ATM's serviced by the CIRRUS network:

1) the pin is verified with the issuing bank on every transaction,
although there appears to be room for CIRRUS to interject a false
verification for testing purposes.

2) all data traffic is encrypted with DES with key distribution by
public-key methods.  Lines that go out of service are automatically
replaced by dial-ups as needed, so that tapping could be done without
much chance of detection, but the cost of attacking a 4.8Kbit DES line
is probably not worth the cost (but since atm's send pins and account
numbers directly over the line, you would completely compromise those
accounts).

3) CIRRUS does not apparently support return of account balance.  This
would explain why moving out of your local area (i.e. local banking
group) causes your balance to disappear from the atm summary.

None of this information indicates that the PIN is NOT stored on the
card, only that atm's do not ever have to take the card's word that
the pin is correct.

The information that I have found does not say anything about the
other major atm transaction networks (cash stream and the plus
system), nor does it really say anything about the atm's themselves.

Many thanks to Mark Schuldenfrei for pointing me at the August 85
issue of CACM which had a case study of CIRRUS (really an interview
with one of the honshos).
-----------[000039][next][prev][last][first]----------------------------------------------------
From:      linnig@skvax1.csc.ti.com  21-Dec-1988  9:55:34
To:        security@tilde.csc.ti.com, linnig@tilde.csc.ti.com
Our systems here use password aging, and it is a damn pain in the @ss.

We have two levels of passwords to get through when we log in via
dialin.  I use two different dialin nodes, and have different passwords
for each.  I have four different accounts on two different machines.

Password aging forces me to have different passwords for all of these
(they age at different rates).  This makes me write all this down
somewhere.  Having my passwords on paper seems a lot less secure than
having one password for the machines and a different password for
the dialins (I grudgingly allow the need for them to be different).

I  can memorize two passwords.  Keeping track of six passwords that
expire from time to time is a hell of a lot harder.

	Mike Linnig
-----------[000040][next][prev][last][first]----------------------------------------------------
From:      John Laws (on UK.MOD.RSRE) <LAWS@rsre.mod.uk>  21-Dec-1988 10:15:35
To:        Bernie Cosell <@relay.mod.uk:cosell@bbn.com>
Cc:        misc-security <@relay.mod.uk:misc-security@uunet.uu.net>
Bernie,
 
'Why should passwords be aged?'  Because in using them they are at
risk of being exposed. It matters not that you do not write them down.
In typing them in your fingers movements may be observed from a distance,
even the sound of your typing can be a great assistance. You may move your
lips to each charater of the password. Equally your password may be
observed as it passes along the wires and computer switches of your
comms path. The longer and/or more frequently you use a password the
greater the risk that it may be exposed. How great that risk is depends
on how often you can be observed ie length of comms lines, ability to
tap lines, how often others are with you when you use it,......
 
John Laws
-----------[000041][next][prev][last][first]----------------------------------------------------
From:      Don Chiasson <G.CHIASSON@xx.drea.dnd.ca>  21-Dec-1988 10:35:34
To:        security@pyrite.rutgers.edu
Cc:        kerchen@iris.ucdavis.edu, G.CHIASSON@xx.drea.dnd.ca
Even searching the source code isn't a guarantee: a really determined 
foe could modify the compiler or run time library so that a virus was
automatically inserted whenever a certain program was compiled or linked
with libraries.

I admit this is getting a bit far out: it is the old statement that a lock
will stop only people who are dumb or not really dishonest.  Even though 
most people will not examine all the source code, the threat that they 
could is enough of a deterrent.  It does point out, though, that anyone
who is *really* concerned about security such as the military or banks
must take incredible precautions.
          Don
-----------[000042][next][prev][last][first]----------------------------------------------------
From:      Ken Wallewein <kenw@noah.arc.cdn>  21-Dec-1988 11:15:42
To:        <security@pyrite.rutgers.edu>
> I find it little more than a damn nuisance ...

  I've seen/heard others make similar comments lately.  It got me thinking.  I 
think I have one good reason.

  Although passwords are intended to be private things, known only to those 
with 'need to know', they tend to get spread around due to various extenuating 
circumstances.  The older a password is, the likelier it is that this has 
happened, and the more people it is likely to have been given to.  Changing 
passwords can be thought of as refreshing their confidentiality.

/kenw
-----------[000043][next][prev][last][first]----------------------------------------------------
From:      Bertil Reinhammar <bertil@isy.liu.se>  21-Dec-1988 11:33:57
To:        security@pyrite.rutgers.edu
Aging passwords are motivated by rejecting the assumption a) by Bernie
Cosell stating that passwords are well chosen. They are *often not* so.

Moreover, people do sometimes lend their passwords to others. Indeed
not recommendable but that's my experience. It is virtually impossible
to find all these sinners. Aging password limit the damage significantly
since most of these indiscretions were supposed to be short term. ( In the
dreadfull case of people persisting on leakage we can only hunt and kill. )

As a comment on Cosell's assumption on well chosen passwords I would
say that the *only* way to get at least reasonable passwords is to
reject certain classes of them. E.g. passwords used recently, passwords
being close to user name, passwords being relatives names etc.

Bertil Reinhammar

Dept. of Electrical Engineering	     ...!uunet!mcvax!enea!rainier!bertil
University of Linkoping, Sweden	     bertil@isy.liu.se
-----------[000044][next][prev][last][first]----------------------------------------------------
From:      Michael Stack  <A01MES1@NIU.BITNET>  21-Dec-1988 11:54:48
To:        Security Topics Discussion List  <SECURITY@pyrite.rutgers.edu>
On the outside chance that there may be subscribers to this list who
have not yet seen it:  there is a fascinating (and long) article in
the Nov 7 issue of The New Yorker on the subject "Voting by Computer".

   If ninety-five million Americans vote on Tuesday, November 8th,
   the decisions expressed by about fifty-two million of them will
   be tabulated according to rules that programmers and operators
   unknown to the public have fed into computers.

   Would {a "logic-and-accuracy public test"} discover, for example,
   a "time bomb" set to start transferring a certain proportion of
   votes from one candidate to another at a certain time, or any
   other programmers' tricks?
   "Of course not," Naegerle said. "It's not a test of the system.
   It's not security!"

I encourage anyone concerned with the problems of computer security
to find and read this article.  It's an eye-opener, even for those
of us acquainted or involved with security issues.

Michael Stack
Northern Illinois University
-----------[000045][next][prev][last][first]----------------------------------------------------
From:      packard!shz@att.att.com (S. Zirin)  22-Dec-1988 10:26:00
To:        security
The California locksmith license law requires locksmiths in the state
to apply for a Locksmith Contractor's license which costs several hundred
dollars annually.

The state contractor's laws do not require other licensed contractor's
(e.g., general, electrical, etc) to use only licensed locksmiths, but do
require licensed locksmiths to use only licensed electrical (etc)
subcontractors.  The law provides for a simple background check, some form
of general contracting test that has precious little to do with
locksmithing, and yet another way for the state to increase their revenue.

The national locksmith's organization, Associated Locksmiths of America
(ALOA), does provide a Proficiency Registration Program (PRP) for locksmiths.
Three levels of proficiency are recognized:

	RL  = Registered Locksmith
	CPL = Certified Professional Locksmith
	CML = Certified Master Locksmith

A locksmith must pass 12 categories on a uniform test to earn the RL
designation, an additional 12 categories to earn CPL and (currently)
an additional 9 to earn CML.  The tests must be taken several times
to ultimately earn the CML designation since there is a limit on the
number of categories tested at one time.  A locksmith with one
of these designations has demonstrated a measurable level of locksmithing
ability and is recognized by the national locksmith organization.

Seth Zirin, Registered Locksmith
att!packard!shz
-----------[000046][next][prev][last][first]----------------------------------------------------
From:      Jim Shaffer <SHAFFERJ@BKNLVMS.BITNET>  22-Dec-1988 10:46:00
To:        security@pyrite.rutgers.edu
The following were found on the Bitnet mailing list Virus-L@LehiIBM1.Bitnet.
Does anyone have any more information on this subject?

VIRUS-L Digest              Monday, 12 Dec 1988         Volume 1 : Issue 42
---------------------------------------------------------------------------

Date: Tue, 6 Dec 88 08:33:44 PST
From: eto@elroy.jpl.nasa.go
Subject: Virus Carried by >2400 baud modem carrier

This memo has been distributed at JPL, but I have not run across
mention of the virus anywhere else:

Subject: New Virus
Sender:  David I NAKAMOTO / JPL/01                Contents: 2.

Part 1.

  TO: JEMS / JPL/01

  Part 2.

  There is a new virus out there that is carried on the subcarrier
  of modems running at 2400 baud or higher.  This virus was
  discovered by someone working in a Telecommunications company in
  Seattle.  From my information, this virus is transmitted during a
  binary file transfer and uses the subcarrier to change registers
  inside your modem to spread the virus around.  That's how it
  replicates.  The virus attaches itself to all incoming binary
  data and infects the host's hard disk, causing random writes to
  sector after sector.  The only apparent cure is to cycle the
  power on the modem or reset the modem registers BY HAND.  To
  prevent the spread of the virus, it is recommended that you use
  300 or 1200 baud only, that you refrain from file transfers, that
  sysops close their file transfer areas, and make backups of your
  hard disk every day in case of infection.

  Four systems are known to be infected with this virus, none on
  lab that I know of.  A possible hardware fix is being developed
  that filters the subcarrier for this virus.

  End of Item 2.

VIRUS-L Digest             Tuesday, 13 Dec 1988         Volume 1 : Issue 44
---------------------------------------------------------------------------

Date:     Mon, 12 Dec 88 22:02 EST
From:     <LACUREJ@IUBACS>
Subject:  more on modem virus

A report of the so-called modem virus was posted to a local BBS here
in Bloomington, Indiana, about a month ago.  I know nothing about
sub-carriers on 2400 baud modems, but I found the idea of a virus
inhabiting the registers of a modem to be so fantastic that I
dismissed the report as nothing more than a prank.  Below is a copy of
the first message in the report, it was followed by a series of
messages as the virus allegedly spread through Washington State.

Jon LaCure
Indiana University
lacurej@iubacs

Report:
----------------------------------------------------------------------------

The following messages were found in the SnoBbs'ers echo

Message #21191 "SnoBbs'ers"
Date: 06-Oct-88 00:57
From: Tom Cooper
To:   All
Subj: Worlds worst virus

I found the following message thread on a Seattle board.  Looks like a really
bad virus is out now.  TC
--------------------------------------------------------------------
#1153 OF 1165 TIME:  TUE 10-04-88  03:17:41 FROM:  MIKE ROCHENLE   TO:  ALL
SUBJ:  Really nasty virus
AREA:  GENERAL (1)
   I've just discovered probably the world's worst computer virus yet.
I had just finished a late night session of BBS'ing and file trading
when I exited Telix 3 and attempted to run pkxarc to unarc the
software I had downloaded.  Next thing I knew my hard disk was seeking
all over and it was apparantly writing random sectors.  Thank god for
strong coffee and a recent backup.  Everything was back to normal, so
I called the BBS again and downloaded a file.  When I went to use ddir
to list the directory, my hard disk was getting trashed agaion.  I
tried Procomm Plus TD and also PC Talk 3.  Same results every time.
Something was up so I hooked up my test equipment and different modems
(I do research and development for a local computer telecommunications
company and have an in-house lab at my disposal).  After another hour
of corrupted hard drives I found what I think is the world's worst
computer virus yet.  The virus distributes itself on the modem
sub-carrier present in all 2400 baud and up modems.  The sub-carrier
is used for ROM and register debugging purposes only, and otherwise
serves no othr purpose.  The virus sets a bit pattern in one of the
internal modem registers, but it seemed to screw up the other
registers on my USR.  A modem that has been "infected" with this virus
will then transmit the virus to other modems that use a subcarrier (I
suppose those who use 300 and 1200 baud modems should be immune).  The
virus then attaches itself to all binary incoming data and infects the
host computer's hard disk.  The only way to get rid of the virus is to
completely reset all the modem registers by hand, but I haven't found
a way to vaccinate a modem against the virus, but there is the
possibility of building a subcarrier filter.  I am calling on a 1200
baud modem to enter this message, and have advised the sysops of the
two other boards (names withheld).  I don't know how this virus
originated, but I'm sure it is the work of someone in the computer
telecommunications field such as myself.  Probably the best thing to
do now is to stick to 1200 baud until we figure this thing out.

                                        Mike RoChenle
-----------[000047][next][prev][last][first]----------------------------------------------------
From:      Luke OConnor <ljpoconnor@violet.waterloo.edu>  22-Dec-1988 21:46:05
To:        misc-security@watmath.waterloo.edu
Seemingly the point is to increase security by extending the length
of the original password.

May I ask

(i)  how are the ESP passwords distributed? 

(ii) why doesn't the system admin. issue users with one password
     that it considers safe?

Luke 
-----------[000048][next][prev][last][first]----------------------------------------------------
From:      Jim Shaffer <SHAFFERJ@BKNLVMS.BITNET>  22-Dec-1988 22:07:23
To:        security@pyrite.rutgers.edu
As far as I know, there is no "Internet version."  Internet users may
subscribe to VIRUS-L@LEHIIBM1.BITNET also.  If you're on the Internet,
send the SUB command as above in the body of a mail message to
LISTSERV@LEHIIBM1.BITNET (or LISTSERV%LEHIIBM1.BITNET@CUNYVM.CUNY.EDU,
as required by your mailer).  For example:

To: LISTSERV@LEHIIBM1.BITNET
Subject:
Enter your message.  Hit control/z to end or control/c to quit:
SUB VIRUS-L Joe User
^Z

To submit articles to the list, mail them to VIRUS-L@LEHIIBM1.BITNET.
-----------[000049][next][prev][last][first]----------------------------------------------------
From:      wcs@skep2.ATT.COM (Bill.Stewart.[ho95c])  22-Dec-1988 22:27:20
To:        clyde!misc-security@gatech.edu
ESPs are typically configurable, used on incoming modem lines
but not on local network or hard-wired connections.
If you have the kind of configuration where you use them,
it's strongly recommended that, for lines that use them, you
always prompt for login, passwd, and ESP, even if the person
gets one of them wrong; otherwise a password-cracker can
break things one at a time.  Some additional guidelines:

	- make your passwd program check that the password
		is different from the ESP (you don't need a
		clear-copy ESP around to do this - just
		crypt with the ESP's salt)
	- think about whether the ESP should be the same as
		your LAN's dialin password, if your LAN has
		a modem pool that supports them.
	- for lines that use the ESP, drop DTR after (say) 3
		bad attempts.

-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
#
#	News.  Don't ask me about News.
-----------[000050][next][prev][last][first]----------------------------------------------------
From:      "W. K. {Bill{ Gorman" <34AEJ7D@CMUVM.BITNET>  23-Dec-1988 15:26:10
To:        Art Zemon <zemon%pernod.DEC@decwrl.dec.com>
All this assumes, of course, that the personnel concerned with any
computer installation are "secure", i.e., safe from coercive
incursions by potential terrorists, infiltrators or saboteurs.
This must be true both on and off the job, or system penetration
by a determined assailant is assured.

Case in point: The various measures, of whatever effectiveness,
surrounding casino employees in some locations.
-----------[000051][next][prev][last][first]----------------------------------------------------
From:      kerchen@iris.ucdavis.edu (Paul Kerchen)  23-Dec-1988 15:46:10
To:        security
>...  The ESP is changed once a month on the systems here
>with it.  Concerns about users having dumb passwords, like
>abc123, are thus reduced...

This system will certainly be more secure than a single password
system, but only if the distribution of the ESP is secure.  If the
sysadmin simply mails the ESP to all the users, this doesn't lock out
those users who are already accessing the facilities illegally.  Of
course, if the sysadmin cannot mail the new ESP, how can she/he
distribute it without a major hassle?  I can envision an
administrative nightmare when trying to distribute the new ESP to all
the users of a 100+ user system (and every month at that!).  Clearly,
there must be a way to securely distribute the ESP (off hand, nothing
comes to mind, but there *must* be a way, right?).
	Another point is that some people really have poor memories.
The ESP is "hard but rememberable" for some but for others it is hard
and *un*rememberable.  Therefore, they write it down and leave it near
their terminal, workstation, etc.  Of course, that is a classic
password problem, but it must be considered as well.
	How about requiring all users to have two different passwords?
Then, even if they choose 'abc123' and 'foobar', they are still more
difficult to crack than either one by itself.  Of course, the benefits
of such a system do not come for free and they may even be outweighed
by the penalties, but I'm just throwing this out for discussion.

Paul Kerchen				| kerchen@iris.ucdavis.edu
-----------[000052][next][prev][last][first]----------------------------------------------------
From:      dab@allspice.lcs.mit.edu  27-Dec-1988  9:46:26
To:        security@pyrite.rutgers.edu
As I understand it, the driving force behind the Electronic Communications
Privacy Act of 1986 was the celluar phone people trying to make it illegal
to listen to cellular telephone frequencies.  This isn't to say that
scramblers wont become popular, but there is a privacy law that applies.

						David Bridgham
-----------[000053][next][prev][last][first]----------------------------------------------------
From:      "JOE ST SAUVER, (503) 686_4394 EXT 36" <JOE@oregon.uoregon.edu>  27-Dec-1988 10:06:26
To:        security@pyrite.rutgers.edu
My understanding is that cellular phone transmissions *are* specifically 
covered by provisions of the Electronic Communications Privacy Act; however,
numerous scanners are available which can be used out of the box to 
receive these frequencies, and many others that have these frequencies
"deleted" are capable of being "fixed" to re-receive them with relatively
trivial modifications.

Joe St Sauver
-----------[000054][next][prev][last][first]----------------------------------------------------
From:      David Flory <HXWY@cornella.cit.cornell.edu>  27-Dec-1988 10:26:26
To:        SECURITY@pyrite.rutgers.edu
Unfortunately it is illegal to receive cellular telephone calls, even though
they are broadcast on "public airwaves" The Electronic Communications Privacy
Act of 1986 (PL99-508) makes the "intentional" (whatever that means)
interception of cellular telephone calls punishable by a $500 fine and/or six
months in jail.  But this is hardly protection (considering how effective
legislation has been with dealing with drug smuggling and the like)

Digital cellular phones will take the analog voice transmission, and convert it
to a digital stream that sounds much like static.  Unfortunately one of my
souces (Dr. Herschel Shosteck) is of the opinion that it wont be implemented
until 1995 (after the Europeans get all their bugs in their digital cellular
phonesout) Also, for several years the systems will support BOTH analog and
digital cellular phones (some frequencies allocated for both) so some cellular
calls will be monitorable for a while.  Also, many markets will not switch to
this technology for quite a while.

djf
-----------[000055][next][prev][last][first]----------------------------------------------------
From:      "W. K. (Bill) Gorman" <34AEJ7D@CMUVM.BITNET>  27-Dec-1988 10:46:26
To:        Security Digest <security@pyrite.rutgers.edu>
I will paraphrase what has been said on the SECURITY-L list:

     This seems to ba a rather obvious hoax, based on the
     theory that if one can't actually spread virii,
     spread rumors of virii. Take a *close* look at
     the signature on this report, i.e., Mike RoChenle,
     which comes out Micro Channel! Gimme a break!
-----------[000056][next][prev][last][first]----------------------------------------------------
From:      "Kenneth R. van Wyk" <LUKEN@ibm1.cc.lehigh.edu>  27-Dec-1988 11:06:26
To:        Security List <security@pyrite.rutgers.edu>
     In a more recent VIRUS-L, I told the readers that the original
     message sent to some bboard by Mike RoChenle (read: Micro Channel)
     was undoubtedly a hoax.  No one has yet come up with any information
     that could substantiate the original report.

     Please, everyone who reads this, assume that the original message
     was a hoax that was forwarded, in good faith, to my VIRUS-L forum.

     Regards,

     Ken van Wyk
     Moderator of VIRUS-L

Kenneth R. van Wyk                   Calvin: Mom, I'm going to grow a LONG
User Services Senior Consultant         beard like the guys in ZZ Top!
Lehigh University Computing Center   Mom: That's great Calvin, do it!
Internet: <luken@Spot.CC.Lehigh.EDU> Calvin: Wow, I thought she'd put up more
BITNET:   <LUKEN@LEHIIBM1>              of a fuss than that!
-----------[000057][next][prev][last][first]----------------------------------------------------
From:      Lynn R Grant <Grant@dockmaster.arpa>  27-Dec-1988 19:46:27
To:        Security@rutgers.edu
Re:  Bernie Cosell's question about the usefulness of password aging:
Password aging minimizes the amount of time that your password is open
to attack.  You may have a well-chosen password, but the longer it is
used, the more likely it is that someone has looked over your shoulder
and seen you enter it, or a line-tapper has read it off your
communication line, or, if you are the type that writes your good
password on a piece of paper, someone has discovered it.

The DoD Password management guideline has another good use of this,
though I have never seen it implemented the way they describe.  Most
systems I have seen will suspend your userid after you enter some number
of incorrect passwords.  You must then get a security administrator to
reset it.  This leaves you open to an easy denial-of-service attack.
And if someone does it to all your security administrators, the whole
shop is in trouble.

To counter this, the DoD guideline suggests making the logon process get
slower after the first few bad passwords are entered for a particular
userid.  That limits how many passwords can be tried in a given length
of time, without leaving you open to the denial-of-service attack.  If
you calculate how many trys it will take on the average to guess your
password, you can set up your password so it expires before then, making
a brute force attack much harder.

            Lynn Grant
-----------[000058][next][prev][last][first]----------------------------------------------------
From:      Stan Horwitz <V4039@TEMPLEVM.BITNET>  27-Dec-1988 20:26:27
To:        <security@pyrite.rutgers.edu>
  Hello.  I was just at what was called an "emergency breifing" on viruses.
The person who conducted the breifing is quite well known for his work in the
area of viruses and computer security.  His name is Dr. Fred Cohen.  This was
a very interesting meeting.   One thing that surprised me is that public domain
software is a smaller source of viruses than proprietary software which comes
in those nice shrink wrapped packages.  Since there is no regulartory agency
whose job it is to certify software and it's potential for harboring viruses
and legitimate bugs, proprietary software becomes just as easy to infect at
the publishing house as any of your own disks.

  It also seems that few unversities or other institutions of higher education
admit to viruses being a major problem.  I don't know of any courses offered
in the subject of computer security and virus detection.  Are there any at
your school?

  A question of relevance to this discussion is along the following lines.  Is
it not the ethical responsibility of our government to establish laws and
guidelines which software must pass before being distributed?  I know that
the government has guidelines for itself about the integrity of software for
it's internal systems.  What about for consumers in general?  We have laws
regulating production of auto's and other consume products and services.  The
same should be true of software.  There should be some sort of committee made
up of individuals from government and private industry who are responsible for
certifying software.  For gosh sakes, even floppy disks must under some sort
of certification!  It's kind of silly to certify the integrety of floppy disks
when we are allowed to purchase disks with software that might very well have
a virus due to the lack of regulations and standards in this area.
-----------[000059][next][prev][last][first]----------------------------------------------------
From:      lypowy@cpsc.ucalgary.ca (grep)  29-Dec-1988  4:26:35
To:        security@rutgers.edu
Also, there is a new list called VALERT-L that is used for reports of
virus infections ONLY (and immediate treatment procedures).  You may
subscribe to this list in the same manner used for VIRUS-L.

Greg Lypowy
University of Calgary Computer Science Department
2500 University Drive N.W.			       lypowy@cpsc.UCalgary.CA
Calgary, Alberta, T2N 1N4	 ...!{ubc-vision,ihnp4}!alberta!calgary!lypowy
-----------[000060][next][prev][last][first]----------------------------------------------------
From:      packard!shz@att.att.com (S. Zirin)  29-Dec-1988  4:46:36
To:        security
>Practically speaking you should be bonded before you offer
>professional security services, to insure your customers.

Bonding and insurance are not the same.  A bond protects your customer
if you are convicted of being dishonest and does not protect against
negligence.  Liability insurance protects a customer against negligence.

>(I disagree with such laws; it is commission of burglary
>that should be the crime, not ownership of a flashlight.)

You must therefore support the right of private individuals to own
guns.  Correct?

Seth Zirin
att!packard!shz
-----------[000061][next][prev][last][first]----------------------------------------------------
From:      compass!worley@ucbvax.berkeley.edu (Dale Worley)  29-Dec-1988  5:06:35
To:        foo@ucbvax.berkeley.edu
Date: 16 Dec 88 08:13:25 PST (Friday)
From: Rodney Hoffman <Hoffman.es@Xerox.com>
Subject: Armed with a keyboard and considered dangerous

The 16 Dec 88 'Los Angeles Times' contains this story (excerpts only):

         EX-COMPUTER WHIZ KID HELD ON NEW FRAUD COUNTS
                         By Kim Murphy
  
  Kevin Mitnick was 17 when he first cracked Pacific Bell's computer 
  system, secretly channeling his computer through a pay phone to 
  alter telephone bills, penetrate other computers and steal $200,000 
  worth of data from a San Francisco corporation.  A Juvenile Court 
  judge at the time sentenced Mitnick to six months in a youth facility....
  
  [After his release,] his probation officer found that her phone had 
  been disconnected and the phone company had no record of it.  A 
  judge's credit record at TRW Inc. was inexplicably altered.  Police 
  computer files on the case were accessed from outside.... Mitnick 
  fled to Israel.  Upon his return, there were new charges filed in 
  Santa Cruz, accusing Mitnick of stealing software under development 
  by Microport Systems, and federal prosecutors have a judgment showing 
  Mitnick was convicted on the charge.  There is, however, no record 
  of the conviction in Sant Cruz's computer files.
  
  On Thursday, Mitnick, now 25, was charged in two new criminal complaints
  accusing him of causing $4 million damage to a DEC computer, stealing 
  a highly secret computer security system and gaining access to 
  unauthorized MCI long-distance codes through university computers 
  in L.A. and England.  
  
  U.S. Magistrate ...took the unusual step of ordering [Mitnick] held 
  without bail, ruling that when armed with a keyboard he posed a danger 
  to the community.  "This thing is so massive, we're just running around 
  trying to figure out what he did," said the prosecutor, an Asst. U.S. 
  Atty.  "This person, we believe, is very, very dangerous, and he needs 
  to be detained and kept away from a computer."  LA and FBI Investigators 
  say they are only now beginning to put together a picture of Mitnick 
  and his alleged high-tech escapades.  "He's several levels above what 
  you would characterize as a computer hacker," said Detective James K. 
  Black, head of the LA Police Dept's computer crime unit.  "He started 
  out with a real driving curiosity for computers that went beyond personal
  computers.... He grew with the technology."
  
  Mitnick is to be arraigned on two counts of computer fraud.  The case 
  is believed to be the first in the nation under a federal law that makes 
  it a crime to gain access to an interstate computer network for criminal
  purposes.... Federal prosecutors also obtained a court order restricting
  Mitnick's telephone calls from jail, fearing he might gain access to a 
  computer over the phone lines....

END OF DOCUMENT