----MESSAGE-BEGIN---- <1988120410182700> From: texbell!rpp386!scsmo1!tim@cs.utexas.edu 5-DEC-1988 17:58:27 To: unix-wizards@sem.brl.mil Subj: [1070] Re: Here's a *BRILLIANT* password idea! >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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120410193200> From: Phil Hughes 5-DEC-1988 17:59:32 To: unix-wizards@sem.brl.mil Subj: [1842] Re: Here's a *BRILLIANT* password idea! (Sarcasm on) 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120422541600> From: Ralph.Hyre@ius3.ius.cs.cmu.edu 6-Dec-1988 6:34:16 To: misc-security@rutgers.edu Subj: [645] [### OLD MSG ###] > 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-)" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120423041700> From: hplabs!marki@hpiacla.hp.com (Mark Ikemoto) 6-Dec-1988 6:44:17 To: misc-security@rutgers.edu Subj: [441] looking for DES code ### OLD MSG ### 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120423141700> From: ames!rochester!kodak!doering@ucbvax.berkeley.edu (Paul Doering) 6-Dec-1988 6:54:17 To: security@pyrite.rutgers.edu Subj: [436] Key management 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120423441700> From: *Hobbit* 6-Dec-1988 7:24:17 To: security@pyrite.rutgers.edu Subj: [472] Administrivia 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* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120605371200> From: jbrown@jato.jpl.nasa.gov (Jordan Brown) 7-Dec-1988 13:17:12 To: misc-security@ames.arc.nasa.gov Subj: [1427] physical security 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120605381500> From: 7-Dec-1988 13:18:15 To: security@pyrite.rutgers.edu Subj: [1460] Securing documentation sets in a public terminal room. [### 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120719012300> From: *Hobbit* 9-Dec-1988 2:41:23 To: security@pyrite.rutgers.edu Subj: [810] Duplicates 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* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120719412300> From: GREENY 9-Dec-1988 3:21:23 To: Subj: [326] Locksmith Licensing 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... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120719512300> From: HXWY@cornella.cit.cornell.edu 9-Dec-1988 3:31:23 To: Subj: [924] Digital Cellular privacy protection 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120720012300> From: desmedt@csd4.milw.wisc.edu (Yvo Desmedt) 9-Dec-1988 3:41:23 To: misc-security@uunet.uu.net Subj: [2224] UWM working group on DATA SECURITY [### OLD MSG ###] 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120803112600> From: Michael Kielsky 9-Dec-1988 10:51:26 To: security@ubvm Subj: [1720] Please send data... [### OLD MSG ###] 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120803212700> From: kerchen@iris.ucdavis.edu 9-Dec-1988 11:01:27 To: Subj: [1481] Virus-writing [### OLD MSG ###] 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120803312700> From: Bernie Cosell 9-Dec-1988 11:11:27 To: misc-security@uunet.uu.net Subj: [1723] Why should passwords be aged? [### OLD MSG ###] 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988120811102400> From: Ron Natalie 9-DEC-1988 18:50:24 To: unix-wizards@sem.brl.mil Subj: [1171] Re: password security 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121115393600> From: Ralph.Hyre@ius3.ius.cs.cmu.edu 12-Dec-1988 23:19:36 To: Chriz@cup.portal.com Subj: [5010] Re: Value-Based Auditing [### OLD MSG ###] 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-)" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121115462500> From: Devon Sean McCullough 12-Dec-1988 23:26:25 To: security@pyrite.rutgers.edu, risks@csl.sri.com Subj: [921] security + freedom = accountability [### OLD MSG ###] 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121202404100> From: mason@eddie.mit.edu (Mark Mason) 13-Dec-1988 10:20:41 To: marki@hpiacla.hp.com@hplabs.uucp, misc-security@rutgers.edu Subj: [225] Re: looking for DES code 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121202504100> From: "R. Gary Cutbill" 13-Dec-1988 10:30:41 To: security@pyrite.rutgers.edu Subj: [428] Dual key encryption systems [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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121203004100> From: lvc@cbnews.att.com (Lawrence V. Cipriani) 13-Dec-1988 10:40:41 To: misc-security@att.att.com Subj: [632] Additional security to login [### OLD MSG ###] 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121206431200> From: "Michael J. Chinni, SMCAR_CCS_E" 13-DEC-1988 14:23:12 To: security@pyrite.rutgers.edu Subj: [983] [Nathaniel Ingersoll: ATM passwords (PINs)] F Y I ----- Forwarded message # 1: From: Nathaniel Ingersoll 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121215004700> From: Joe McMahon 13-Dec-1988 22:40:47 To: security@pyrite.rutgers.edu Subj: [328] Re: Virus-writing 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121215104800> From: zemon%pernod.DEC@decwrl.dec.com (Art Zemon) 13-Dec-1988 22:50:48 To: security@pyrite.rutgers.edu Subj: [728] Re: physical security 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121215204700> From: the terminal of Geoff Goodfellow 13-Dec-1988 23:00:47 To: other_list@ucbvax.berkeley.edu Subj: [759] Sun has tamperproof UNIX, 4.5BSD and secure electronic mail? 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121400422600> From: Phil Springer 15-Dec-1988 8:22:26 To: security@pyrite.rutgers.edu Subj: [399] Re: Securing documentation sets in a public terminal room. 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121401022700> From: (Mike Litchfield 'Flashback') 15-Dec-1988 8:42:27 To: security@pyrite.rutgers.edu Subj: [449] Cellular phones 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121401222700> From: wstef@beta.uucp (W. Gregg Stefancik) 15-Dec-1988 9:02:27 To: security@pyrite.rutgers.edu Subj: [514] Re: Locksmith Licensing 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121412223000> From: gwyn@smoke.brl.mil (Doug Gwyn ) 15-Dec-1988 20:02:30 To: misc-security@uunet.uu.net Subj: [516] Re: Locksmith Licensing >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.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121412423000> From: PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet 15-Dec-1988 20:22:30 To: security%ubvm.bitnet@Hamlet.Bitnet Subj: [634] Re: virus-writing >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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121413023000> From: DAvid James Flory 15-Dec-1988 20:42:30 To: SECURITY@pyrite.rutgers.edu Subj: [776] Digital Cellular phones 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121413223000> 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 Subj: [137] Re: Value-Based Auditing 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121413423100> From: simsong@athena.mit.edu 15-Dec-1988 21:22:31 To: mason@eddie.mit.edu Subj: [626] looking for DES code 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121419134200> From: "Jonathan I. Kamens" 16-DEC-1988 2:53:42 To: unix-wizards@sem.brl.mil Subj: [937] Re: random passwords (was Re: Worm...) 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121421172600> From: Phil Hughes 16-DEC-1988 4:57:26 To: unix-wizards@sem.brl.mil Subj: [998] Re: ATM passwords (PINs) 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121421202500> From: "Richard A. O'Keefe" 16-DEC-1988 5:00:25 To: unix-wizards@sem.brl.mil Subj: [71] Re: random passwords (was Re: Worm...) I had a Versatel card (Bank of America) and my PIN was 10 characters. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121506102500> From: "Michael J. Chinni, SMCAR_CCS_E" 16-DEC-1988 13:50:25 To: security@pyrite.rutgers.edu Subj: [2573] [ted: password security] 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121904071800> From: "Michael J. Chinni, SMCAR_CCS_E" 20-DEC-1988 11:47:18 To: security@pyrite.rutgers.edu Subj: [722] [Cory Kempf: Re: password security] F Y I From: Cory Kempf 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988121904204900> From: "Michael J. Chinni, SMCAR_CCS_E" 20-DEC-1988 12:00:49 To: security@pyrite.rutgers.edu Subj: [1556] [ted: pins and passwords] 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). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122002153400> From: linnig@skvax1.csc.ti.com 21-Dec-1988 9:55:34 To: security@tilde.csc.ti.com, linnig@tilde.csc.ti.com Subj: [756] re: password aging 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122002353500> From: John Laws (on UK.MOD.RSRE) 21-Dec-1988 10:15:35 To: Bernie Cosell <@relay.mod.uk:cosell@bbn.com> Subj: [721] Re: Why should passwords be aged? 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122002553400> From: Don Chiasson 21-Dec-1988 10:35:34 To: security@pyrite.rutgers.edu Subj: [644] Safe code (old msg, was virus-writing) 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122003354200> From: Ken Wallewein 21-Dec-1988 11:15:42 To: Subj: [543] Why should passwords be aged? > 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122003535700> From: Bertil Reinhammar 21-Dec-1988 11:33:57 To: security@pyrite.rutgers.edu Subj: [929] Re: Why should passwords be aged? 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122004144800> From: Michael Stack 21-Dec-1988 11:54:48 To: Security Topics Discussion List Subj: [1013] Voting by Computer 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122102460000> From: packard!shz@att.att.com (S. Zirin) 22-Dec-1988 10:26:00 To: security Subj: [1415] Re: Locksmith Licensing 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122103060000> From: Jim Shaffer 22-Dec-1988 10:46:00 To: security@pyrite.rutgers.edu Subj: [5186] very weird IBM PC virus report 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: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122114060500> From: Luke OConnor 22-Dec-1988 21:46:05 To: misc-security@watmath.waterloo.edu Subj: [254] Re: Additional security to login 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122114272300> From: Jim Shaffer 22-Dec-1988 22:07:23 To: security@pyrite.rutgers.edu Subj: [517] Re: Virus-writing 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122114472000> From: wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) 22-Dec-1988 22:27:20 To: clyde!misc-security@gatech.edu Subj: [916] Re: Additional security to login 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122207461000> From: "W. K. {Bill{ Gorman" <34AEJ7D@CMUVM.BITNET> 23-Dec-1988 15:26:10 To: Art Zemon Subj: [408] Re: physical security 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122208061000> From: kerchen@iris.ucdavis.edu (Paul Kerchen) 23-Dec-1988 15:46:10 To: security Subj: [1504] Re: Additional security to login >... 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122602062600> From: dab@allspice.lcs.mit.edu 27-Dec-1988 9:46:26 To: security@pyrite.rutgers.edu Subj: [315] Cellular phones 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122602262600> From: "JOE ST SAUVER, (503) 686_4394 EXT 36" 27-Dec-1988 10:06:26 To: security@pyrite.rutgers.edu Subj: [404] RE: Cellular phones 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122602462600> From: David Flory 27-Dec-1988 10:26:26 To: SECURITY@pyrite.rutgers.edu Subj: [1028] Digital Cellular Phones 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122603062600> From: "W. K. (Bill) Gorman" <34AEJ7D@CMUVM.BITNET> 27-Dec-1988 10:46:26 To: Security Digest Subj: [333] Re: very weird IBM PC virus report 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! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122603262600> From: "Kenneth R. van Wyk" 27-Dec-1988 11:06:26 To: Security List Subj: [824] Re: very weird IBM PC virus report 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: Calvin: Wow, I thought she'd put up more BITNET: of a fuss than that! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122612062700> From: Lynn R Grant 27-Dec-1988 19:46:27 To: Security@rutgers.edu Subj: [1395] Password Aging 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122612462700> From: Stan Horwitz 27-Dec-1988 20:26:27 To: Subj: [1830] Re: Virus-writing 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122720463500> From: lypowy@cpsc.ucalgary.ca (grep) 29-Dec-1988 4:26:35 To: security@rutgers.edu Subj: [396] Re: Virus-writing 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122721063600> From: packard!shz@att.att.com (S. Zirin) 29-Dec-1988 4:46:36 To: security Subj: [564] Re: Locksmith Licensing >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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988122721263500> From: compass!worley@ucbvax.berkeley.edu (Dale Worley) 29-Dec-1988 5:06:35 To: foo@ucbvax.berkeley.edu Subj: [2859] From risks-forum: Mitnick Date: 16 Dec 88 08:13:25 PST (Friday) From: Rodney Hoffman 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.... ----MESSAGE-END----