|
|
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
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |