From: GOLD::HOBBIT 26-JAN-1988 08:02 To: NET%"security-list",HOBBIT Subj: [1205] Important bit of administrivia A while back I mentioned that red.rutgers.edu, our last 20, is being decomissioned and rolled out in Febrary [Snif!]. I now know which host will serve as a replacement distribution point for the Security list -- this one, aim.rutgers.edu. I've found that PMDF can suck up the entire list in one gulp and not complain, and there's Gnu emacs to do the editing hair with, so it should work out just fine. Thus, this is the official announcement: Security is moving. Please send all further submissions to security@aim.rutgers.edu, and administrative matters to security-request@aim.rutgers.edu. Archives will now live at this site in security.mail, in pseudo-VMS format. To FTP files from here, connect and log in as GUEST with no password. The entry for this list in interest-groups.txt will also eventually change as well. You may see a couple more messages forwarded from Red before the changeover is done. Security@rutgers.edu or rutgers.arpa should also continue to work, but use of this path is discouraged because "rutgers.rutgers.edu" is a small Sun dedicated to lots of mail traffic, and has a perpetual load of over 10 or so. Here's to fast networks and capable mailers, _H* From: (Hugh Pritchard) 9-Jan-1988 14:08:54 To: SECURITY@RED.RUTGERS.EDU Subj: [1559] Reagan Signs Bill Governing Computer Data [Repeated without permission from the business section of _The_Washington_Post_ of Saturday, Jan 9, 1988] [headlined] Reagan Signs Bill Governing Computer Data President Reagan yesterday signed a bill intended to tighten security of computer systems that store nonclassified data such as census, tax and business records. The National Bureau of Standards is to develop programs to protect the machines from being illegally tapped by outsiders. The law overrides a national security directive that Reagan issued in 1984 giving the Pentagon's National Security Agency responsibility for safe- guarding the data. Later, the White House created a new classification of data for protection -- "sensitive but unclassified." The measures led to criticism in Congress that the government was tightening the flow of information and expanding military authority. The new law places responsibility for civilian computer security in civilian hands, but provides for the NSA to give technical advice to the bureau. The law also specifies that nothing in it will be used to restrict disclosures under the Freedom of Information Act. [end of article] /Hugh Pritchard, Systems Programming PRITCHARD@CUA.BITNET The Catholic University of America Computer Center (202) 635-5373 Washington, DC 20064 USA Disclaimer: My views aren't necessarily those of the Pope. From: 11-Jan-1988 12:05:17 To: SECURITY@RED.RUTGERS.EDU Subj: [18894] distribution of sensitive software like DES A recent discussion of DES software distribution on one of the Bitnet mailing lists came to a definitive resolution. Since this seems to be security related, I thought the readers of this list might find it interesting. Selden Ball system@crnlns.bitnet -------------------------------------------- Date: Fri, 8 Jan 88 21:43:42 -0500 From: Rayan Zachariassen Subject: Re: DES To: "Selden E. Ball, Jr." After you read the following article (referred to earlier by Dennis Ferguson), hopefully the DES discussion will disappear from this list. Date: Mon, 26 Oct 87 17:18:36 PST From: John Gilmore Subject: Export control does *NOT* apply to publicly available software. To: info-futures@bu-cs.bu.edu I researched this topic pretty thoroughly last year, by going down to the local Federal Building and wading through the rulebooks in Commerce Dept. library. What prompted me to do it was that I had a PD DES, that I had posted to comp.sources.unix, which a Canadian reader claimed was in violation of export laws. Rich $alz took the info I got and talked with the NSA (US National Security Agency) and some Boston-area cryptographers. The upshot was that NSA never came up with anything that contradicted the rules I found, and Rich posted not only the DES code, for worldwide distribution, but also the "crypt breaker's workbench" that decrypts the ancient Unix "crypt" command. Now, the way things wag with NSA is that if you ask them "Can I do this?" the answer is almost always "No". What you have to say is "Show me the rules that say I can't do this. I have some that say I can." The courts have regularly ruled that the government cannot enforce a policy which is not written down and equally applied to everyone (it's called "secret law"). So if what *is* written down supports you, they are stuck with it. They can't secretly make new laws and tell you later that you broke them. Since everyone else on this topic is shooting off their mouth without having done any research (now we have *two* Canadians who are falsely telling us what the US export law is -- thanks guys!), I figured I'd better post my full references to make it credible. Save this message; if I ever leave the net somebody had better have a copy to shout down the clowns again. From: gnu@hoptoad.uucp (John Gilmore) Subject: There are basically no export controls on public domain information. Date: 3 Oct 86 23:57:06 GMT I got into a hassle last month for posting a DES program to mod.sources because someone claimed that I was breaking the export control law. I spent the afternoon down at the Federal Building and discovered that export policy is in better shape than I thought. Basically, you can export any technical data to any destination if it "has been made generally available to the public in any form". This export is under a "general license" which is available to everyone without any paperwork. So, you should expect to see the DES posting again (it was canceled) and to see Crypt Breaker's Workbench on mod.sources soon. Here are the regs for all you policy hounds: Export Administration Regulations, Part 370.2, Definitions. "General License. A license established by the US Department of Commerce for which no application is required and for which no document is granted or issued. It is available for use by all persons, except those listed in and prohibited by the provisions of Supplement No. 1 to Part 388, and permits export within the provisions thereof as prescribed in the Export Administration Regulations. These general licenses are not applicable to exports under the licensing jurisdiction of agencies other than the Department of Commerce." Part 379.1, Definitions. "... All software is technical data." Part 379.2, Licenses to Export. "Except as provided in Part 370.3(a), an export of technical data must be made under either a US Department of Commerce general license or a validated export license. General licenses GTDA and GTDR apply to specific types of exports of technical data..." Part 379.3, General license GTDA: Technical Data Available to all Destinations. "A General License designated GTDA is hereby established authorizing the export to all destinations of technical data described in 379.3(a), (b), or (c) below: (a) Data Generally Available Data that have been made generally available to the public in any form, including-- (1) Data released orally or visually at open conferences, lectures, trade shows, or other media open to the public; and (2) Publications that may be purchased without restrictions at a nominal cost, or obtained without costs, or are readily available at libraries open to the public. The term "nominal cost" as used in 379.3(a)(2) above, is intended to reflect realistically only the cost of preparing and distributing the publication and not the intrinsic value of the technical data. If the cost is such as to prevent the technical data from being generally available to the public, General License GTDA would not be applicable. (b) Scientific or Educational Data ... (c) Patent Applications ..." ------ (end of first message) John here, talking to info-futures again. Chris Lewis (the first Canadian "expert") tried to pick the above to pieces, so I provided more explanation by private mail, now revealed to the info-futures readership for the first time ever! Date: Sun, 12 Oct 86 16:57:06 PDT From: gnu (John Gilmore) Subject: Re: Export control revisited Chris Lewis is still somewhat concerned about export control. I will try to explain the things he mentioned in his message of 8 October. >> "General License. A license established by the US Department >> of Commerce for which no application is required and for which >> no document is granted or issued. It is available for use by >> all persons, except those listed in and prohibited by the >> provisions of Supplement No. 1 to Part 388, and permits export > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > what is this section about? It lists people who have abused the general license in circumstances where it does not apply (eg shipping Vaxen to Russia). The idea is that you are innocent until proven guilty with regards to general licenses. I looked in the supplement and it was a 3-page list of names and cities. I was not on it. :-) >> within the provisions thereof as prescribed in the Export >> Administration Regulations. These general licenses are not >> applicable to exports under the licensing jurisdiction of agencies >> other than the Department of Commerce." I also got myself a copy of the regulations on cryptographic material export, but I didn't include it in my posting since it did not apply. It's listed under Part 399.1, supplement #1 (the Commodity Control List), "ECCN 1527A". It mentions that computers when combined with cryptographic software are covered under this ECCN, and says "Technical Note: No technical data or software controlled under this ECCN may be exported or reexported under General License GTDR." HOWEVER, we are exporting under General License GTDA, not GTDR, and this is a valid distinction. There is nothing in this ECCN section that precludes shipping cryptographic technical data (e.g. software) under general license GTDA. It also says, "Exporters requesting a VALIDATED LICENSE from the Department of Commerce must provide a statement from the Department of State, Office of Munitions Control, verifying that the equipment intended for export is under the licensing jurisdiction of the Department of Commerce." (emphasis mine) However, we are not requesting a validated license, we are using the general license, so this requirement does not apply either. In summary, I believe that the provisions of ECCN 1527A do not apply to public domain software, and we are OK. (I don't know of any other ECCN sections that apply either.) >> "A General License designated GTDA is hereby established >> authorizing the export to all destinations of technical data ... >> >> (1) Data released orally or visually at open conferences, >> lectures, trade shows, or other media open to the public; and >> >> (2) Publications that may be purchased without restrictions >> at a nominal cost, or obtained without costs, or are readily >> available at libraries open to the public. > 1) Has *this* DES program been formally published before? > 2) Can it legally be? Journals are supposed to be reviewed prior > to publication by one of the security agencies. We're a loophole. > 3) From another tack: can you make a DES program PD? (1) You elided the relevent section of the general license definition. "(a) Data Generally Available: Data the have been made generally available to the public IN ANY FORM, including... (1) and (2)...". (emphasis mine.) If something has been placed into the public domain and its location advertised to the Usenet community, or placed into a publicly accessible bulletin board, or posted to the Usenet, I claim that it has been made generally available to the public. (1) and (2) are not the only ways something can be made available to the public; they are just examples. (2) You can't be expected to know how things work in the U.S., being Canadian, but there is NO requirement that "journals are supposed to be reviewed prior to publication". We have a free press here. They tried to impose something like this and it didn't work. There is a "voluntary" system whereby authors can submit manuscripts to the NSA for review, but you are not even bound by the result -- they can only make suggestions. Mostly this is so they can recommend that you delete certain phrases that might give away what they are working on, and you are supposed to feel patriotic enough to go along. Presumably they could also try to go to court to stop you from publishing, but I don't think that has happened to any paper that has been voluntarily submitted under this program. (They did go to court against the magazine that published the "how to build an atom bomb" article.) You may be confused between mandatory review of journals and the Defense Department's right to review articles by people who they fund. If you are doing government-sponsored research, they can write the contract such that they get to OK any release of information derived from the sponsored research. But if I invent something on my own, without gov't money, I can publish it. (3) Public Domain-ness is a state of ownership. Since you can certainly own a DES program (e.g. AMD owns the copyright of the 8068 DES chip; ATT owns crypt(1)), you can also renounce its ownership and place it into the public domain. >You didn't include anything from 370.3 (or is that a typo?) either. It was not a typo. I don't have a copy of it here, but I don't think it applies to us. It's part of the "General Policy on Exports" section. >If this program were to be published in a technical magazine (presumably >safest in a real journal, not necessarily BYTE), then I'd feel safe >because they've already had approval. BYTE published one or two DES programs >ages ago, but this was before the NBS standard was formalized. Presumably >you could publish *that* program (6502 assembler), but not anything written >since then. I haven't seen a DES program since (though, I don't read all >that many journals...) This objection is covered above -- there is no required government review of publications here, and no government approval is required to publish. >I realize perfectly well that a court challenge on this would probably >find in our favor - as in, is DES in software really DES? But, I want >to ensure that we stay well clear of the shadow (if not the substance) >of the law. Actually, this is not relevant. The export control regs don't mention DES at all. They say "cryptographic equipment...designed to ensure secrecy of communications...or of stored information...and "software"... performing the functions of such cryptographic equipment", and then make a few exemptions for things like simple scrambled voice, video, or fax. >I can't help remembering the export restrictions on crypt (which, I believe >are still in effect *even tho* Enigma has been declassified for years), >AT&T's security package, Motorola and Intel's encryption boards etc. >I remember seeing discussions in trade journals 2-4 years ago about DES >export restrictions, code-breaking discussions, other more recent encryption >methods, but I can't remember where. None of the above stuff is "technical data generally available to the public", so it cannot be exported under the GTDA general license. Note that journal articles like the AT&T Tech Journal one on breaking crypt are generally available to the public, and they are being exported without trouble. Ditto for _Cryptologia_. It *DOES* take an export license to export non-public technical data, e.g. the Unix crypt command (licensed software), encryption boards (hardware, not technical data), etc. I must say that I felt the same way you do about this -- I had a general feeling that exporting this stuff was illegal, even though I thought it should be legal -- until I spent the time to research it. My opinion of the people who wrote US export law has gone up significantly. They really believe that if the US "public" can get it, it is exportable. FYI, here is the definitive story on how the "export restrictions on crypt" came about, from Dennis Ritchie himself. As you can see, no government agency ever said it could not be exported; AT&T and DEC simply decided that applying for an export license was too much trouble. I've also included a message from Gordon Moffett who says that Amdahl is now exporting Unix with the crypt command without trouble. From: dmr@research.UUCP Subject: export controls Date: 18 Sep 84 05:15:46 GMT Posted: Mon Sep 17 22:15:46 1984 As has been said, there is indeed a special "International Edition" of System V that differs from the ordinary system in that it lacks the crypt command, the encrypting features of ed and vi, and the encrypt entry of crypt (3). The crypt entry, which is used for passwords, is there, as is the underlying DES algorithm. Here's how it happened. About a year ago, I got mail from Armando Stettner saying basically, "Do you know of any problems with exporting crypt? Our lawyers [at DEC] are worried about it." I replied that such worries were utterly unfounded for a variety of sensible reasons. Now, as it has turned out, DEC was very justified in worrying about export controls in general; they have recently been fined (I think) $500,000 for the Vaxen that almost got sent to Russia. I conjecture that the earliest stages of this or a similar incident were already in progress and they were trying to be extra careful when they learned about crypt. At any rate, the DEC lawyers communicated their fears to AT&T, and the AT&T lawyers, equally cautious, sought government advice. The problem, you see, is that cryptographic materials are under export control. There is a thing called the Munitions Control Board that worries not only about machine guns going to Libya, but also about the crypt command going to England. In practice, the enforcement is done by the Commerce department. AT&T had a meeting with Commerce, the MCB, and NSA. The upshot was that they decided it would be simplest all around just not to export the crypt command. The gov't would almost certainly have granted the license, but (probably wisely) AT&T decided it wasn't worth the hassle. In technical terms, the situation is ludicrous. The encrypt subroutine is distinguished mainly by the excruciating care I took to make it an exact transcription of the algorithm published in the Federal Register, and by its slowness. NBS, the caretaker of DES standardization, is explicit that software implementations cannot be certified, so in that sense encrypt is not "real" DES. The underlying subroutine is still there, only the simple command that uses it is missing. So there is actually nothing to protect, and even if there were, it's not protected. Nevertheless, in the present situation we officially don't need an export license, whereas with the crypt command we would. In political terms, AT&T probably could have done better. Conservative and careful, they called a big meeting at which no one could possibly have put forward anything but official positions about encryption programs. Private checking with well-placed people in the appropriate agencies might well have done the job. But who knows? Dennis Ritchie ----- In article <3140@amdahl.UUCP> Gordon Moffett writes: Our Corporate legal advisor says that the restrictions against exporting encryption stuff has been lifted. We used to have two UTS's: one with the crypt(3) stuff for domestic customers, and one without export. We no longer distiguish between the two -- we now ship everything to non-USA customers just as to the USA sites. I've already gotten one letter about this, asking me for further confirmation that this is ``true''. First, PLEASE DON'T ASK ME! Talk to *your* companies' legal advisors, or to the Federal Government directly. Second, I am sure we would hear about it from the Federalees if our Corporation were making a mistake .... -- Gordon A. Moffett ...!{ihnp4,seismo,hplabs}!amdahl!gam [Back to Chris's comments: -- gnu] >The definitive answer would be to see whether the current listing of >restricted items includes DES, and in what forms. I don't think excerpts >from a different set of legislation is sufficient to answer this question. >Further, there *may* be a difference between "legislation" and "regulation" >here. DES restriction might *not* be enshrined in legislation, but come >out of some other department's regulatory powers. The second paragraph >I've quoted still leaves that whole question open. I have spent the time researching it, and I think it's OK to export. If you still think differently, please give details of the regulations or laws involved. I'm not interested in "maybes"; I have an answer that came straight from the rule books, and won't be swayed from it by anything less definitive. From: Brendan O'Connor 10-Jan-1988 04:54:05 To: misc-security@RUTGERS.EDU Subj: [698] Re: Security msgs re: SS numbers Is there any way to find out if someone else is using your SSN? I lost my card in Motor Vehicles (one of the worst possible places, it seems to me). Since I know that there's a big trade in SS cards to illegal aliens, I suspect that mine was picked up and sold to somebody. If this is the case, I want to find out if somebody is using it, and what I can do to prevent future trouble for me. UUCP : ...{allegra,ihnp4,cbosgd}!psuvax1!PUCC.BITNET!BMOCONNO ARPA : BMOCONNO@PUCC.PRINCETON.EDU BITNET : BMOCONNO@PUCC.BITNET From: Stan Horwitz 11-Jan-1988 22:43:42 To: Subj: [3035] Re: Security msgs re: student PC labs Has anyone ever considered the cause of software piracy? I have a possible answer. Though no one can condone software piracy I believe that many software publishing houses are their own worst enemies. If software were priced within the reach of your average student, perhaps software piracy on the part of students would decrease. It is not your average student that has over two or three hundred dollars to pay for legal copies of many of the popular software packages used on campuses these days. If these products were more reasonably priced, people, especially students, might not feel as obliged to steel them. My personal opinion is that it takes a lot of nerve to charge such high amounts for any software package for individual (non NETWORK) use. More companies should use Borland as an example and price their software as they do. Also, many software publishers claim large losses due to soft- ware piracy. I honestly wonder about the true losses involved. Many people I know who make thier living programming micro-computers learned their trade in large part due to software they gained illegally. Then when they were out making money off this software, almost all purchased legal copies of the software and now often recommend others to buy these popular software packages. So software companies should consider that while it is true that they are being ripped off, at least their software is getting some publicity and quite often generating dollars for them in the future. One other point should be considered. How much does it cost a typical software publisher to develop a challenging copy protection scheme? Not being a micro-computer user, I do not know the challenges involved in the development of copy protection schemes. I think copy protecting software is silly. It is like putting a dead bolt lock on a paper bag. Why bother considering the cost? I know of many people who can break software without even breaking a sweat. Realistically, copy protection serves only one purpose ... to incovenience legitamate owners of software. Those who wish to subvert copy protection will find a way to do so. Instead of investing time and energy into this silliness, why not just lower the cost of the software or put more effort into perfecting the software? So far, the vast majority of software packages are not very good and could stand a lot more improvement. Please understand, that I DO NOT codone software piracy. Also understand that I do not condone consumer ripoffs via the outrageous prices charged for poorly written, poorly developed, and often inadequate software. Sicerely Stan Horwitz My opinions are my own and I am sure my employer V4039 at TEMPLEVM would not agree with what I have just typed. Temple University Oh well, that's why we have katsup and mustard. Philadelphia, PA From: C. P. Yeske 12-Jan-1988 07:52:53 To: security@RED.RUTGERS.EDU Subj: [554] Re: Copy Protection > They have physically put a Laser "ThumbPrint" on track 15. In fact, this is one of the EASIEST methods of copy protection to defeat. The Laser Thumbprint does not even need the most sophisticated methods of duplication. It is pretty much a gimmick. Also, the vendor can not provide this means of protection for every type of media now available. Curt Yeske Technical Administrator Carnegie Mellon Computing Services From: Will Martin __ AMXAL_RI 12-Jan-1988 12:01:25 To: security@RED.RUTGERS.EDU Subj: [2208] Different type of key I just saw an ad showing a type of key I had never seen before; this might be old hat to many of you, but it's new to me, and I'm wondering if someone could post a note identifying just what kind of key (and lock) this is. The ad is on page 31 of the December '87 issue of Government Product News, a tabloid-sized product-info and advertising freebie magazine aimed at people who buy stuff for state, local, or federal government departments. The ad is actually for a product that uses this key and lock as part of its design -- a fuel-dispensing pump system which can keep track of the fuel used by a particular vehicle in your fleet and prevent unauthorized personnel from stealing fuel. They push this "unique coded key" as a "pick-proof" method of control. Each vehicle has a differently coded key, so the key not only opens the lock, but also identifies which particular key is in use, so the automated inventory-control system can keep track of how much fuel is going into which vehicle (assuming the operator doesn't just fill a can or two extra each time... :-). The company and product is the ITI Tri-Scan Fuel Management System, located in Burlington, MA. (1-800-323-3265, or (617) 272-7233). The ad copy says that the system is used extensively in Europe, so maybe this is a non-US key and lock assembly. Anyway, the key body is a solid tube with scoop-type notches cut or ground out on the top and at least one side. (It appears roughly like a smooth ear of corn with bites taken out here and there.) The picture shows only one side, so I don't know if there are notches on the other side, too. The bottom is smooth. The working part of the key looks to be about 2 1/2 inches long. Anyone recognize this? By the way, there is another locksmithing-oriented item in this issue; on page 14 there is a blurb about a book, LOCKS & LOCKPICKING -- A BASIC GUIDE FOR LAW ENFORCEMENT, SECURITY, AND MILITARY. $10 from R&R Publishing of Hermosa Beach, CA. "Completely revised and updated from a similar manual of 8 years ago." Regards, Will Martin From: Jack Holleran 14-Jan-1988 07:51:15 To: security@RED.RUTGERS.EDU Subj: [3023] A response to a superuser abuse SUMMARY: Two ex-boyfriends use their superuser abilities to delete files necessary to complete coursework and allegedly read private mail. If this happened to my 'SO' or one of my daughters, this is what I would recommend. 1-Document the circumstances in a one page summary and present it to them. 2-Tell them that if the data isn't restored in 2 hours (or some nominally short time), she is prepared to present her summary to the dean (or whoever the powers-to-be are). I choose 2 hours because most superusers or hackers really can't destroy data before copying it somewhere for back-up. If the data has truly been destroyed, then anytime frame is insufficient. But if it exists, the superusers are under pressure (deservedly so!!) to restore the files. (I'm not sure that I wouldn't also do step 3 even if the files are restored.) 3-If the threat doesn't bring the data back, then present the document to the dean. If an apology AND a public policy isn't made, then escalate to the next step. 4-Tell the local school paper and the local town paper. The local school paper will present her side of the argument BEFORE the superusers. In most public presentations of arguments in an unemotional manner (facts, not feelings) will put the superusers in an awkward position. Don't forget to state your experience so the superusers can't show that your inexperience was the cause of the files being lost. 5-The school will probably react if the letter reaches the local area newspaper because most schools "rent" or "lease" a portion of their computing power to local institutions to support workers doing research. As an institution, I would be very displeased if I thought I might lose opportunities because of some immature superusers. The key to success is rational escalation. While the timeframe is late for immediate success, the superusers might learn an ancient phrase "...hell hath no fury...". Now for a management or a corporate point of view... Everybody makes mistakes. In this case, the superusers used poor judgment based on the facts presented. As a manager, I would allow one mistake due to poor judgment or immaturity. BUT THEY HAVE TO BE TOLD THAT THEY HAVE HAD THEIR MISTAKE! The next one would be costly for the superusers. When a superuser ABUSES the customer, it is time to re-evaluate the need for that superuser. The superuser is like the insider in the stockmarket, he hears a lot of information but he is OBLIGED by law not to benefit by it. A superuser can browse through a lot of data but he should do so by invitation only! Also, if you the customer want to be sure your files exist, you may have to take the time yourself to make copies. This is a risk that you have to evaluate. Books have been written on this subject so I won't expand here. Jack Holleran (Holleran@DOCKMASTER.ARPA) From: gwyn@brl_smoke.arpa (Doug Gwyn ) 12-Jan-1988 04:43:37 To: misc-security@uunet.uu.net Subj: [544] Re: Security msgs re: master keys Dennis Mumaugh stated that the government-style S&G padlock is hard to "pick". That's misleading. I manipulated one open in less than ten minutes when I was in the ASA. (We were locked out of a laboratory/ classroom. The instructor had already called someone to come open the lock so I had to lock it back up.) From: Walter Ray Smith 18-Jan-1988 14:50:51 To: security@red.rutgers.edu Subj: [1620] Pay phone thief again This pay phone guy has made the big time: Weekly World News! Right next to a diet ad... Copyright (C) 1988 Weekly World News Reprinted without permission Phone ranger rips off $500,000 from booths FBI dragnet is out for the nickel-&-dime desperado Cops have circulated wanted posters throughout the country for an elusive bandit who they say has ripped open pay phone coin boxes for seven years--and made off with $500,000. The phantom phone bandit has been identified in a fugitive FBI warrant as James Clark, 47, who brazenly uses the name "James Bell" and pays bills with mountains of coins. "He's about as slippery as they get," said Powell Caesar of Ohio Bell in Columbus, Ohio. "He's like a crooked Houdini. There isn't a coin box he can't crack." Clark, a former machinist and die-maker from Ohio, drives a blue van, wears cowboy boots, gold-rimmed glasses and has a ponytail. A special tool allows him to open phone boxes, steal the coins and quietly slip away, say phone officials. He's been doing it for seven years, making $70,000 a year tax free. "Every telephone company from California to New York State would like to nail his hide," said Caesar. "Sooner or later he'll slip up and we'll be waiting." Police believe Clark is in Arizona, California or another western state. He's supposed to be armed with a .38 caliber pistol. The wanted posters offer rewards for information leading to his capture. From: grm+@andrew.cmu.edu (Gretchen Miller) 7-Jan-1988 16:01:34 To: security@aim.rutgers.edu Subj: [1784] Tape-name schemas for large multi-cputype machine room tape libraries. Hi! I'm an operator at Carnegie-Mellon University Computing Services department. I am looking for information on how different organizations physically identify magtapes. We operate several different types of machines here (Dec-20s, VMS vaxes in various sizes, and an IBM 3083 running VM/CMS). The user-ids on these systems has been a standard form: The user's first and last initial followed by single digit number, followed by a single number or letter. Mine, for instance, is GM5B. We maintain a large user and administrative tape library (approximately 3,700 user tapes, and about 1200 administrative tapes). To physically identify each tape, so we can tell if the owner is the person trying to mount a tape, or remove it from the tape library, we place an identifying label on the tape case, which is the name people use when requesting a tape mount. Tape names are 6 characters: the first four are the owner's userid, and the last two are unique identifying numbers or letters. An example of a tape name might be GM5BN2. This worked very well until we got a UNIX system. We now have a system with userids that do not conform to the standard, and we will be acquiring a tape drive for that system soon. Therefore, we want to find out how other sites identify tapes in their tape libraries, and particularly how sites where the number of characters in userids varies identify their tapes. Please mail replies to me, and, I'll post a summary of replies to this bboard. Your help is greatly appreciated. Gretchen Miller Computing Services, Operations Carnegie-Mellon University From: Mike Bell 14-Jan-1988 22:25:34 To: misc-security@ukc.ac.uk Subj: [1245] Re: infinity transmitters > ... however these devices are > pretty much made obsolete by the fact that any of the ESS switches > do not open an audio path untill they receive answer supervision > from the dialed end. None of the electro-mechanical exchanges I've seen connect the audio path until *after* the phone has been picked up... (If there was, you could just put a high pass filter on your line and get free incoming phone calls:-) As I understand it, the mode of operation of such devices is to send the tone immediately *after* the called party has hung up, when an audio path still exists. The infinity transmitter then 'picks up' the phone again to keep the line open. Only when the connection to the subscriber is completely digital will this possibility go away. (but lots of others will arise). So if you get lots of `wrong numbers', and sometimes have difficulty getting a dial tone... Happy Paranoia! -- --------------- UUCP: ...!ukc!camcon!mb | Cambridge Consultants Ltd -- Mike Bell -- or: mb%camcon.uucp | Science Park, Milton Road --------------- Phone: +44 223 358855 | Cambridge CB4 4DW From: Larry Hunter 20-Jan-1988 13:16:53 To: darrell@sdcsvax.ucsd.edu Subj: [6014] Skip Tracing How would you go about finding such a person? The obvious security issue here is perhaps this person does not want to be found. DMV records would be the first place I would look, then perhaps at Social Security. But who has access to these records? First, your specific questions: The friend who left town 10 years ago because the Hell's Angels were after him is easy. He's not really trying to hide from you; try asking his relatives. You can get DMV records pretty easily; they're public. Social security records are very tightly held, but you can try impersonating the subject and asking for "your" records (highly illegal). Almost no one is entitled to look at SS records. Your female friend's marriage certificate (and divorce certificate, if any) is listed in both her maiden and married names (see below). One has very little in terms of legal right to privacy regarding where one lives. Many of the relevant records (land ownership, leases, etc.) are either explicitly public or not protected at all. Most of the measures one might take to "disappear" involve name changes to evade debts and/or false id, both of which are illegal. How hard it is to find someone depends really on how badly they want to be lost. Most people are relatively easy to find. Doing a skip trace (as these investigations are generally called) usually begins with some last known address. You should first check the phone book for a new number or address. The phone books from nearby towns are often helpful. Unlisted numbers at least tell you what town the subject is in, and there are (illegal) ways of finding them out. For $1, the post office will tell you of any active forwarding address for a year after the move. You can also send mail to the last known address with the inscription: "Do not forward: address correction requested" and save yourself 78 cents. The post office is also required to give out the actual address of businesses operating through PO boxes. You can claim that you bought something from the subject's PO box and have not received it; that is usually enough to get the real address of the boxholder. There are also the Polk directories that list names and phone numbers by address. You can call some of the subject's old neighbors, and with a suitable pretext, get potentially useful information about the subject. These directories also indicate numbers that have changed since the last publication, highlighting recent moves. Public records can also be of great assistance. Marriage records are listed by both husband and wife's original names, so find the married name of your old flame is pretty easy. You also might consider looking in local newspapers around the date of the marriage for announcements. These are goldmines of information about friends, addresses, employers, etc. Divorce records are also useful and available. Traffic tickets are a matter of public record, and almost everybody gets them now and then; they have names and addresses on them. Birth and other records may yield a parent's address, which can be very useful in tracking children. Many other city or county records (property tax, fishing licenses, auto or boat registration, etc.) may provide information. Try the several cities and counties around the last known address. Most records can be had be anyone for a small fee. Some clerks may try to tell you you need some official permission to look at files. This is incorrect: local files are a matter of public record and anyone is entitled to look. Private records, such as credit records, Equifax (an insurance investigator) files, medical and banking records and so on may all be accessible to various degrees. It depends on your connections to insiders in those companies or the quality of your pretext in asking. Sometimes a little money helps. If you know the subject's old employer, they may have useful records; they may even be the ones who transferred him to a new city. Interviewing people who may have known the subject before he moved can be very helpful. People in the neighborhood (friends, local grocery store, gardeners, landlords, water company) may have information. Relatives are generally very knowledgable. Lots of local businesses may have forwarding addresses on file for returning deposits or for final bills: phone company, water, gas, electric, landlord, etc. Some people who WANT to disappear use phony mail drops, or "rented" addresses. There are lists of such addresses in a publication called the National Mail Drop Directory. Many of the operators of these services will help a tracer find a true address. Phony ID is pretty easy to come by in the US, but it is a rare case that completely drops out of his old life, never seeing old friends, never talking to family, etc. Lee Lapin's book How to Get Anything on Anybody may provide a useful introduction to running a more difficult investigation. Lapin includes a great idea from a sting operation run by the NY police that caught dozens of fugitives. They sent letters to last known addresses that read as follows: "Congratulations! You have been selected to join FIST TOURS on their inaugural trip to Atlantic City. You and a companion will be our guest in Atlantic City for free. You'll recieve $15 in quarters each and a buffet lunch at the Regency Lounge. The tour is complete with drinks en route and wine and cheese on the return trip. Also a surprise, which is free. This is absolutely free to you and your guest. All we ask is that you fill out the attached reply card. Your trip will be leaving at [a certain place] but you must call to confirm your reservation...." More than fifty felons went to jail for answering that letter ("Also a surprise, which is free"). Happy Hunting! Larry From: "David Madeo drm4@lehigh" 27-JAN-1988 16:14 To: security@aim.rutgers.edu Subj: ?? I was just wondering if anyone noticed that CPP security bought Pinkertons recently. Any comments? This seemed to be the closest digest for the question. David Madeo drm4@lehigh.bitnet zdrmade@vax1.cc.lehigh.edu dmadeo@lehi3b15.UUCP From: Mike Linnig 12-Jan-1988 17:42:23 To: security@RUTGERS.EDU Subj: [838] RE: Misc msgs You might get a passive infared motion sensor and aim it at the drive way. Radio shack sells one for about $60 and they are pretty immune to false alarms. Also you can buy these gadgets hooked to flood lights so that the lights come on when someone enters the yard. btw, driving over a coil does not cause a current to flow. These devices usually use the coil as an inductor. Driving near the coil changes its inductance. The inductor may be part of an oscillator thats freq depends on the inductance. Mike Linnig, Texas Instruments From: "Bob_Hewitt.WBST129"@Xerox.COM 13-Jan-1988 11:09:05 To: security@RED.RUTGERS.EDU Subj: [1349] Re: Security msgs re: home security The best solution I have found for home security at night, is to install an infrared sensor which turns on spotlights and any type of noisemaker you want. I installed one on our deck, near the garden, and it serves two purposes. First, it detects any motion of a warm body (prowler) within its adjustable range, and second, it detects racoons in the summer if the sensitivity is set properly. We have two spotlights and a Sonalert wired to the device so that we are alerted if someone enters the field of detection and the racoons are scared off by the light and high pitched sound of the Sonalert. We were able to have our own corn for the first time in years! The device can be used in the driveway to detect motion of a car or person approaching the house and turn on a light or any other device you want. As I mentioned, the range and sensitivity can be adjusted. It is capable of detecting a car at 100 fet if adjusted for high sensitivity and detects a warm body at 35-50 feet. I bought ours at a local supply house called Hechingers complete with the dual spotlight fixture for $34.95 last year. I'm sure the security houses sell them too, although I didn't check them out. Bob From: NET%"simsong@westend.columbia.edu" 31-JAN-1988 13:02 To: BMOCONNO%pucc.bitnet@rutgers.edu Subj: [361] Security msgs re: SS numbers I suggest that you contact the social security administration, tell them what happened, and ask them if they will issue you another number. Please let me know what happens. I'm currently writing a book about the abuse of social security numbers. Simson L. Garfinkel Graduate School of Journalism Columiba University NY, NY 10027 718-230-0430 From: James Ford 13-Jan-1988 08:48:08 To: security@red.rutgers.edu Subj: [2769] PC Lab security Here at the Univ. of Ala. (in Tuscaloosa), we have a graphics lab in which drawing students use ACAD 2.62 (among other programs). To insure that students won't "borrow" the software, we use the following procedure..... The main program is called PC-Lock. When this program is installed, the user has to supply a password to access the hard disk. IF they decide to boot up with a DOS disk in drive "A", they are unable to access the hard drive. Nortons Adv, PcTools, Explorer, Ultra-Util. and other programs return a "Invalid Drive" message when used. Also, using PC-Lock, CNTL-BRK can be turned off permantly. :-) Then all one has to do is make a simple menu to run after PC-Lock accepts a valid password. Advantages: No multiple sub-directories or "hidden" sub-directories. Easy to write menus (use your favorite "freeware" menu pgm). Only way to get to hard disk is via the passwords..or, you can use DEBUG to format the drive again, (G=C800 and the such, however the data is lost....... :-) You can use a total of 5 passwords (1 administrator and 4 user passwords). ANY key combination is allowed...even backspaces. If a user messes up entering the password, striking ENTER gives him another chance. Disadvantages: You have to make some files "normal" again to edit them (adding new programs to the drive..etc). If a person happens to buy the program, (since he knows the passwords for that class) he can change them. *BUT*, since the errorlevels passed will be the same, he/she/it still can't get to the software. The supervisor can then enter his own password and change all of them to whatever he wants. Unlimited attempts at trying the passwords..however, it would take someone quite some time to figure out a 16 character password. CTRL-ALT-DEL is removed from operation until the correct password is typed in....... I'm not quite sure how PC-Lock works, but if you use FDISK, the hard drive is seen as a non-DOS disk.....maybe it moves the FATs to another part of the disk? Just though ya'll might be interested.... James Ford 1611 Bryant Dr. Apt #3 Tuscaloosa, Ala 35401 (205) 752-4901 From: THE DOCTOR. 18-Jan-1988 22:33:45 To: Subj: [1861] Security in PC labs. Why mess with Floppy Disks at all, use a network. I have been administering a PC network using Novell Netware, and overseeing another for about a year now. All the interesting stuff is on the network file server where it's very convienient to access, and the .EXE files are flagged EXECUTE ONLY. The only thing you can do to an execute only file is execute it and, if you're the system administrator, erase it. All the extra files associated with the program are marked SHARABLE READ ONLY ( with a few annoying exceptions ). If somebody does try to copy a program, they get everything except the .EXE or the .COM file. If they try to corrupt a program, they get a message like "Access Denied." Since all the files are bottled up inside the file server, direct bios calls and the like won't get around the protection. I mentioned annoying exceptions: It seems some application programs read their .EXE files while they're running. If the file is set to Execute Only, they can't read it either, and they usually report "EXE file not found," or something equally unhelpful. Another trick Novell has is not permitting users to see a subdirectory. When they do a DIR, the directory appears empty, and COPY *.* doesn't find any files. In order to copy a piece of software, they would have to explicitly copy each file, and first they would have to find out all the filenames. Unfortunately, some programs use directory search calls to find their files. Novell's security system is quite transparent to well-behaved users, and if carefully administered, very robust. Tom Ruby MSRS002@ECNCDC From: corwin@EDDIE.MIT.EDU 30-JAN-1988 03:13 To: V4039%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU Subj: [1078] re: copy protection for micor software I work for Crystalline Creations, a small company based in Lexington MA, whose sole product at the moment is the worlds strongest go playing program. Our official policy on copy protection is: it's a pain in the ass. Both for us, since we would have to come up with a copy protection scheme, and for our users. And besides, we're constantly improving the programs playing ability. Liscensed users get free upgrades, but if you steal a copy, eventually, you learn to play better than it does, and then what do you do? The policy seems to work fine, since we are making money, or I have gotten paid, at any rate. However, come June, we are releasing a version for the NEC PC, the IBMPC clone on the Japanese market (where we have a much larger potential market than in the US). However, the Japanese insist that the software be copy protected, so we need a scheme. So, does anyone know any reasonable protection schemes, which are at least slightly bothersome to thieves, but not too much of a pain to implement. If not, can anybody suggest where to look? corwin From: david@david.UUCP (David A. Roth) 13-Jan19-88 00:21:26 To: Subj: [569] Burglary alarm company recommendations. I am looking for recommendation of national burglary alarm companies that offer monitoring services including fire detection and water. I am interested in pricing and first-hand experience dealing with them. Please reply directly by e-mail since my site currently does not receive this newsgroup. Thanks in advance. David A. Roth Columbus, Ohio ...ihnp4!david!david ...cbosgd!osu-cis!david!david ...cbosgd!n8emr!david!david ...rutgers!david!david From: NET%"RPollard.ElSegundo@Xerox.COM" 1-FEB-1988 20:51 To: HOBBIT@aim.rutgers.edu Subj: [479] Re: Security digest Some of the recent talk of buggung and electronic survailance got me to wondering something. I live in a condo and as such share common walls with neighbors. (Neighbors that I don't really know very well.) If one of my neighbors wanted to "bug" my unit for some reason what sort of methods would likely be employed. It occurred to me that it might not only be audio but visual bugging as well. Also, how would one go about detecting such devices? Thanks for any info. Rich From: _*Hobbit* 3-FEB-1988 21:39 To: HOBBIT@aim.rutgers.edu Subj: superuser abuse Somehow I don't think going to town papers would do jack. Media people wouldn't understand what you were driving at, and would probably make a complete botch of the resultant story that would make *everybody* look bad, on both sides of the battle. _H* From: DORFMAN@ECLA.USC.EDU 5-FEB-1988 12:34 To: security@aim.rutgers.edu Subj: [606] Computer Security Introductory Text The Data Systems Engineering organization at Lockheed in Sunnyvale, Calif., is establishing a small technical library, and we would like to obtain one book on Computer Security. The book would be used as a technical introduction for software professionals with no specific background in computer security. We would appreciate any recommendations that readers of the Security List can provide. If there is sufficient response, I will post a summary to the List. Merlin Dorfman ARPA: DORFMAN@ECLA.USC.EDU UUCP: ...ucbvax!sun!sunncal!leadsv!laic!cosmos!galaxy::dorfman 408-756-8204 From: andrew@frip.gwd.tek.com (Andrew Klossner) 10-FEB-1988 09:51 To: misc-security@tektronix.tek.com Subj: [1064] Submission for misc-security "Is there any way to find out if someone else is using your SSN?" You can query the Social Security Administration for a statement of your earnings, which will reflect FICA tax payments for your account. If there are extra payments, you can followup to find their source. >From a RISKS article by Lance P. Keigwin (lance@ubvax.UUCP): "You can only get a complete record by seeing a Service or Claims representative, who must complete an SSA-450 for transmission to HQ in Baltimore. Insist on a photocopy of it when it arrives. Be troublesome, if necessary." -=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP] (andrew%tekecs.tek.com@relay.cs.net) [ARPA] From: 10-FEB-1988 09:51 To: Subj: [121] Info re disaster planning I am looking for information on disaster planning for University computer Centers. I will appreciate any help. Thanks From: David S. Hayes 10-FEB-1988 09:51 To: uunet!misc-security@uunet.uu.net Subj: [764] locksmithing courses I'm interested in locks just out of curiosity. (I don't have my cat anymore.) I'd like to take a locksmithing course, but I don't know how to go about selecting one. I'd like a correspondence course. It doesn't have to cover every last technical innovation invented since last Tuesday, but should be reasonably current. Mostly I'm interested in things like car and house locks, not the high-security electronic stuff. It must be relatively inexpensive, since this is only a hobby. Finally, it must provide whatever certifications are necessary to get the basic tools of the trade. Recommendations gratefully accepted. Thanks. From: dnelson@ddsw1.UUCP (Douglas Nelson) 10-FEB-1988 09:51 To: codas!misc-security@rutgers.edu Subj: [1836] Concerning tracking down the useage of your Social Security number, I once worked for a company that subscribed to Trans-Union credit checking. This company offered you the ability to do a social security number trace, where any occurances of your social security number in the country that would occur from things even as small as a declined credit application would show. This command was merely typing in 'TRCE xxxyyzzzz' and it would come back with all the occurances of that SS number, and the applicants and/or account holders, as well as their current and previous addresses. I distinctly remember several times doing this (we did it in order to see if the individual had credit at another address, etc) and having more than one person show up under the identical SS number, and although occasionally it may have been due to a mis-typing on the part of the data entry person originally, most of the time it belonged to an addressee somewhere in Florida or California or New York with a seemingly foreign name. All I could suggest is that you go to your local credit checking agency and see if they use Trans-Union credit checking or a compatible one that would offer such a service. I suppose it is pretty common knowledge that the first three digits of your Social Security number indicate where you were born. We also used that in order to verify job applications when doing a background check. ------------------ Douglas Nelson dnelson@ddsw1.UUCP ------------------ From: mcvax!ethz!prl@uunet.uu.net (Peter Lamb) 10-FEB-1988 09:51 To: cernvax!misc-security@uunet.uu.net Subj: [779] Re: distribution of sensitive software like DES Just to show that these things tend not to work anyway; on a U**x box near me there is a copy of the Unix `secretmail' stuff (public key encrypted local mail). The manual entry has a big notice saying `not to be exported'. The same company does not export `crypt'. Of course this is irrelevant, since we have licensed Unix source which predates the ban; it includes both crypt and secretmail. I think the argument used by DEC etc, that it would cost too much is a bit odd. Have they ever calculated how much it costs to make two different distributions of their software? And not-for-export software gets distributed anyway.... -- Peter Lamb uucp: seismo!mcvax!ethz!prl eunet: prl@ethz.uucp Tel: +411 256 5241 Institute for Integrated Systems ETH-Zentrum, 8092 Zurich From: decvax!decwrl!sun!seismo!esosun!dcdwest!sarge@ucbvax.Berkeley.EDU 9-FEB-1988 19:17 To: AIM.RUTGERS.EDU!HOBBIT@sundc Subj: [520] I am a security officer for CPP Security Services here in San Diego and have been for over 8 years now. California Plant Protection (in Ca.) or CPP Security Services for other parts of the country is a well organized company and they even pay a liveable wage. When CPP bought Pinkerton Security you can believe that CPP Paid a Hefty Sum. Most of the CPP Area Managers act half way human to the guards. I may be a contracted Security Officer but I'm a professional one. Bob Heddles From: Nick Papadakis 8-FEB-1988 13:03 To: ROMKEY@XX.LCS.MIT.EDU Subj: [619] immunological/antibody program From: Philip A. Earnhardt A display ad on Page 10 of today's (7 feb 88) Sunday New York Times: !!! ANTI-VIRUS PROGRAM !!! NOW AVAILABLE. Anti Virus diskette that locates and eliminates unwante software viruses once and for all. $99.00 each. To place your order.... Technology recapitulates phylogeny! A neat way to implement this would be as a 'benificent' virus that runs around zapping any *other* viruses it finds. But who watches the watchmen, eh? Maybe this $99 'immune system' has AIDS ... More evidence that security is simply a waste of time. - nic From: Daniel Keizer 10-FEB-1988 14:41 To: security@aim.rutgers.edu Subj: [1999] RE: Secure labs with PC-LOCK An interesting note on PC-lock was recently posted. I have seen PC-LOCK in use and am quite impressed with the actual design of the program ... can't remember the person who wrote this fine program though. The program gives you enough security that only someone who understands hard disks and the PC computer will be able to break it. There is no way that I know of to break the security by brute force, although there is a very easy way to by-pass it. I am not sure if I should be revealing this way or not, but security by non-disclosure is no security at all. PC-LOCK writes a new master hard disk boot block, just like FDISK. But this one has its own boot code. As well, you might notice that when you boot from a floppy, the hard disk light goes on for a second ... dos is reading the hard disk to try and determine if it is valid. It knows if it is valid by modifying the last two bytes (ID field) from 55 AA (hex) and it simply zeroes out one of those bytes. So, booting from a floppy won't recognize a hard disk in this fashion (invalid drive spec ...) but when booting off of the hard disk itself, PC-LOCK takes hold and recognizes itself, and boots up fine with the CLEANDSK.DRV device driver. (which is where the password stuff is.) The actual driver program itself and the installation programs are *VERY* well protected. The author must be commended with his attempts to hide his code (self-decrypting). The simple way to by-pass this is to use FDISK to reclaim the whole disk back again. You would have to get to that point by some other means. Experimentation is fun. The person un-protecting the disk in this means would have to know the partition boundaries in order to make it work, but PC-LOCK does not (as far as I can determine) work with more than one partition (such as a UNIX/MINIX partition). Nor would it work with a friends' AT&T 6300. Not sure why. Anyone else have any experiences with PC-LOCK? Dan Keizer BUSU@CC.UOFM.CDN BUSU@UOFMCC.BITNET From: simsong@amsterdam.columbia.edu 11-FEB-1988 02:10 To: MSRS002%ECNCDC.BITNET@cunyvm.cuny.edu Subj: [673] Security in PC labs. Cc: security@aim.rutgers.edu Questions about the Novell Netware software: 1. What prevents the user from taking a snap-shot of memory and making their own .EXE or .COM? 2. For that matter, what pervents them from using the DOS LOAD_PROGRAM call, (without the execute-program version), to get a perfect image? (This is how one program loads in overlays. I do it all the time.) 3. I gather that the way EXECUTE ONLY works is that Novel has patched DOS so that when it wants to read the blocks of an EXECUTE ONLY program to load it into memory, it uses an undocumented BIOS READ DISK BLOCK function. Or would that be too simple? ................................................................simson From: sri_spam!csib!lgold@rutgers.edu 11-FEB-1988 18:08 To: security@rutgers.edu Subj: [984] Re: copy protection for micro software The version of Empire for the Atari ST has a cute protection scheme that looks relatively easy to implement. In order to run the program, you have to have a copy of the manual. Why? The program asks you to type in "the Nth word on page M" where N and M are two randomly selected numbers. If you don't have the manual in front of you, you can't type the word in and can't run the program! It doesn't necessarily stop people from copying the program, but it DOES make it more of a pain-in-the-you-know-what to do so. --Lynn From: GOLD::HOBBIT 26-FEB-1988 08:54 To: NET%"security-list",HOBBIT Subj: [1298] Summary of msgs re: Intro to Computer Security [Here are the responses collected so far. _H*] Date: Sun, 14 Feb 88 14:54:56 EST From: ncoast!smith%ncoast@mandrill.CES.CWRU.Edu Subject: Computer Security Introductory Text May I suggest _UNIX_System_Security_ by Patrick H. Wood & Stephen G. Kochan published by Hayden Books (Division of SAMS) ISBN: 0-8104-6267-2 $34.95 Retail. -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Tue, 16 Feb 88 11:04:06 EST From: "Michael J. Chinni, SMCAR-CCS-E" Subject: Re: Computer Security Introductory Text Try contacting the following: Computer Security Institute 43 Boston Post Road Northborough, Massachusetts, 01532 (617)845-5050 They put out a "Computer Security Handbook" that I have found very interesting from a novices point-of-view. Mike Chinni -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Tue, 16 Feb 88 13:44:50 -0500 From: edelheit%community-chest.mitre.org@gateway.mitre.org Subject: Re: Computer Security Introductory Text I would suggest that you look at "Tutorial: Computer and Network Security" by Abrams and Podell. It is published by IEEE Computer Society Press (order # 756). It can be ordered by calling 1-800-CSBOOKS. Jeff Edelheit (edelheit@gateway.mitre.org) The MITRE Corporation 7525 Colshire Drive McLean, VA 22102 (703) 883-7586 From: Bill Sommerfeld 13-FEB-1988 15:52 To: "THE DOCTOR." Subj: [1410] Re: Security in PC labs. ... the .EXE files are flagged EXECUTE ONLY. The only thing you can do to an execute only file is execute it and, if you're the system administrator, erase it. All the extra files associated with the program are marked SHARABLE READ ONLY ( with a few annoying exceptions ). Unless the programs wind up executing on the server (which doesn't appear to be the case), there is no significant security difference between labelling a file execute-only, and labelling it read-only; the client has to be able to read the file across the network in order to copy it into its address space to execute it. If the students can boot an arbitrary floppy on the PC's, or if they can patch the operating system, they can get around this pseudo-security on the client side. This system may very well make it harder to steal the software if you don't have source or symbol tables on the network code and the protocols themselves are unpublished. However, if you think this is ``secure'', you're wrong. Access control does no good on a network unless it is enforced on the server end; the distinction between `read executable' and `read' is enforced by the _client_, not the server. - Bill From: hp_sdd!dag@hp_lsd.hp.com 16-FEB-1988 18:08 To: sdcsvax!misc-security@rutgers.edu Subj: [361] Re: re: copy protection for micro software Tie the operation of the software to a piece of hardware. i.e., send a piece of HW that can be read by the PC. Perhaps it has to be inserted in the joystick loop, perhaps it has to be plugged on to an RS-232 port, etc. The software can be copied and pirated, but without the right piece of HW on the system too, it won't run. From: "John O. Rutemiller" 18-FEB-1988 08:46 To: security@aim.rutgers.edu Subj: [155] re: Driveway Metal Detectors In the February 1988 issue of Popular Science there is an artical on page 117 which talks about driveway detectors and lists some different sources. John From: "Robert W. Baldwin" 19-FEB-1988 02:38 To: security@rutgers.edu Subj: [897] police radar Does anyone have infomation about the capabilities and limitations of police radars for speed checking. I'm looking for both technical limitations of the devices and for procedural limitations that are necessary to make a ticket stand up in court. I'm aware that many state courts do not accept radar evidence and others (like california) only allow it to be used in a few places. One technical limitation seems to be that the device must have a stable speed reading before it displays a speed for the officer. One two occassions I've seen a car suddenly slow down, and avoid getting a ticket. On another occassion I saw two cars zoom past a police car, neither was stopped, but when a single car passed doing the same speed, it was pulled over. This seems to be a procedural limitation to avoid the defense of a driver claiming that the other car was speeding. Comments? --Bob From: Clement Taylor 22-FEB-1988 12:36 To: Security Conference Subj: [665] BITNET Security Gentlemen, I am the BITNET coordinator at Exxon Engineering. Does a compendium exist of recent transmissions on this conference? I am particularly interested is what is being discussed regarding "viruses" CHRISTMAS EXECs etc. I may be called upon to justify our continued participation in BITNET in light of these threats. Thank you for your assistance. Regards, Clem Taylor Exxon Research & Engineering 180 Park Avenue Florham Park, New Jersey 07922 (201) 765-3338 [Moderator note: Archives exist here at aim.rutgers.edu, but I don't recall ever having seen anything about IBM-machine viruses. Do some of you Bitnet folks have more info? _H*] From: Wm Brown III 25-FEB-1988 17:07 To: "David S. Hayes" Subj: [2498] locksmithing courses I researched this several years ago and found that most of the commercially available courses aren't worth your time and money unless you actually wish to go into business as a locksmith. Since most 'serious' students are being funded by the VA or some other government program, the courses are geared to absorb the exact number of dollars provided by these agencies and include a large amount of information necessary for someone operating a business, but of no interest to anyone else -- things like how to install locks or fix door closer mechanisms. Most of these programs are also aimed at students with very limited educations, and you will probably find them pretty boring. The only way to learn about locks is to work with them. Instead of spending your money on a course, go out and buy a sample of each major type. Take them apart, put them back together, and play with them until you understand and appreciate the subtleties of their designs. You may wind up destroying a few, but in doing so you will learn a lot. There are a few good books on the subject. One is published by TAB books, (they also print a lot of basic electronics and computer introductory texts). Some of the others, including some pretty sophistocated references which were considered secret within the trade ten years ago, may now be bought from some of the companies which sell books on survival, weapons, Ninja-whatever, and other sleazy topics. Many of these advertise in gun mags or (I am told) in some of the weekly tabloids seen at the supermarket. The hardest part, by far, will be obtaining specialized tools such as picks and raw materials like key blanks. If you can find a local locksmith who is willing to trust you, that's the best bet. Otherwise, you may have to pay scalper prices through the mail-order sleaze merchants mentioned above. I would start by asking the 'smith to sell you a Pippin file, which you will need anyway. This is a fairly innocuous instruent, and asking for one may just get your foot in the door. Finally, beware of legal problems. In many places, possession of locksmithing tools is grounds for arrest. The burden will be on you to prove that you are really a serious hobbyist! From: goldstein%star.DEC@src.dec.com 26-FEB-1988 11:14 To: SECURITY@aim.rutgers.edu Subj: [14996] Export of "public domain" crypto software [Moderator note: Thanx also to Chris Kent for forwarding this as well; one outgoing copy is plenty... _H*] I read John Gilmore's mail, forwarded to SECURITY a few months ago, with great interest. I wondered, could our export control laws really be as rational as he claims? So I forwarded the memo to our company export lawyers for comment. I am not really surprised at the outcome: we are not so lucky. John's arguments are incorrect, and export of all crypto software is in fact strictly regulated. I attach the gory details I got back from our lawyers. There have been some other comments recently to the effect of "why bother regulating crypto export when it slips out anyway with public comain software". There are a couple of things to be said: (1) Like it or not, it's the law. Large corporations like DEC operate at a high level of visibility, and must hew to the straight and narrow far more than garage shops and private individuals. If we screw up legally, you can guarantee the government will be on our case pronto. We still have painful memories of the 782 fiasco a couple of years ago. That and related events at the time cost the company $1.5M to get its export license back, when (a) the export controls in question were Dept. of Commerce, and (b) it was far less clear that we had actually violated any laws. (2) Given our general climate of free trade and communication, it is inevitable that some crypto software will slip past the export controls. The government does not have the resources to go after each individual violation. However, you can rest assured that repeated violators will be (and have been) brought on the carpet. Keep in mind that the "public" networks are to a large extent funded with government money. If a pattern of export violations develops on these networks, their very existence could be jeopardized. Andy Goldstein VMS Development ******************************** _____________________________ | | | | | | | | | d | i | g | i | t | a | l | I n t e r o f f i c e M e m o |___|___|___|___|___|___|___| TO: "TO" Distribution DATE: 16 February 1988 FROM: Tom Ehrgood CC: "CC" Distribution DEPT: Corporate Law TEL: (202) 383-5698 LOC: WNP SUBJECT: Controls Over The Export Of Cryptographic Software This memo answers points made in an October 27, 1987, memo by John Gilmore, which we received on January 28th. Gilmore's memo, which I am separately forwarding, argues that the posting of cryptographic software to certain widely available bulletin boards places that software in the "public domain," with the consequence that export licenses are not required for the exports of that software. Gilmore's analysis has been given wide distribution on various networks. Gilmore is mistaken in his analysis and in his conclusion. Given the high national security sensitivity of cryptography, generally, and DES encryption, specifically, it is important to set the record straight. The fundamental points that Gilmore gets wrong are: o Exports of cryptographic software are governed by the State Department's International Traffic in Arms Regulations ("ITAR"), not by the Commerce Department's Export Administration Regulations ("EAR"). Exports would be governed by Commerce's EAR only if State waived jurisdiction. o Although State Department regulations contain a "public domain" exemption for technical data, cryptographic software does not qualify as "technical data," and thus the "public domain" exemption does not apply. A legal analysis follows. DISCUSSION I. State Department Control Over Cryptographic Software ---------------------------------------------------- A. Cryptographic software is a "defense article" --------------------------------------------- Section 38 of the Arms Export Control Act authorizes the President to control the export and import of "defense articles" and "defense services." This statutory authority -- which includes the authority to to "designate those items which shall be considered as defense articles and defense services" -- was delegated to the Department of State, which in turn has implemented the statutory authority through promulgation of the International Traffic in Arms Regulations ("ITAR"), 22 C.F.R. Subch. M. The term "defense article" is defined in section 120.7 of ITAR to mean "any item designated in section 121.1," which contains the United States Munitions List. Category XIII of the Munitions List provides in paragraph (b) as follows: Speech scramblers, privacy devices, CRYPTOGRAPHIC DEVICES AND SOFTWARE (ENCODING AND DECODING), and components specifically designed or modified therefore, ancillary equipment, and protective apparatus specifically designed or modified for such devices, components, and equipment. (Emphasis added.) Since "cryptographic . . . software" is thus included on the United States Munitions List, it is a "defense article" subject to the State Department's ITAR controls over exports of such articles. At certain low thresholds, it may not be clear whether software containing certain encryption functionality in a technical sense constitutes "cryptographic software" within the meaning of Category XIII(b), above. Section 120.5 of ITAR establishes a procedure under which "[t]he Office of Munitions Control will provide, upon written request, a determination on whether a particular article is included on the United States Munitions List." Questionable cases may be resolved by following this procedure. Assuming that encryption software does constitute "cryptographic software" within the meaning of Category XIII(b), State Department export licenses are required, REGARDLESS OF WHETHER THE ENCRYPTION IS BASED ON THE DES ALGORITHM. The relevance of DES vs. non-DES lies in the ease with which licenses can be obtained, not in whether licenses are required. B. The State Department's "public domain" exemption does not apply to exports of "defense articles." --------------------------------------------------------- Part 123 of ITAR contains rules governing export licenses for the export of "defense articles." The basic rule is stated in Section 123.1(a) as follows: Any person who intends to export a defense article must obtain a license from the Office of Munitions Control prior to the export unless the export qualifies for an exemption under the provisions of this Subchapter. Part 123 sets forth a number of exemptions in sections 123.16 through 123.22. None is these exemptions covers the posting of cryptographic software on a bulletin board. Section 126.5 exempts from the licensing requirement any exports of unclassified defense articles or unclassified technical data to Canada for end-use in Canada or return to the United States. This exemption would be potentially applicable only if the ONLY exports that might take place as a result of the bulletin board posting were exports to Canada. (See section 120.10, which defines "export" to include "[s]ending or taking defense articles outside the United States in any manner.") In any event, care would have to be taken to ensure that applicable documentation requirements are met to invoke properly the exemption. Part 125 of ITAR contains rules governing exports of technical data. Section 125.1(a) provides: The export controls of this part apply to the export of technical data . . . . Information which is in the "public domain" (see section 120.18) is not subject to the controls of this chapter. Section 120.18 defines "public domain" as follows: "Public domain" means information which is published AND WHICH IS GENERALLY ACCESSIBLE TO THE PUBLIC: (a) Through sales at newstands and bookstores; (b) Through subscriptions which are available without restriction to any individual who desires to obtain or purchase the published information; (c) Through second class mailing privileges granted by the U.S. Government; or, (d) At libraries open to the public. (Emphasis added.) This definition is a much more restrictive one than the analogous Commerce GTDA regulation analyzed by Gilmore: a bulletin board posting of information would not fall within ITAR's public domain unless that posting qualified under paragraphs (a)-(d) of section 120.18. A posting would not appear to so qualify. (This memo does not take any position on whether bulletin board posting would place Commerce-controlled technical data into Commerce's public domain; specific information about the technical data and the bulletin board would be necessary.) Regardless of how the ITAR "public domain" applies to bulletin board postings in general, the posting of cryptographic software cannot fall within the "public domain" provision, because, per section 125.1(a) above, the "public domain" provision applies to "technical data." Cryptographic software -- a "defense article" (see Section I.A above) -- does not constitute "technical data" under ITAR. More on that below. The term "technical data" is defined in section 120.21 as follows: "Technical data" means for purposes of this subchapter: (a) Classified information relating to defense articles and defense services; (b) Information covered by an invention secrecy order; (c) Information which is directly related to the design, engineering, development, production, processing, manufacture, use, operation, overhaul, repair, maintenance, modification, or reconstruction of defense articles. This includes, for example, information in the form of blueprints, drawings, photographs, plans, instructions, computer software and documentation. This also includes information which advances that state of the art of articles on the U.S. Munitions List. This does not include information concerning general scientific, mathematical or engineering principles. "Technical data" per this definition thus consists either of information "relating to defense articles" (par. (a)) or information directly related to the doing of things to "defense articles" (par. (c)). [Paragraph (c) is not relevant here.] Since cryptographic software is itself a "defense article," it cannot simultaneously qualify as "technical data." Moreover, different ITAR Parts govern exports of "defense articles" (Part 123) and exports of "technical data" (Part 125). Of course, not all encryption materials (DES or otherwise) necessarily take the form of "cryptographic software" controlled under Category XIII(b) of the Munitions List. Non-Category XIII(b) materials will qualify as "technical data" within the meaning of the section 120.21 and will thus be eligible for "public domain" treatment if the specific ITAR conditions apply. II. Commerce Department Controls Over Cryptographic Software -------------------------------------------------------- Section 370.10 of Commerce's Export Administration Regulations state the general rule that Commerce does not control exports of State Department-controlled items. Specifically, subsection (a) provides: (a) U.S. Munitions List. Regulations administered by the Office of Munitions Control, U.S. Department of State, Washington, D.C. 20520, govern the export of defense articles and defense services on the U.S. Munitions List. Thus, Gilmore's statement that the State Department's concerns about exports of crypt commands are "enforced" by Commerce is wrong. What has complicated the picture and confused Gilmore is that Commerce's Commodity Control List -- Commerce's counterpart to the United States Munitions List -- contains a category 1527A covering "cryptographic equipment . . . and software controlling or performing the function of such cryptographic equipment." Gilmore identified this regulatory control provision, but he misinterpreted it. Gilmore found the note in category 1527A, which states that Exporters requesting a validated license from the Department of Commerce must provide a statement from the Department of State, Office of Munitions Control, verifying that the equipment intended for export is under the licensing jurisdiction of the Department of Commerce. Gilmore mistakingly says, however, that "we are not requesting a validated license, we are using the general license, so this requirement does not apply . . . ." Gilmore missed the 1527A heading: "Validated License Required: Country Groups QSTVWYZ." These designated country groups comprise every country in the world except Canada. Consequently, a validated license issued by Commerce is required in order to make any export of 1527A-controlled cryptographic software. And because a validated license is required, exporters seeking such a license must, per the note quoted above, submit a State Department statement "verifying" that Commerce has jurisidiction over that cryptographic software. Such a statement would generally take the form of an ITAR section 120.5 commodity jurisdication determination. In sum, unless the State Department has issued a statement verifying Commerce jurisdiction over the cryptographic software that Gilmore has in mind, Commerce's controls do not apply. And without such a statement, Gilmore's analysis of section 379.3 of EAR (General License GTDA) is completely irrelevant. III. Conclusions ----------- Gilmore's conclusion that the posting of cryptographic software to a bulletin board places it in the public domain and thus exempts it from export licensing controls is flat-out wrong. U.S. law is clear: in order to export "cryptographic software" within the meaning of Category XIII(b) of the United States Munitions List to any country other than Canada, a State Department export license is required. If there is any reason to believe or suspect that a non-U.S. or non-Canadian national will gain access to that bulletin board, an export to a third country should be assumed and a license is required.. If there is any question whether specific encryption software constitutes "cryptographic software" within the meaning of Category XIII(b), clarification can be obtained under procedures established pursuant to section 120.5 of ITAR. A determination from State under 120.5 that it does not have jurisdiction is the prerequisite to bringing the control question into Commerce's export regulations. IT IS IMPERATIVE THAT NO DIGITAL EMPLOYEE ACT IN RELIANCE ON GILMORE'S ANALYSIS OR HIS CONCLUSIONS. From: Chris McDonald STEWS_SD 678_2814 27-FEB-1988 15:46 To: security@aim.rutgers.edu Subj: [4363] For dorfman@elca.usc.edu I would suggest the IEEE Tutorial "Computer and Network Security", edited by Marshall D. Abrams and Harold J. Podell. IEEE Computer Society order number is 756; IEEE catalog number is EH0255-0. I am also attaching a selected list of publications which I distribute to anyone who tells me they want to get "serious" about information security. Chris Mcdonald White Sands Missile Range --------------------------------------- SELECTED BIBLIOGRAPHY in AUTOMATED INFORMATION SYSTEMS SECURITY 1. Information Systems Security Products and Services Catalogue, October 1987, National Security Agency. Catalogue contains five chapters: Endorsed Cryptographic Products List; NSA Endorsed Data Encryption Standard (DES) Products List; Protected Services List; Evaluated Products List; and Preferred Products List. 2. Evaluated Products List for Trusted Computer Systems, National Computer Security Center. 3. COMPUSECese Computer Security Glossary, 1 October 1985, National Computer Security Center. 4. Trusted Computer System Evaluation Criteria (DoD 5200.28-STD), CSC-STD-001-83, December 1985, National Computer Security Center 5. Password Management Guideline, CSC-STD-002-85, 12 April 1985, National Computer Security Center. 6. Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments, CSC-STD-003-85, 25 June 1985, National Computer Security Center. 7. Technical Rationale Behind CSC-STS-003-85: Computer Security Requirements, CSC-STD-004-85, 25 June 1985. 8. Magnetic Remanence Security Guideline, CSC-STD-005-85, 15 November 1985, National Computer Security Center. The guideline has a For Official Use Only exemption under Section 6, Public Law 86-36 (50 U.S. Code 402). Distribution authorized to U.S. Government agencies and their contractors to protect unclassified technical, operational, or administrative data relating to operations of the National Security Agency. 9. Personal Computer Security Considerations, NCSC-WA-002-85, December 1985, National Computer Security Center. 10. Security of Personal Computer Systems: A Management Guide, January 1985, National Bureau of Standards Special Publication 500-120. 11. Security Guidelines for Microcomputers and Word Processors, March 1985, Department of Energy. 12. Advisory Memorandum on Office Automation Security Guideline, 16 January 1987, National Telecommunications and Information Systems Security Committee. 13. A Guide to Understanding "Audit" in Trusted Systems, NCSC-TG-001, 28 July 1987, National Computer Security Center. 14. Trusted Network Interpretation, NCSC-TG-005, 31 July 1987, National Computer Security Center. 15. Computer Security: An Overview of National Concerns and Challenges, Report # 83-135 SPR, Congressional Research Service. 16. Proceedings of the IEEE Symposium on Security and Privacy, Annual, Computer Society of the Institute of Electrical and Electronics Engineers, INC. IEEE Proceedings are available from the Computer Society of the IEEE, Post Office Box 80452, Worldway Postal Center, Los Angeles, CA 90080. 17. Federal Information Processing Standards (FIPS) #31, #39, #41, #46, #48, #65, #73, #74, #81, #83, #102, #112. FIPS are available from the National Technical Information Service, Springfield, VA 22161. 18. Datapro Reports on Information Security, Datapro Research Corporation. Customer Service number for Datapro is 800-328-2776. 19. Lobel, Jerome, Foiling the System Breakers, New York, NY, McGraw-Hill, 1986. 20. Parker, Donn, Computer Security Management, Reston, VA, Reston Publishers, 1981. 21. Parker, Donn, Crime by Computer, New York, NY, Scribner, 1976. 22. Carroll, John, Computer Security, 2nd Edition, Stoneham, MA, Butterworth Publishers, 1987. 23. The MIS Information Security Resource Manual, 1986, MIS Training Institute. 24. Computer Security Buyers Guide, Computer Security Institute. The Computer Security Institute is a professional association for computer security specialists. The Institute's telephone number and mailing address are: 617-393-2600/Computer Security Institute, 360 Church Street, Northborough, MA 01532. 25. Kochan, Stephen G. and Wood, Patrick H., UNIX System Security, Indianapolis, Indiana, Hayden Books, 1985. From: gwyn@brl_smoke.arpa 28-FEB-1988 10:10 To: misc-security@uunet.uu.net Subj: [1043] Re: locksmithing courses I think Belsaw's course would fit your needs fairly well. I took this course in my spare time many years ago; it covered the basics adequately, and you would mail in the results of exercises (such as a key you had made by the impression method) for evaluation by an instructor. Belsaw offered their own line of supplies (a key machine came as part of the course), and it shouldn't be too hard to establish your bona fides with locksmith supply distributors. Belsaw advertises in magazines like Popular Science. From: new@udel.edu 28-FEB-1988 12:26 To: sri-spam!csib!lgold@rutgers.edu Subj: [791] Re: copy protection for micro software Marauder (sp?) for the Amiga also uses the copy-protection scheme that asks for certain words from the manual. Sinc the program is designed to copy copy-protected disks, the normal mechanisms would not protect it. In addition, the manual is printed in light blue, I assume non-repro blue. Shortly after the program came out, a program named "find" came out that you start before you run Marauder. When Marauder asks for word 6 on page 3, simply type "find 6 3" and find will tell you the word. Find does not violate the copyright on the manual because it looks into Marauder's addres space to get the word; I know because there is at least one word that Marauder "knows" incorrectly, but find will find tell you what the program expects. - Darren From: "Marshall D. Abrams" 1-MAR-1988 11:05 To: security@aim.rutgers.edu Subj: [3572] Aerospace Computer Security Applications Conf. - Call for Papers Call for Papers Fourth Aerospace Computer Security Applications Conference December 12-16, 1988, Sheraton World Hotel, Orlando, Florida The Conference Operational requirements for civil and military systems under development increasingly stress the necessity for information to be readily accessible to users and operators. This produces an apparent conflict with policies and directives which require total protection of system data from compromises of privacy, confidentiality, and integrity. Accomplishing both of these sets of requirements requires the application of the maturing technology of computer security to new systems throughout their development cycle. In addition, operational approaches to satisfy system requirements and accommodate the implementation of engineering technology require intensified research and development. This conference will explore technology applications in two complementary aspects: first, the policy issues and operational requirements for both civil and military systems; and second, the hardware and software tools and techniques being developed to satisfy system requirements. Special emphasis will be placed on specific examples of systems applications. A three-day technical conference exploring the application of computer security technology will be preceded by two days of tutorials dealing with policy matters, technology applications, and other areas. Introductory and advanced surveys will be offered as well as advanced courses exploring specialized technological areas. Areas of Interest Include: * Trusted DBMSs and Operating Systems * Network Security * Current and Future Trusted System * Technology * Space Station Requirements * Certification, Evaluation and * Accredition * Policy and Management Issues * Advanced Architectures * C3I Systems * Risk/Threat Assessments Papers and Tutorials Technical papers and tutorials which address the application of computer security technologies in the aerospace environment are solicited. Original research, analyses and approaches for defining the computer security issues and problems identified in the Conference's interest areas; methodological approaches for analyzing the scope and nature of computer security issues; and, potential solutions are of particular interest. Full unclassified papers or unclassified abstracts of classified papers, must be mailed before 20 May, 1988. Material should be sent to: Dr. William T. Bisignani Technical Program Chairman Booz-Allen & Hamilton Inc. 4330 East-West Highway Bethesda, MD 20814 Tutorial Proposals including a detailed outline and a resume of presentor(s) must be mailed before 20 May, 1988 to: Dr. Dixie B. Baker Tutorial Program Chairwoman The Aerospace Corporation P.O. Box 92957 2350 East El Segundo Blvd. El Segundo, CA 90245-4691 Classified Sessions: Classified sessions at the SECRET level are planned. Vendor Exhibit A technical exhibit program is planned for interested vendors displaying computer and physical security products. Inquiries should be sent to Mr. Robert D. Kovach Aerospace Computer Security Associates c/o ORI, Inc. 1375 Piccard Drive Rockville, MD 20850 Additional Information For more information or to receive future mailings, please contact the conference chairman: Dr. Marshall D. Abrams, phone: (703) 883-6938 The MITRE Corporation, 7525 Colshire Drive Mail Stop Z670, Mc Lean, VA 22102 E-mail address: abrams@mitre.arpa From: STGEORGE%unmb.bitnet@rutgers.edu 3-MAR-1988 17:29 To: security@rutgers.edu Subj: [157] Court Cases? Do any of you know any court cases, completed or pending, which involve enforcement of the Electronic Communications Privacy Act of 1986? Thanks in advance. From: gnu@hoptoad.uucp (John Gilmore) 28-FEB-1988 06:11 To: hobbit@aim.rutgers.edu Subj: [4646] [Moderator note: I pulled this off sci.crypt; some of you may not have seen it yet. _H*] I'm glad to see that a lawyer has finally looked over the analysis of PD cryptographic software export controls that I did a while ago. I still think we have a free country but will go look up the regulations they quote, to make sure. It may be that before we post something, we have to put it in a magazine or newsletter, or offer it on floppies to anyone who sends in $5 -- no big deal. I would prefer to have a court rule that posting something to 8000 machines, many of which are public-access, and including it in a software library accessible to anyone, is making it "freely available to the public". But for that to happen, somebody will have to take somebody to court, and so far there are no volunteers. The point is that information which is freely available to anyone in the US can be exported. If any Tom, Dick, or Harry in the states can get it, there should be no grounds to hassle somebody over exporting it. Realize that the lawyer who came up with this opinion is paid by DEC to keep DEC out of trouble. The safest thing to do, in the short term, is to turn and run from any kind of trouble. I just think that the long term trouble caused by only the government having privacy is worth facing the short term trouble. I'll have more to say later. -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com "Watch me change my world..." -- Liquid Theatre From: NET%"iconsys!bryan@uunet.uu.net" 1-MAR-1988 23:42 To: misc-security@uunet.uu.net Subj: [1193] Question--Exporting the DES Algorithm What exactly is the policy regarding exportation of software object code implementing (in one form or another) the National Bureau of Standards Federal Information Processing Data Encryption Standard (DES) algorithm? The AT&T UNIX Operating System Release 2.2 and Release 3 license agreements state that the "crypt" program, library, and associated documentation are not to be distributed with international versions of the operating system. Careful examination of the source code, however, reveals the following: 1) The "crypt" library is not the sole source for the crypt(3) routine. The generic C library includes the same crypt routine as contained in the "crypt" library. The difference is that in the "crypt" library, there are additional decryption routines. 2) There appears to be nothing special about the "crypt" program. It does not differ in its use of the DES algorithm from "login". My question is: exactly what may not be exported (by law, not tradition), and why is exportation proscribed? Please respond via E-Mail. Thank you for your help. -- Bryan J. Cardoza Quality Assurance Manager Icon International, Inc. {ihnp4,uunet}!iconsys!bryan From: NET%"dasys1!rodd@rutgers.edu" 2-MAR-1988 23:00 To: misc-security@RUTGERS.edu Subj: [908] re: copy protection for micro software >Tie the operation of the software to a piece of hardware. i.e., >send a piece of HW that can be read by the PC. Perhaps it has to >be inserted in the joystick loop, perhaps it has to be plugged on >to an RS-232 port, etc. Not very convienent if your PC is in a cabinet. Also if you're running in a multitasking environment you will either run into dongle conflicts if they don't allow passthru or will wind up with your machine in the middle of the room to be able to plug in three feet worth of dongles :-) -- Rod -- Rod Dorman {allegra,philabs,cmcl2}!phri\ Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!rodd New York, NY, USA {sun}!hoptoad/ [Moderator note: *What* is a "dongle"?? _H*] From: Larry Hunter 3-MAR-1988 22:54 To: "Robert W. Baldwin" Subj: [778] Re: police radar Cc: security@aim.rutgers.edu Does anyone have infomation about the capabilities and limitations of police radars for speed checking. I'm looking for both technical limitations of the devices and for procedural limitations that are necessary to make a ticket stand up in court.... Although I've never looked for it in print, I've heard that some states require a radar gun to be calibrated periodically (like hourly). If you challenge a radar ticket in court by asserting that the gun was out of calibration, the prosecutor should have to produce evidence that the gun had been appropriately calibrated. If the ticketing officer didn't bring his calibration records with him to court that day, you'd probably win. Larry From: williams@nrl_css.arpa 4-MAR-1988 10:05 To: Clement Taylor Subj: [626] Re: BITNET Security Cc: security@ARAMIS.rutgers.edu There has been some discussion of these issues on the RISKS ARPAnet mailing list. I don't know how or if this list can be forwarded into BITNET, but the person to ask is the moderator, Peter Neumann. From the current issue: The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, FTP SRI.COM, CD STRIPE:, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85). Good Luck! Jim Williams From: Clive Dawson 4-MAR-1988 14:40 To: goldstein%star.DEC@SRC.DEC.COM Subj: [1212] Re: Export of "public domain" crypto software Cc: SECURITY@aim.rutgers.edu Andy-- Many thanks for providing that legal analysis regarding export of cryptographic software. It was all most interesting and informative. There's one point at the end which could use some further clarification, however: If there is any reason to believe or suspect that a non-U.S. or non-Canadian national will gain access to that bulletin board, an export to a third country should be assumed and a license is required.. Let's say that a given bulletin board could somehow be confined within the U.S. borders. It is still the case that a LOT of non-U.S. or non-Canadian nationals will have access to it, be they permanent residents, foreign students, etc. Is it really true that export to a third country must be assumed in this case? I'm guessing that Digital itself has a lot of employees in this category. Surely they are not barred from looking at cryptographic software, or are they? Even if they sign confidentiality agreements with Digital, I would be surprised if the State department would consider this sufficient for export control purposes in general. I guess what we need here is a clear definition of what "export" means for the purpose of these statutes. Clive Dawson From: mgrant@cos.com 4-MAR-1988 21:08 To: security@rutgers.edu, BALDWIN@xx.lcs.mit.edu Subj: [938] Re: police radar The police radar's that I've played with have had an audio feedback. With the audio feed back, you hear an obnoxious buzzing and whistling which represents the doppler shift comming back from the object you are clocking. I found that by listening and watching, I could very accuratly determine exactly who I was aiming at, even with 2 or more cars comming at me. I would point the gun at an aproacing car and I'd hear a high pitched whine, point it away and the whine would go away. Point it at two cars and I'd hear 2 whines at different pitches. Moving the gun twards one car made one whine louder and the other softer. Of course, I've very rarly seen police officers actually holding the radar guns. Most of them I've seen were aimed forward or backwards attached to the window in the left rear. I can't imagine that it would be too easy to figure out who exactly you were aiming at with the gun in this position. -Mike Grant From: Wes Williams 5-MAR-1988 10:17 To: BALDWIN@xx.lcs.mit.edu Subj: [1188] Re: police radar Cc: security@rutgers.edu, GZT.EWW@oz.ai.mit.edu The procedures vary widely from state to state as well as from the local municipality and counties. The research you need to do starts on the local level and will be interesting. I have found that the following can be true: 1. Local police departments may require periodic testing of the units by an in/outside tech type that will validate the Radar unit for safety (rads) as well as the degree of accuracy for the unit. 1a. This may be out of date as well as never done. 1b. State requirements may be downgraded and be illegal. 1c. There may be no requirements (state or local). 1d. The testing (when performed inside) may be done by someone that does not have the qualifications nor the capabilities. 2. Find out if the locality is a constantly watched spot. A police eye (ie: trained observer) that is on the scene and is familiar with the traffic patterns as well as the time involved for a car to pass point A and get to B is as good (in some cases) as the Radar gun. This is also subject to state and local laws. 3. Final note..... READ THE TICKET! In general, a typo or misprint anywhere on the ticket is the real loophole. You can be away clean. Luck... ------- From: Douglas Allen Luce 5-MAR-1988 13:54 To: sdcsvax!misc-security@rutgers.edu Subj: [1612] Re: copy protection for micro software Shipping a piece of hardware that must be plugged into the computer before the software will run has been tried, with only moderate success. There are a couple ways to circumvent this scheme, both fairly straightforward: copy the piece of hardware or remove or rewrite the piece of code in the program that checks to see if the hardware is where it should be. I've only seen this implemented for very small computers; Atari 8 bit machines and commodore 64 computers. Basically, a small jumpered plug was inserted into the joystick port. The program then matched out signals through the joystick port to see if the plug was there. Finding the code in the programs wasn't a complex job; one could pull up a machine language debugger and monitor the joystick port for accesses. From there, the code could be broken down and the part that controlled access replaced with an "ok" code. One would no longer need a piece of hardware to run the program. Also, these plugs were fairly simple to copy. All one had to do was to crack open the device (I think they called them "dongles," a name I hate for some reason), look at the way the inside worked (usually simple, a jumper or two) and then make a new one out of a $.75 joystick plug and a few pieces of wire. A company would generally have a single "dongle" to run all their programs; pirates had only to make one "dongle" to run a whole family of programs. I haven't seen it implemented for the PC's or anything above, but I would think that the same measures could be taken to circumvent copy protection. Douglas Luce Carnegie Mellon From: Russ_Housley.XOSMAR@xerox.com 7-MAR-1988 14:27 To: security@rutgers.edu Subj: [715] Re: copy protection for micro software Cc: Housley.XOSMAR@xerox.com In the 4-Mar-88 edition of Security Digest, hp-sdd!dag@hp-lsd.hp.com suggests that "operation of the software to a piece of hardware." Some vendors of equipment for use on Ethernets (or IEEE 802.3 networks) do just as he suggests. The software checks the 48-bit source address of the host it is running on. If the address is different than expected, the software fails to work. This scheme has failed (i.e., not permitted legal software to function correctly) when the equipment had a second Ethernet port installed. In this case, the equipment had two 48-bit source addresses, and the software checked the "wrong" one. Russ Housley Xerox Special Information Systems Vista Laboratory From: "David M. Balenson" 9-MAR-1988 14:26 To: misc-security@seismo.css.gov Subj: [1276] Submission for misc-security Can anyone provide any information concerning the use of the AMD DES chip within the SUN workstations (e.g., 3/50, 3/140, 3/160, 3/180)? I understand that the CPU boards have any empty socket which will accomodate the AMD chip (AmZ8068) and that the kernel has to be reconfigured to make use of the chip. Is that all there is to it? Will this permit the 'des' command to use the AMD chip, rather than use software? I have also heard that two additional chips may or may not be necessary -- one is a TTL support chip, the other a PAL. What exactly are these chips for? Are they necessary, or not? Is anyone out there, in particular anyone at SUN, currently using the AMD chip? Thanks. David M. Balenson (balenson@icst-ssi.arpa) National Bureau of Standards (301) 975-2910 From: tjfs@otter.hple.hp.com 9-MAR-1988 15:25 To: misc-security@ucbvax.berkeley.edu Subj: [633] RE: Secure labs with PC-LOCK Dan Keizer writes: > security by non-disclosure is no security at all. I *totally* agree. If more people believed this, we wouldn't have the problems we have now with exporting crypt, ... It seems to me it's a philosophical battle between those who say "we won't tell you anything about it to make it more secure" and those who say "if we can't study it, we can't tell if it is secure (and it probably isn't)". With the advent of decent public key encryption, one-way encryption of passwords etc it seems to me a *good thing* that security systems become more understood so that the state of the art continues to advance. Tim From: Will Martin __ AMXAL_RI 10-MAR-1988 21:16 To: security@aim.rutgers.edu Subj: [2549] Re: SSNs, the SSA, and giving out info Back on 25 Feb., I posted a note about a local (St. Louis) newspaper advice column which stated baldly that the SSA would give people info about an individual if you gave them their SSN. Here are the relevant paragraphs from that original posting: >If they cannot answer your questions directly, they may be willing to >give you her Social Security number. You can then trace her whereabouts >through the Social Security Administration. > >At 63, she may have retired, and if she is receiving Social Security >payments, you might be able to get her current address. If she is >deceased, the SSA should be able to tell you that, also. I promised that, when I had time, I would check with the SSA office here and let the list know what they said about this -- was it true or not? Well, I finally had a chance to check today. The word from them is that the SSA will NOT give an inquirer info about a person just because that inquirer provides the subject's SSN. What they will do, though, is to take information from the inquirer, and then write the subject of the inquiry a letter, saying something like, "John Smith, who claims to be your cousin, is trying to get in touch with you. His name, address, and phone are: xxxxxx. You may contact him there if you wish to." In other words, they will act as a conduit to the party whose SSN is provided, but will not give out information about that person to another. (I didn't think to go into detail about just what the SSA would do if the person was listed as deceased, unfortunately.) This actually strikes me as being very helpful, and more likely to be something that the SSA would do theoretically than that they are likely to do in real life! I was asking this as an hypothetical question, showing the SSA representative the newspaper column, and wasn't actually asking them to DO anything. I wouldn't be surprised if this was something so out-of-the-ordinary, so unlike standard procedure, that it would be next to impossible to get the SSA to do this in reality. After all, to do the search and write the letter would take some hours of time, and, considering SSA employees are rated on how many cases they can process in a day, it would be a rare find indeed to locate one who would be willing to delay normal processing, buck the system, and do an inquiring stranger this favor! Nonetheless, from a privacy issue standpoint, the info I got was reassuring. At least the SSA claims it will not wantonly distribute data about you to anyone who happens to know your SSN. Regards, Will Martin From: eachus@mitre_bedford.arpa 11-MAR-1988 22:42 To: iconsys!bryan@uunet.uu.net Subj: [5022] Re: Question--Exporting the DES Algorithm The communications on exporting the DES algorithm which have appeared on the net recently are ALL correct. Huh? What did you just say? Read on. If something not subject to ITAR regulations is in the public domain, or "widely published" in the US, any citizen has a general license to export that information. If fact you may go overseas and speak publicly about what you know, and that will create information subject to license requirements, qualify it for general license, and export it. In other words, as an American citizen, your freedom of speech does not end at the waters' edge. (The country where you give the speech might not like what you say, but that is a different issue.) However, if you have information subject to ITAR regulations (no matter how you got it), you (or your company) can be prosecuted if you export it without State Department approval. See the "aid and comfort" clause in the constitution. Since some crypto information is clearly protected this way, most company lawyers "take the easy way out" and advise the company not to export any crypto software, without checking to see if it falls under the ITAR rules. (Apply standard disclaimers to what follows at least twice.) Last time I checked the "opinion" of State was that the DES algorithm was not subject to ITAR rules, although certain implementations (usually in the form of chips) were protected. Note that any government employee must be vague here, either he knows all the (classified) uses of crypto (and where is YOUR need to know) but can't tell you, or he doesn't know and can't be more specific. Therefore the standard procedure is to request an opinion before exporting crypto implementations, and if you don't get something on the order of "your application does not currently appear to fall under ITAR rules..." you talked to the wrong person (or you really are trying to export a 300 MIP DES chip 8^> ). If you do ACCIDENTLY export something subject to ITAR rules, you probably won't go to jail. In any violation, your rights to free speech must be shown to conflict with other constitutional powers, and the balence must tilt strongly against you before the ITAR regulations have any standing. If you intentionally violate the ITAR regs, however you might not have any constitutional protection. Let me give you a realistic example. You buy a Zowie 1000 portable computer and take it with you to England. Unbeknownst to you, the Zowie 1000 is used in a test system for Stealth Bomber ECM equiptment. You violated the ITAR regulations, but in the normal course of events, you won't even know it, because the DoD is unlikely to tell the Customs people which COTS (commercial off the shelf) equipment is used on black projects. In any case your violation was innocent and is probably protected. Second case, an ATE specialist on the Stealth project buys a Zowie 1000 for personal use because he uses it at work and likes it. He takes it (and some of his software) to England on his vacation. Dumb, and the security folk at the plant may have a long talk with him, but if it was innocent probably no long term repercussions. The third case of course, is he takes it with him and sells it to a foriegn agent for $100,000 -- and twenty years hard labor. What did you think the ITAR regulations were for anyway? So now you know why all the weasel words. If you take my (knowingly incoorect) advice (or someone elses) and innocently violate the ITAR regs, I'm guilty and you are not... "So you're going to Berlin on your vacation? Could you do me a favor? I have this package for my sister, but the mail takes weeks. I'll give you ten bucks for your trouble." You are only guilty if you think he's a spy and do it anyway... Each case is different, and an awful lot depends on intent. It would be nice if someone who has requested and recieved (from the government, not from a company lawyer) a recent opinion on the DES algorithm, would post the opinion here. If no one out in net land has a recent opinion, someone should go ahead and request one. The most recent opinion I have seen was two companies back, and things can change in either direction. Robert I. Eachus Disclaimer: Oh boy, do I need one here. If you have any intention of exporting anything which might be subject to ITAR rules, have your lawyer check with the State Department and get a written opinion. If you decide to create a test case and take it to the Supreme Court, I'll be glad to come cheer, but if you expect me to get up and say it was all my idea, you didn't read carefully. Second Disclaimer: I didn't ask MITRE, MITRE's lawyers, or anyone elses lawyers for their opinion of this message, but if I did, I'm sure that they would waffle at least as well as I did. From: gianni stifano 18-MAR-1988 03:05 To: SECURITY@aim.rutgers.edu Subj: [560] File: "SECURITY MAIL" being sent to you I've just graduated and i'm very interested in security aspects in MHS. Could anyone give me some information about research on document concea= ling or document signing in an X.400 environment? Thanks in advance. From: shafferj%BKNLVMS.BITNET@CUNYVM.CUNY.EDU 24-MAR-1988 14:51 To: security@aim.rutgers.edu Subj: [7328] major VMS security problems The following three messages should be of interest to this discussion. I'm posting them with the assumption that no one else has posted the information contained within them while the Bitnet distribution of Security was down. The last message of the group is particularly scary, because I'm on VMS v4.4 here and I've never heard of the bug. It would appear that our system managers here haven't heard of it either, because there have apparently been some break- ins lately. {See disclaimer at end!} **************** Forwarded messages begin: **************** From: "XMRP20000[khw]-g.c.mccoury" Subject: Hacker hits VMS From The Star-Ledger(Newark NJ) 3/17/88 TEEN HACKER 'INVADES' NEW SECURE COMPUTER PARIS(Reuters)- A 19-year-old West German hacker has succeeded in breaking into one of the world's top-selling computers, Digital Equipment Corp.'s VAX system, in what experts say is a new blow to confidence in computer security. Computer specialists broke the news yesterday at a computer conference already shocked by the arrest on Sunday of West German hacker Steffen Wernery, 26, as he arrived to take part in a panel debate on system security. Wernery is a member of the Hamburg-based Chaos Computer Club which caused a storm last year when it revealed it had penetrated more than 100 computers around the world, including the network of the U.S. space agency NASA. French police announced later that Wernery had been charged with "theft, destruction and damaging computer goods" and had been jailed pending trial. West German journalist and computer expert Hans Gliss, who was also held briefly by French police when he arrived in Paris on Sunday, said the unidentified 19-year-old from Munich had worked out how to enter VAX computers made by Digital. Gliss said the Munich hacker had breached the VAX system by using material openly available from Digital, which is based in Maynard, Mass. Digital executives were in a meeting and not available for comment, a spokeswoman said. Rudiger Dierstein, of West Germany's national space foundation DFVLR, said the consequences of the Munich hacker's achievement were "terrifying." "This person has given a full description of how to gain access to the system and gain full control. Imagine combining the intelligence of this hacker with a definite criminal intention," he said. "Someone could take control of a satellite as they are all computer-controlled. That is why I tremble when I hear the initials SDI." SDI stands for President Reagan's proposed Strategic Defense Initiative, a space-based computer-guided defense system against nuclear missile attack. Dierstein said the 19-year-old had privately published his work in a pamphlet entitled "Hints on the Use of the VMS Operating System" but police had confiscated all the documents. The VMS(Virtual Memory System) is the main language used in Digital's VAX computers. Experts said other major computer manufacturers like IBM could not afford to be complacent as it was being shown their systems were equally vulnerable. Companies targeted by Chaos Computer Club "hackers" were unaware their systems had been tampered with until the club informed West German authorities. Experts at the Paris conference said Wernery had fixed a meeting with the French subsidiary of the Phillips electronic group - one of the companies penetrated by the hackers - before leaving for France. * Grover McCoury * * ATT IS/Communications Laboratories * * Middletown NJ * **************** From: Steve Ward Subject: Re: Hacker hits VMS Does anyone know if this is a REAL security hole in VMS or just the usual 1) failure to change default password(s) on sys, maint, user, userp accounts as shipped from DEC. or 2) autologins left activated by local sys manager. or 3) other equivalent act of stupidity. Often these sensational stories are due to vulnerability caused by stupidity. I have never had much trouble in "hacking" a login to a multiuser system when testing for security, usually by just trying the time-honored guess-the-password approach. Of course, hacking to TEST for security on your own computers is quite different from the vandalism and criminalism of attacking someone else's machines, whether one is hacking through cleverness or taking advantage of the lax management of computer systems on all os's that is out there. I know of large numbers of machines that are accessible to the world where the local users object strongly to being forced to periodically change passwords or insist on using any password, including very short passwords, last names, etc. The ability to "hack" a login is inversely proportional to the number of login accounts on the system :-) Of course, all os's exhibit true security hole bugs from time to time. Is this one? **************** From: Tony Li Subject: Re: Hacker hits VMS Yes, this is the result of a real hole. Do you recall the V4.4 SECURESHR bug? Tony Li - USC University Computing Services "Fene mele kiki bobo" Uucp: oberon!tli -- Joe Isuzu **************** End of forwarded messages **************** If anything further on this subject should be posted to the VAX discussion, I'll forward it to the Security discussion. Jim Shaffer, Jr. ShafferJ%Bknlvms.Bitnet@cunyvm.cuny.edu From: Wes Williams 12-MAR-1988 19:19 To: GZT.EWW%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Subj: Failed mail Just by chance, the other day, I tipped over the box that the bookcase type holder for DbaseIII+ was in, and found a warning from the manufacturer that this product may be covered by the State Dept. Regs. for exporting. Thinking about an upcomming trip to a neighboring country, I was agast that I may have run afoul of customs (forgetting that I had a copy in the trunk). Is this type of program really covered under these laws? From: Jim Duncan 14-MAR-1988 04:41 To: security@rutgers.edu Subj: [1196] dongle Years ago, when I was an avid C-64 user, my favorite word processor was PaperClip from Batteries Included (in Toronto, I think). They allowed (encouraged) copying their software for backup purposes; to use the program, you had to have an electronic key, called a `dongle', plugged into one of the joystick ports. I have seen that word used in other documentation to mean the same thing. Of course, versions of PaperClip which didn't need a dongle to operate proliferated as crackers everywhere found the code which checked for the dongle and detoured around it. I didn't care; PaperClip was so good, and the manual was so well written, that, like Turbo Pascal, it was worth it to me to have a legitimate version and the support that went with it. Batteries Included used the same system with other software they published, like Delphi's Oracle. Great word, huh? I'm suprised that it didn't find its way into a book of Sniglets. I'd like to see an etymology. Jim Duncan, Computer Science Dept, Old Dominion Univ, Norfolk VA 23529-0162 (804)440-3915 INET: jim@cs.odu.edu UUCP: ...!sun!xanth!jim ---------- Time flies like the wind, but fruit flies like bananas. --------- From: che@pbhyf.UUCP (Mitch Che) 13-MAR-1988 19:58 To: misc-security Subj: [1665] >[Moderator note: *What* is a "dongle"?? _H*] Every so often I feel like I've just passed through a time-warp. Unfortunately, it's always backwards. ADAPSO supported this idea which died a timely death about a year or so ago. A "dongle" refers to the little device which plugged into the back of the PC into the RS-232 port. A fair amount of research apparently went into these and some software actually shipped with this protection scheme. ADAPSO pulled its support of any kind of standard for use. Copy protection seems to be a non-issue. With the crash of the PC software industry, copy protection is just what a small company needs to go under. If your software is still copy-protected, rest assured your software is not available in my shop. -- Mitch Che Pacific Bell "Fine Corinthian leather? Of course. --------------------------------------- From fine Corinthian cows..." From: NMIEP%NOBERGEN.BITNET@CUNYVM.CUNY.EDU 21-MAR-1988 15:38 To: security@aim.rutgers.edu Subj: [772] embezzlement Maybe the latest incident on computer embezzlement? Two employees of the largest Norwegian clearing house, Bankenes Betalingsentral BBS, are charged with attempted fraud. The scheme was apparently in accordance to the old dream of redirecting transactions to other accounts. The particular day of the attempt, there were to be a large number of social security benefit transfers. The possible outcome is said to be app. ! 250 million. One of the two had an operator type job, with access to tapes. However, the whole thing was set up in such a way that it was easilly detected by regular security checks. This hopefully shows that security does work, and that the notion that no cases have ever been spotted due to security routines, is not true. Eirik Kim Pedersen From: Steve Bui 24-MAR-1988 13:04 To: security@aim.rutgers.edu Subj: [589] Security package for MVS and VM systems Dear members: Arizona State University is in the process of getting a new security package for our systems, and would like to have your opinion, as well as any inputs on the security software topic. We would like to know: 1. Do you run both VM and MVS? 2. Which security package do you have on your Vm system (RACF, VmSecure...)? 3. Which security package do you have on your MVS system (RACF, ACF2...)? 4. Does the security package(s) perform to your satisfaction? 5. Any comment your security hits and miss? I appreciate your response to my userid, and many thanks for responding. From: gianni stifano 24-MAR-1988 09:49 To: SECURITY@aim.rutgers.edu Subj: [721] File: "SECURITY MAIL" being sent to you Does anyone know TeleTrusT International? It's an international working group about the security of telematic transactions, with particular respect to digital signature obtained by RSA Public Key Cryptosystem. I'd be interested in more deep information about the opportunity to introduce TeleTrusT concepts in X.400 based MHS. Thanks in advance and sorry for my bad english. From: jbn@glacier.stanford.edu 1-APR-1988 06:20 To: misc-security@decwrl.dec.com Subj: [1042] Re: copy protection for micro software Technically dongles can be made to work, and a number of vendors sell them. See any issue of PC Tech Journal for ads for such gadgets. But they are very unpopular with users, and you get nasty reviews in Byte if you put one on your product. The most successful dongles do something useful that the program needs to function. Some dongles have a CPU in them, typically an 8-bit microcontroller. If some obscure but crucial part of the processing is performed in the dongle itself, it can be very difficult to operate the program without it. An excellent example is Cubicomp, which sells an animation package that requires a special graphics board only available through Cubicomp. There's actually nothing exciting about their graphics board; it's just a marketing ploy, and one clever enough that few people have figured it out yet. These strategies are generally for high-end software. At the low end, games, the future probably lies with compact disk technology. But that's another story. John Nagle From: robert@pvab.pvab.se 24-MAR-1988 15:23 To: misc-security@enea.se Subj: [544] Re: Question--Exporting the DES Algorithm > The AT&T UNIX Operating System Release 2.2 and Release 3 license > agreements state that the "crypt" program, library, and associated > documentation are not to be distributed with international versions UNIX can't live without them, so they are not provided as library functions or user commands in export versions, but the complete source for all those functions is (of course) included if you buy a source license. Imagine that. From: ORG5NMC@CMS1.UCS.LEEDS.AC.UK 29-MAR-1988 10:14 To: security@aim.rutgers.edu Subj: [607] Hello all, glad to see this list is alive again. Thanks to all who answered my previous query on master keys. The response was great! I want to ask a question about computer security. Are there any legal obligations (British or American) on a computer user who finds a major flaw within a popular OS? How could a private individual bring a bug to the attention of a computer manufacturer given that site computing personnel take a dim view of anybody who finds these bugs? *NOTE* These questions are for my own interest and are not meant to represent any actual situations or occurrences. From: Derek Andrew 2-APR-1988 08:04 To: watmath!misc-security@rutgers.edu Subj: [1822] Submission for misc-security One problem with using passwords is their vulnerability to an eavesdropping attack. One solution is to implement a challenge and response algorithm as described here. 1. Let P(day) represent a secret permutation of the alphabet, unique every day. e.g. P(today) = zfhkgjavitclbumxpwdonyrseq 2. Let C(T,N) be a function which generates a string of N unique letters. T is the time of day (number of seconds since midnight). e.g. C(12:00:00,5) = jrmxo 3. Let M(P(day),C(T,N)) be a mapping function such that every letter in C(T,N) is replaced by the letter following it in P(day). This mapping is simple and can be applied by visual inspection. e.g. C(zfhkgjavitclbumxpwdonyrseq,jrmxo) = asxpn The permutation of the alphabet of the day P(today) is printed, then, when the user is logging in, a challenge is issued using the C(T,N) function and the user's response is compared with the result of M(P(day),C(T,N)). If they match, the user is allowed access. How does one evaluate the security of this system? What are the possible attacks assuming 100% collection of the wiretap data? How does one choose a suitable value for N? If N = 1, the attacker has a 1:26 chance getting in, but if N = 26, the attacker can derive P(today) after one observation. Does the C(T,N) function need to be secret or is it alright to allow the attacker to anticipate the challenge? I suggest using T as a parameter to eliminate the problem of the same challenge being issued twice on the same day (thus with the same P(day)). From: GREENY 21-MAR-1988 10:12 To: security@aim.rutgers.edu Subj: [907] ATM machines What with all the viruses running about these days, I was wondering what sort of protection ATM machines have against such beasties. Specifically, I'm concerned about my $$$ in these machines. It has occurred to me that the machines which accept charge cards (such as Visa and MC), could not really verify that the PIN you key in is indeed your PIN. It takes up to 5 minutes for an authorization request to come back from a dept. store card reader when you make a purchase, yet the ATM is instanteanous.....this is wierd, either the PIN is stored on the card (read: very stupid) or the machine just ignores the PIN of credit cards..... Whats the deal? does anyone know about what actually goes on with these machines? bye for now but not for long Greeny [Moderator note: There was a discussion about these things a while back; however, I think the relevant messages have long since been rolled off to some dusty tape that I'd be hard put to locate... _H*] From: latzko@aramis.rutgers.edu 29-MAR-1988 13:45 To: security@aim.rutgers.edu Subj: [740] dongles Were yea verily used on PC class machines. Autodesk used on on their 2.6 release of AutoCad. Their response when i called them about it was 1> if it breaks within a year fed ex it back and they will fed ex a replacement. 2> after a year as 1> but with a small charge 3> if it gets stolen or misplaced you are up the creek. They suggested insuring it. After many people complained and enough people didn't buy the upgrade they tossed the idea. Other software which use dongles are Novell Netware and Banyan Vines. There is breaker software for Novell. I am not sure for Vines. /S* PS The person I talked to at AutoDesk told me someone had broken the dongle code withing 24 hours and was distributing the fix within 48. From: dhunt%nasamail@ames.arc.nasa.gov 7-APR-1988 12:21 To: security@aim.rutgers.edu Subj: [724] RE: security in x.400 MHS The best source for information on security in any of the OSI supported services is the OSI Implementors Workshops held approximately quarterly at the NBS in Gaithersburg, Maryland. There are currently two documents available, both of which provide some information on X.400 and security. They are the "Stable Implementation Agreements" and the Working Agreements. The stable agreements are just that, implementors are expected to be working towards those ends. Additionally, the IEEE X.400, particularly the British representatives from the British PTT and BCI,Ltd., have been working directly on the X.400 Security Issues. NBS Special Publications are available from the U.S. Government Printing Office. Doug Hunt From: Luke Ward 7-APR-1988 14:21 To: SECURITY Digest Subj: [1258] Security in X.400 MHS Get hold of a copy of the new 1988 draft X.400 and X.500 (directory) standards. In the US we order these from ANSI (New York) or a company called Omnicom (Vienna, VA) - not sure what the Italian source is. In particular you probably want to take a look at the following: CCITT / ISO ISO Title F.400 / DIS 8505-1 Message Handling: System and Service Overview (see esp clause 15: Security Capabilities of MHS) X.402 / DIS 8505-2 Information Processing Systems - Text Communication - MOTIS - Overall Architecture (see esp clauses 10: Security Model, 21: Authent- ication, and annexes D: Security Threats, and E: Provision of Security Services in X.411 / ISO 8883-1) X.509 / DP 9594-8 Information Processing Systems - Open Systems Inter- connection - The Directory - Part 8: Authentication Framework Luke Ward Data Administration, Virginia Tech From: tli@sargas.usc.edu 8-APR-1988 08:17 To: misc-security@ucbvax.berkeley.edu Subj: [348] Re: major VMS security problems I'd like to retract that statment. We recently received a mandatory security patch from DEC for many versions of VMS. I suspect that there is more going on here than we know about. Tony Li - USC University Computing Services "Fene mele kiki bobo" Uucp: oberon!tli -- Joe Isuzu Bitnet: tli@uscvaxq, tli@ramoth Internet: tli@sargas.usc.edu From: John Pershing 13-APR-1988 09:17 To: security@aim.rutgers.edu Subj: [358] State Department Restrictions and Dbase III+ In general, before trying to transport _any_ machine-readable media across _any_ international boundaries, you should consult your friendly, local, neighboorhood lawyer. Even if the U.S. export laws impose no restrictions on taking various software or data out of this country, the other country's export laws may prohibit you from bringing it back! -jp From: "Dennis G. Rears (FSAC)" 22-APR-1988 13:19 To: security@aim.rutgers.edu Subj: [928] Security Bug > I want to ask a question about computer security. Are there >any legal obligations (British or American) on a computer user >who finds a major flaw within a popular OS? No legal obligations at all unless there is something explicity in the liscensing agreement. Even if there is it would be hard to prove that customer A had knowledge of the bug. >individual bring a bug to the attention of a computer manufacturer >given that site computing personnel take a dim view of anybody who >finds these bugs? Notify the vendor. If you get no response send out the bug to everybody you can. Since you had previously notifed the vendor and he did nothing, they could be held liable for any damages caused by the bug. Dennis From: Liisa Rautiainen 23-MAY-1988 08:53 To: SECURITY@aim.rutgers.edu Subj: [1036] File: "SECURITY MAIL" being sent to you I'm studying system analysis at the University of Oulu. Now I'm working with my pro grad thesis subject of which is information system security. During the summer 1988 I'm going to develop an overall security program for a computer- center. Therefore I'm interested in all aspects concerning information security and vulnerability. I'm very grateful if someone could give me some hints where and how to get latest information of the owerall security programs for computer-centers or send information about the subject: classifications of the system security aspects, computer risks, vulnerability, risk analysis, contingency planning and so on. Yours sincerely Liisa From: iberall%rana.usc.edu@oberon.USC.EDU (Thea Iberall) 23-MAY-1988 08:38 To: mit-eddie!elbows@bloom-beacon.mit.edu, mit-eddie!hair@athena.mit.edu, Subj: [1518] The instructions that are sent with the program say that when compiled and run the program will draw a nice picture of a turkey. I have been informed that the program is a Trojan Horse. It does not draw a turkey, but it does erase all of the unprotected files in your directory. You might want to pass this information along to people you know who use the networks. From: dasys1!stanleyw@rutgers.edu 15-MAY-1988 18:30 To: misc-security@RUTGERS.edu Subj: [599] Submission for misc-security Medeco Lock Co. had their cylinder tested by a government lab at Port Hueneme, California. The test, I believe, used sound waves to determine pin height. The test was performed around 1980. Does anyone have any info on the test and is there an NTIS number. -- Stanley Wociechowski Big Electric Cat Public UNIX ..!cmcl2!phri!dasys1!stanleyw From: "Curtis C. Galloway" 24-APR-1988 16:06 To: security@aim.rutgers.edu Subj: [4020] Cops Catch Clumsy Computer ``Criminal'' From the Pittsburgh Post-Gazette, April 24. Used without permission. by Roger Stuart SOUTH PARK MAN CAUGHT IN U.S. TRAP LEAVES TRAIL CLOUDED IN MYSTERY A South Park man who was stung seeking bogus computer-stored information about U.S. military secrets has a long history of mysterious associations, ranging from foreign intrigue to local garbage. As with past incidents, authorities don't know -- or won't say -- what Laszlo J. Balogh was up to this time when his name surfaced in a sting that caught a West German computer hacker who repeatedly gained access to classified military files. As with past exploits, Balogh, 43, emerged again as part-clever and part-klutzy. Although he has claimed extnsive foreign government contacts and driven expensive foreign cars, he once testified that he had difficulty recording an undercover conversation for the FBI because the recorder kept slipping beneath his sweat suit. In the past, Balogh has billed himself as a Hungarian refugee; a draftsman; a credit corporation employee; a trucking company owner; a diamond dealer; a world traveler; a bodyguard for Kuwaiti princesses; a CIA hit man; and an FBI informant. But longtime neighbors on Ventura Drive said they had no clear picture of Balogh's activities because he is "quiet," "keeps to himself" and is "often gone for weeks at a time." ...Balogh in 1978 was an officer in a now-defunct company when another company official was accused of giving Penn Hills officials a forged check drawn on a non-existent bank. The check was to be used as security in an unsuccessful effort to obtain a garbage-hauling contract. ... Balogh also was involved in a Pittsburgh trucking firm that filed for bankruptcy in 1980. His name surfaced again last week in connection with Marcus Hess, identified by The San Francisco Examiner as the West German computer student who broke access codes to snoop in to U.S. military files a half-world away in Berkeley, Calif. Earlier, a West German weekly magazine, Quick, identified the computer intruder as Mathias Speer, 24. Clifford Stoll, a researcher at the Berkeley Laboratory and Leroy Kerth, a Lawrence Berkeley Laboratory director who oversaw the investigation, said that name may have been a pseudonym. In this case, Balogh, in what investigators believe was an attempt to get more information about confidential military files, took the bait investigators dangled in the hopes of learning who was gaining illegal access to the computer system. Having discovered that an intruder had been reading their computer records, officials at the U. S. Department of Energy's Lawrence Berkeley Laboratiry planted a fictitious file to bait the hacker's interest. The purpose was to keep the hacker on the line long enough for authorities to trace his phone call. The hacker tapped into the computer using a telephone and computer modem. In the event that the call coudln't be traced, authorities also included in the fictitious file an address for the snooper to write for additional information. Berkeley officials thought they had solved their security problem in January 1987, when West German officials were able to trace the phone call to a computer student in Hanover. They were surprised four months later when they received a letter from Balogh, who requested the information offered in the fictitious file. ...Although caught, the West German student has not been charged with any crime. The extent of Balogh's involvement has not been revealed. The FBI isn't saying what, if anything, it knows about Balogh, who in 1983 served them as an informant and government witness. [More about Balogh's involvement in schemes to steal $38,000 in diamonds, secure garbage-hauling contriacts with a phony check, and steal computer equipment to sell to the Soviets.] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Curt Galloway ARPA: cg13+@andrew.cmu.edu UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!cg13+ Drop In Any Mailbox, Return Postage Guaranteed From: goldstein%star.DEC@decwrl.dec.com 3-MAY-1988 18:56 To: security@aim.rutgers.edu Subj: [9085] Reporting Security Problems ORG5NMC@CMS1.UCS.LEEDS.AC.UK asks... (If you put your real name on the message, I'll feel like I'm answering a person rather than a string of alphabet soup.) > I want to ask a question about computer security. Are there > any legal obligations (British or American) on a computer user > who finds a major flaw within a popular OS? Legal: no. The laws surrounding computer security are in an incredibly primitive state. In the US and some European countries, unauthorized use of computers is now explicitly illegal; in the UK, recent decisions I've heard about indicate that there is no law against simple unauthorized entry. Enforcement is yet another story, ranging from the French throwing Steffen Wernery in the nick on suspicion of hacking, to the Germans having to catch someone at home with his fingers in the cookie jar, with the US somewhere in between. But I know of no law that requires an individual to report security problems. If I attempt to draw a parallel to other industry, I don't believe there are any laws requiring private individuals to report, say, safety problems they become aware of. In general, concealment of risks is only illegal where the party who hides information stands to gain from having the information remain secret (e.g., by avoiding a costly recall campaign or expensive safety improvements in a factory) or has control over the risk. But I do think people whe find a security problem have a moral obligation to report it. People who find security problems are in general professionals or researchers, and carry an obligation to the advancement and improvement of the art. Reporting problems is part of that obligation. > How could a private > individual bring a bug to the attention of a computer manufacturer > given that site computing personnel take a dim view of anybody who > finds these bugs? I'm distressed to heard that site management personnel would be so short-sighted to discipline someone who searches for security bugs. If a security problem exists, someone will find it sooner or later; I'd rather it were the curious but responsible hacker than someone malicious. Do please report the problem to the manufacturer. Easier said than done, of course. Most major computer manufacturers have large bureaucracies dedicated to "customer service", and wading through this bureaucracy and its rules can be tedious. DEC is no exception. Try starting with the nearest software service office. See if you can get through to someone technical. I like to think that we've done a pretty good job of instilling in our technical support people the appropriate Pavlovian response to the phrase "security problem in VMS". (If you haven't guessed, that response is "contact engineering, fast!") If you can't get through this way, like because you can't get past the secretary because you don't know your service contract number or don't have one, see if you can get through to someone responsible at a regional office like Basingstoke. (Colorado Springs in the US.) If this doesn't work, try the informal but direct route. The engineering folks of most of the major manufacturers are reachable via the internets. All you have to do is find out who they are. Look for people who discuss security things in the newsgroups (like me here, for example). I can't give you specific names for all time because people change jobs, but recent mail ought to give you some leads. Once you get electronic mail to an interested party in the company, chances are pretty good the information will get to the right person in a matter of days or even hours. [You may wonder, why doesn't DEC just publish an internet address for the express purpose of reporting security problems? It has to do with who owns the nets and what they're supposed to be used for. By and large, they are government funded, and are supposed to exist for the benefit of the educational and research organizations. Having a manufacturer make such a direct use of the public nets smacks too much of gaining commercial benefit from a publicly funded facility. Also, it gives rise to complaints of preferential treatment for sites that happen to have internet access. Obviously, any information volunteered to individuals via the internet will be put to appropriate use by the manufacturer, but expressly setting up a service appears unseemly.] If you've still gotten nowhere, you may have to try a broadcast approach. Send a message to an appropriate newsgroup (like INFO-VAX for VMS) to the effect "I have found a security problem in xxx and would like to report it to the responsible party. Would someone in engineering please contact me?" I would guess that all the manufacturers monitor the important newsgroups (DEC certainly does), and you should get response fast. Of course, your site people may also be reading the newsgroup, and if this is something you haven't told them about and they have the attitude you described above, you may regret having done this. You'll have to weigh the pro's and con's. There is a logical next step one might consider, which is to publish the problem itself. This I implore you not to do. Please don't even tell your friends. Yes, you'll get lots of attention and action, but you'll also cause both the manufacturer but mainly the entire user base much pain. Think about it. You're the only person (in all probability) who knows about this problem. If you're a responsible guy, it'll be safe with you. But there are a lot of not very nice people in the world, and a lot of copycats. If you publicize a security problem, you give all these dirtballs a tool to go messing up the lives of a lot of innocent computer users. Even publicizing a security problem to "responsible people" carries a risk. The more people know about the problem, the greater the chance it will get out somehow. Even if the whole story doesn't get out, if partial or distorted information gets out, others still will know where to look. Consider the probabilities. The typical mean time to discovery of a security problem in VMS is a couple of years. You just found it. But the chance that anyone else working independently will find it in the next 6 months is fairly small. Resist the temptation to conclude that just because you found this problem, all systems in your company or university are at risk and must be notified immediately. It ain't so. The bug always looks horribly simple and obvious after you've found it. But it's buried in a million or so lines of code, and you got lucky. It's only a problem if you tell others. There is a set of people who disagree with the above philosophy, and will probably jump all over me when they see this message. (I've gotten jumped all over each time previously.) I still stand by my position. Others will claim that once one cracker knows about a problem you might as well assume everyone knows about it. Further, they claim that suitably informed system managers can take their own defensive measures if they are informed about a problem. I don't buy it, for several reasons: (1) My experience tells me the cracker communications aren't that good. Yes, some of them will post the news on bulletin boards and it will spread some, but they're just not that globally organized. The Chaos Club is an exception to this rule, but they're not everyone. (2) You can't tell the good guys from the bad guys. Make the information available, and you will guarantee that it will fall into more of the wrong hands. (3) Some system managers will be sufficiently competent to solve the problem on their own. The majority are probably not. Sorry, it sounds like a damned elitist thing to say, but an operating system is a complicated gadget, and if you fix something wrong you're more than likely to break something else worse. What if someone publishes a patch for the problem? Would you trust a patch for your operating system coming from someone you never heard of? If you would, read some of the recent mail about viruses and think again. (4) You won't reach nearly everyone. The internets reach only a small percentage of the customer base of any of the major manufacturers. So you do publish a trustworthy patch for all the internet users. The other 90% of the installations won't get your message, and now they're all the more vulnerable because all the bad guys who read the net news know what the problem is. Not even all the folks on the internets will get the message. I recently saw mail go by from some poor soul who had not heard about the V4.4 SECURESHR bug, and that one has been discussed extensively in INFO-VAX for months. I've been in this debate for some years now, and everything I've seen and heard tells me that if you find out about a security bug, you should (1) tell the manufacturer as effectively and directly as you can (2) otherwise shut up. Well, that was a long answer to a short question. But it's one of my favorite subjects. Thanks for listening. Andy Goldstein VMS Development From: ZSYJKAA%WYOCDC1.BITNET@CUNYVM.CUNY.EDU 2-MAY-1988 18:25 To: security@aim.rutgers.edu Subj: [1644] Virus-writing 101? Thought I'd relate a recent incident to the group regarding computer virus writing and propogation. Apparently we have a professor who thought it would be a good experience for his students, as a project, to write (each) a virus, and demonstrate that it works. OK, in my opinion we're already on shaky ground assuming the 20 or so different viruses can remain totally isolated within the student-instructor environment. As you can guess, some of them have "leaked" out of the "lab". One report indicates that the instructor's hard disk was erased, and another that one student's final project was eaten by his own virus. At least one unrelated PC was found to be infected (in the University's Micro Resource Center!). There are arguments going backand forth about whether this was blatantly irresponsible, or if viral education is a good thing. One can't even consider firing the instructor because he's already leaving to go to another institution. So, this might be a good topic to kick back and forth for a while? What are the ethics/legalities of such an incident? For instance, in American law & philosophy, freedom of information is nearly sacred; is propoagation of the knowlege on how to write a virus itself a bad thing, or only the malicious and/or negligent spreading of one and it's symptoms/damage? Is the passing of this knowlege to a "random" group of students (where the professor is probably unable to evaluate each one's future intentions or views of morality) an unethical, if not illegal, act? Disclaimer: The above are my views, not my employer; I have not had direct contact with the professor or his students. From: tencati@VLSI.JPL.NASA.GOV 28-APR-1988 12:22 To: security@aim.rutgers.edu Subj: [1825] RE: Re: major VMS security problems There's NO glaring hole in VMS security currently (to the best of anyone's knowledge). The current security patch that DEC is distributing is their way of trying to be responsive to all us customers who jumped all over them when the CHAOS feces hit the fan. DEC found flaws in their VMS Workstation Software (VWS) AFTER they had released V4.7. That is why the cover letter says the patch has to be re-applied each time you upgrade to a new version which is lower than 4.7. The VWS apparently has been around since 4.3, which is why the release covers all versions of VMS from 4.3 to 4.7 inclusive. I'd like to commend DEC for the effort they are putting forth. Put yourself in their place. Here you are, a large company, and your product is found to have flaws that could cause certain systems in certain instances to compromise the security they may be relying on. What's the best way to "strongly suggest" that your customers implement the patch you have devised? I think they did a good job. We all wish VMS was bug-free, but when you're developing a product in a competitive environment, the faster you can get it out, the more money you can make. And unfortunately, we live in a money-based society. The patch to SYS.EXE appears to have something to do with the page-faulting algorithm or working-set adjustment according to what I remember seeing in the fiche when I checked to see what it was patching. This also appears to be a retro-fit for all 4.7 and under versions. Before you criticize DEC, first put yourself in their shoes and see if you can come up with a better idea, keeping in mind that YOU are one of the customers you would have to make happy. Ron Tencati Jet Propulsion Laboratory Pasadena, CA. TENCATI@VLSI.JPL.NASA.GOV [These opinions are mine. Not JPL's, not NASA's, all mine!] From: the terminal of Geoff Goodfellow 18-APR-1988 02:36 To: hackers_guild@ucbvax.Berkeley.EDU Subj: [10223] front page, new york times. nypt BC-EXCLUSIVE-COMPUTE-1stadd NYT NEW YORK: the intrusions. According to the Lawrence Berkeley officials, the yearlong investigation involved the FBI and security experts from the Air Force and the Army, as well as private security investigators. Under West German law, not enough evidence was obtained for prosecution, the Lawrence Berkeley officials said. According to Stoll, the West German compromised the military computers by taking advantage of security loopholes in several different operating systems, the software programs that manage data in a computer. On computers operating under the Unix system, he frequently used a loophole to give himself ''superuser'' status, which allowed him to read and alter all material stored in the computer. The intrusions involved a variety of U.S. military computer systems in this country, Europe, and Japan. The Lawrence Berkeley Laboratory became a starting point for connecting to two unclassified military networks, known as Milnet and Arpanet. They link computers at military bases and military contractors. At one computer at the Naval Coastal Systems Command, in Panama City, Fla., the intruder transferred to a computer in West Germany an encyrpted file containing user passwords. The intruder broke some of the codes and called back to search through files protected by the passwords. The intruder also gained acess to computers at the Army's Fort Buckner base in Japan and at the Anniston Army Depot, a supply base for the Army's Redstone Arsenal, in Huntsville, Ala. At the Air Force Systems Command, in El Segundo, Calif., the intruder managed to attain the status of system manager. ''I watched as he scanned all of their SDI references and the usual pile of things and then started printing out information on the space shuttle,'' said Stoll. ''The Air Force later told me it was not classifed information.'' Other systems entered included military computers in San Diego, the Pentagon's Optimus data base, and a computer at NASA's Jet Propulsion Laboratory, in Pasadena, Calif. The officials at the Lawrence Berkeley Laboratory said that they monitored attempted intrusions into a total of 450 military computers. ''Basically, he was walking down the street twisting the doorknob of each house,'' Stoll said. ''He wouldn't push hard, but then he would go around and do the electronic equivalent of trying the back door and the side windows. If they didn't budge, he would go to the next house on the street.'' Shortly after discovering the intrusions, Stoll, aided first by City of Berkeley officials and later by federal law-enforcement officers, began trying to trace their origin. They were traced to a computer at a U.S. military contractor in McLean, Va., near Washington. The Lawrence Berkeley officials declined to identify the company. They then discovered that the intruder was dialing from Hanover to a university computer in Bremen, West Germany. That computer was used to connect to machines in the United States. The intruder's location was masked by dialing into the military contractor's computer in Virginia and then using that computer's capability to call other computers around the country, including those at Lawrence Berkeley. The Lawrence Berkeley computer was used to connect to the military networks - Arpanet and Milnet - to gain access to the military installations. In tracing the intruder, the security investigators created an automatic alarm system. Stoll wrote a computer program that would dial his pager whenever the West German gained access to the computer at Lawrence Berkeley. The pager automatically called a security official from the Tymnet McDonnell-Douglas Network Systems Co., a computer network company based in San Jose, Calif. The Tymnet official then notified West German law enforcement officials. But the investigators traced the calls back to Hanover, where it took as long as 30 minutes to set up a trace because of antiquated equipment. The intruder's calls generally lasted no longer than five minutes. In January of 1987, the security managers at Lawrence Berkeley created an electronic sting operation using a large file of fictitious, seemingly secret information. The file contained a reference to an address at the Berkeley laboratory where further information related to the Strategic Defense Initiative could be obtained. Once the file was discovered, the intruder remained connected to the Lawrence Berkeley computer for more than an hour. Three months later, according to the Lawrence Berkeley officials, a letter was mailed from a United States citizen living in the Northeast to the address given by the lab, inquiring about the false SDI information. The letter was given to the FBI. From: GREENY 26-APR-1988 04:03 To: security@aim.rutgers.edu Subj: [1280] Viral Code I have recently been assigned the task to make sure that the Departmental computers (macintoshes, as well as some IBM's..) are virus free. This should prove to be quite a task seeing as how the faculty members love to get a hold of all the PD and shareware stuff that they can get their hands on. Basically what I have decided to do is to write my own application and or protecting CDEV (on the order of Vaccine) to deal with any virus problems which we may have. I would greatly appreciate it if anyone who has been bitten by one of these beasties or anyone who has trapped one without being bitten could send me the source/object code to it/them. I would be willing to correspond in any way necessary (US Snail Mail, Bitnet, direct modem transfer, disks, tapes, etc..). As for making use of some of the applications which are already out there, well call me overly paranoid, but I really dont trust anything anymore that I dont have a copy of the source to. After I write the above, I will post it to the net(s) along with a copy of the source.... thanx in advance... Bye for now but not for long David S. "Greeny" Greenberg From: wadlow@godot.psc.edu 27-MAY-1988 01:27 To: misc-security@uunet.uu.net Subj: [885] Re: Medeco Cylinder Testing >Medeco Lock Co. had their cylinder tested by a government lab at Port >Hueneme, California. The test, I believe, used sound waves to determine >pin height. The test was performed around 1980. I have never seen any info about tests of that sort... It sounds kind of pointless to perform this sort of test on a Medeco though. Once you know pin heights, you still don't know the rotation of the assorted pins, so you still have a decent number of permutations in order to find the correct combination. I can see more use in performing this sort of test on a Best cylinder, or some other cylindar that doesn't rotate the pins. Steve From: Douglas Humphrey 27-MAY-1988 14:00 To: deh@eneevax.umd.edu Subj: medeco testing An interesting possibility for lock work would be a Sonogram system, used to look into peoples internal organs, etc. with sound waves. These seem to be pretty portable. I wonder how well they would work. Anyone know more about this? Doug From: PALMER at DUVM 29-MAY-1988 16:05 To: SECURITY@aim.rutgers.edu Subj: [932] Phone booths Taken from the Sydney Morning Herald and the May 22, 1988 issue of Awake magazine. In an effort to outwit phonebooth theives, Telecom, Australia's government- owned telephone company, has fitted the susceptible booths with Kirk safes. Named after the worker who invented them, the safe has so far proved 100- percent effective. As mentioned in the Sydney Morning Herald, it has with- stood 'oxy torches, ramset guns, angle-grinders, hydraulic jacks, pulley clamps, centre-punches and bricks.' Ironically, the new safes appear to have led to an increase in vandalism, as theives frustrated by the tough safes vent their anger on the booths. Telecom reports that the current rate of smashed glass and ruined handsets and cords is at a new high of 3,000 cases per month. From: simsong@westend.columbia.edu 18-APR-1988 22:28 To: telcom@xx.lcs.mit.edu, security@aim.rutgers.edu Subj: [180] credit cards I'm purchasing a machine that reads and writes the mag strips on credit cards. Question: Does anybody know if credit cards are high field or low field magnetic systems? Thanks. From: tencati@VLSI.JPL.NASA.GOV 22-APR-1988 19:37 To: security@aim.rutgers.edu Subj: [830] Computer Security My opinion is as follows: The computer user has NO legal obligation to inform other users or the manufacturer of a newly discovered bug in the operating system. However if knowledge of the bug is used to exploit OTHER people's operating systems, then the user has committed a crime. If that machine is located in another U.S. state, or is a U.S. Government-owned machine, then the user has committed a felony. If the user wanted to inform the computer manufacturer. He/She should call the general offices, and tell the secretary that they wish to discuss a newly-found security bug with the appropriate person(s) within their company. They will be routed through a maze of phone numbers and will eventually come upon the correct ears. Ron Tencati Jet Propulsion Laboratory Pasadena, Ca. USA Tencati@vlsi.jpl.nasa.gov From: abrams%community_chest.mitre.org@gateway.mitre.org 27-MAY-1988 11:15 To: abrams%community-chest.mitre.org@gateway.mitre.org Subj: Failed mail This note is addressed to the entire list because (a) of its general interent and (b) Liisa's original note did not indicate which network to respond to. (Liisa, please contact me directly.) I recommend "Building A Secure Computer System" by Morrie Gasser, Van Nostrand Reinhold, 1988 and "Tutorial: Computer and Network Security" by Abrams & Podell, Computer Society of the IEEE, (Computer Society order number 756, IEEE Vatalog number EH0255-0), 1987. Sincerely, - Marshall D. Abrams, phone: (703) 883-6938 The MITRE Corporation, 7525 Colshire Drive Mail Stop Z670, Mc Lean, VA 22102 Alternate e-mail address: abrams@mitre.arpa From: Christopher Seline 24-APR-1988 03:57 To: SECURITY@aim.rutgers.edu Subj: [400] Old ATM bug I stoped using ATM's a few years ago when I discovered an interesting bug. If there was an error giving out the cash, the machine indicated an error on the screen but STILL debited your account or credit card.... This bug has (theoretically) been repaired. scs7317@oberlin.bitnet From: Fred Blonder 24-APR-1988 19:08 To: miss026%ecncdc.bitnet@cunyvm.cuny.edu Subj: [1681] Re: ATM machines Cc: security@aim.rutgers.edu I don't think the concept of a virus applies to ATMS. They're not constantly being exposed to random unverified software. Now if one of the Bank or atm companies programs tries something funny, you might be in trouble, but I hope I am not being too optimistic in assuming that such software gets scrutinzed throughly before it get used. The main point is that ATMS are not general purpose computers, and don't need an operating system, so all the standard hooks that a virus would use to gain a toehold just do not exist. the ATM is instanteanous.....this is wierd, either the PIN is stored on the card (read: very stupid) or the machine just ignores the PIN of credit cards..... Some ATM systems store the PIN encrypted on the card, just like Unix passwords. If the encryption algoritm is truly one-way, this is safer, but stil doesn't protect against a forged card if you know the encryption algorithm. Once when I entered my PIN number incorrectly I was surprised when the machine accepted it and went to the next stage of the menu, but when I finally did something that requred the machine to contact the host computer, it barfed and made me type the PIN again. This is an odd system, but at least it seems secure. ---- Fred Blonder uunet!mimsy!fred Fred@Mimsy.umd.edu From: Eric McIntosh 25-APR-1988 04:20 To: security@aim.rutgers.edu Subj: [1013] Re: Challenge-Response alternative to Passwords Just for information I would like to describe briefly here our proposed solution to the vulnerability of passwords. At CERN we are installing Security Dynamics software on our CRAY UNICOS system. This software requires that every authorised user be issued with a SecurId card which displays a password which changes every 30 seconds and is, I guess, the ultimate in dynamic passwords. In addition, every user must have a PIN so that possession of the card alone is insufficient. When a user attempts to login he is prompted for his PIN and current passcode instead of his UNICOS password. We believe this system to be very difficult to break even with continuous monitoring of lines or networks. It makes life a little more difficult for the user but a lot more difficult for crackers. We have also extended this system to cover batch job submission, to prevent tampering with batch jobs, and to verify user authorisation even when jobs are stored and forwarded and possible monitored by an unauthorised person. From: ZSYJKAA%WYOCDC1.BITNET@CUNYVM.CUNY.EDU 8-JUN-1988 11:05 To: security@aim.rutgers.edu Subj: [767] Floor Safe sources Does anybody have ideas on where I might acquire an older floor safe for home use at a reasonable price? I am hoping to find something about 2x2x2 to 3x3x3 feet or so, and about 1910-1940 or so in appearance so it won't be so ugly my wife leaves. I keep checking things like local estate sales and going-out-of-business sales (lots of those lately) but one hasn't turned up yet. I'm certain I need to find one locally (I'm in Laramie Wyoming; Denver is a 2.5-hour drive away if I could find one there) due to shipping costs for something that heavy. Do these things show up in trade journals or something like that? I know the older safes are not as secure as some modern designs, but modern crooks seldom carry explosives and are seldom adequate safe-crakcers. From: "Mark D. Gabriele" 25-APR-1988 08:19 To: security@aim.rutgers.edu Subj: [785] Security for MVS and VM systems I am aware of several packages which have been evaluated by the National Computer Security Center for securing the MVS operating system: RACF version 1 release 5 (C1); Top Secret Version 3.0 (C2); ACF2/MVS releases 3.1 through 4.0 (C2). A C2 system is more secure than a C1 system. Only one VM security package has been evaluated for VM, and that is ACF2/VM, which got a C2 rating. I have never used MVS, but I have worked with ACF2/VM and I found it to be an extremely flexible and usable system. It supports an enormous degree of custom-tailoring if your site needs it; if you don't, then you can run it as it comes right out of the box. I have never worked on systems running RACF/VM or VMSecure. =Mark note that I don't act as a spokesman for whoever it is that I work for. From: mason@EDDIE.MIT.EDU 25-APR-1988 09:39 To: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU, security@aim.rutgers.edu Subj: [662] Re: ATM machines The PIN you key in is locally (to the atm) run though a one way enxryption algorithm with the account # (stored on the card) and compared with the same thing (again stored on the card). This means if you know the format of the data written on the card (ANSI X9.1) and the encryption stuff (ANSI X9.8) you can write your own cards. Also, in many remote areas where banks feel there's not as much need for security if the ATM cannot talk to the host it will perform transactions and just journal them. Cut the phone lines and Voila! The two year old expired card works again. I don't keep any more money in an account attached to a card than I can afford to lose. From: NG44SPEL%MIAMIU.BITNET@CORNELLC.CCS.CORNELL.EDU 27-MAY-1988 00:25 To: SECURITY%AIM.RUTGERS.EDU@RELAY.CS.NET Subj: [775] Security threats of viruses I am currently researching "computer viruses", trojan horses, and the like. The report which I plan to prepare will include descriptions of various public domain and commercial software which claim to protect from or detect viruses. Some examples of software I am evaluating are: DataPhysician, Triad line, Protec, VI-RAID (commercial), Flushot+, Novirus, Checkup, and CRCDOS (public domain). If anyone is currently using any of these programs, or others like them, I would greatly appreciate your sending me information describing how they are implemented, access controls you have in place, and anything else which you think will be of help. I will be happy to describe the results of my research on SECURITY. Thanks. Neil Goldman (NG44SPEL at MIAMIU.BITNET) From: Brint Cooper 2-JUN-1988 23:27 To: security@aim.rutgers.edu Subj: [1719] Re: Virus-writing 101? reports, "Apparently we have a professor who thought it would be a good experience for his students, as a project, to write (each) a virus, and demonstrate that it works." He relates the havoc in the lab that this project created. Then he/she asks (paraphrase): 1. Is "viral education" a good thing? 2. What are the ethics of such a practice? 3. Would it be against the spirit or letter of "freedom of information" to restrict such teaching and the propagation of such knowledge? Perhaps the analogy with biological viruses isn't overworked after all. In consideration of such analogy, I submit: 1. "Viral education" is a good thing. "Know thine enemy" might be the appropriate commandment. 2. The ethics of viral education are, in my view, similar in computer and biological systems. If there's any doubt about inadvertant propagation, the viral education should remain at the prospective and theoretical levels. I don't believe, for example, that third year bio or chem students "create" new viruses by DNA/RNA splicing and other genetic engineering techniques. The results would be too unpredictable. So it is with computer viruses. 3. The propatation of knowledge is one thing. But for permitting the propagation of the virus, the prof should be sentenced to have to use only the little fingers of each hand on his keyboard for the next five years! A better approach would be to assign students to write "virus hunting" or "interferon" programs. If a "weakened" computer virus is available, one whose characteristics are sufficiently well-known as to keep it well-contained, then the students' anti-viral programs could be tested against it. From: "Michael J. Chinni, SMCAR_CCS_E" 3-JUN-1988 13:57 To: security@aim.rutgers.edu Subj: [1275] Re: Virus-writing 101? > For instance, in American law & philosophy, freedom of information is nearly > sacred; is propoagation of the knowlege on how to write a virus itself a > bad thing, or only the malicious and/or negligent spreading of one and it's > symptoms/damage? I think that both the propagation and passing of said knowledge is at least unethical and possibly illegal. Illegal because it could be viewed as conspiring to commit a crime (malicious use of a virus). I think that this is analogous to a counterfeiter giving a class in forgery and requiring the class to forge currency. If the class had been given to a group of computer security specialists with the intent of showing the ease of creating a virus, the possible results of an infection, and possible countermeasures, then I would see no problem. But for the class to be given to a "random" group of students I find reprehensible. Disclaimer: Opinions expressed are my own and not the official views of my employer. Mike Chinni Dover, NJ From: Nick Papadakis 3-JUN-1988 17:48 To: ZSYJKAA%WYOCDC1.bitnet@cunyvm.cuny.edu Subj: [1849] Virus-writing 101? Cc: security@aim.rutgers.edu It strikes me as a poor example of pedagogy. Biology students do not experiment with tuberculosis (say) when less virulent examples that serve the purpose exist. The instructor should not have permitted the viruses to have destructive side-effects. The general precept in law is that *posession* of information is never illegal, but *utilizing* it may be. There are exceptions (pornography, classified information, and doubtless many other well intentioned attempts by poorly-informed legislators) but the argument hinges on whether you consider *transferring* information to be 'utilizing' within the context above. I sympathize with the DEC employee who recently posted a message to the effect that people who discover security flaws should just keep quiet; in the short term this is a reasonable response. In the longer term people should keep in mind that these machines have only been around for fifty years or so - we don't really have the foggiest idea of what they might ultimately be good for. The fact that they happen to be good for something right now shouldn't be allowed to hinder their further development. Just in passing, I wanted to remark on an interesting point: viruses are only really a problem for people who don't distribute source. Think about it. - nick From: markb@sm.unisys.com 25-APR-1988 14:04 To: security@rutgers.edu Subj: [2582] Re: Challenge-Response alternative to Passwords >1. Let P(day) represent a secret permutation of the alphabet, unique every > day. e.g. P(today) = zfhkgjavitclbumxpwdonyrseq If you assume that what the user types is vulnerable to an eavesdropping attack you must assume that any thing the computer displays is also vulnerable. WSO if the computer displays P(day) that the attacker knows it. OOPS! >2. Let C(T,N) be a function which generates a string of N unique letters. > T is the time of day (number of seconds since midnight). > e.g. C(12:00:00,5) = jrmxo The use of any other monotonically non-decreasing function would work as good as the time. >3. Let M(P(day),C(T,N)) be a mapping function such that every letter in > C(T,N) is replaced by the letter following it in P(day). This mapping > is simple and can be applied by visual inspection. > e.g. C(zfhkgjavitclbumxpwdonyrseq,jrmxo) = asxpn If the attacker knows P(day) (see above) then the security of this method depends on keeping M secret. But the M you chose is easy to determine from just a few examples. >Does the C(T,N) function need to be secret or is it alright to allow the >attacker to anticipate the challenge? I suggest using T as a parameter >to eliminate the problem of the same challenge being issued twice on the >same day (thus with the same P(day)). It doesn't matter what C you use if P(day) and M are known. The only successfull looking system of this type is based on the use having a small calculator like device that used DES or some other encryption algorithm to generate the proper response to a challenge based on a key stored in the device and back at the computer. Mark Biggar {allegra,burdvax,cbosgd,hplabs,ihnp4,akgua,sdcsvax}!sdcrdcf!markb markb@rdcf.sm.unisys.com From: seven@vax.ftp.com 23-MAY-1988 14:45 To: elbows@bloom-beacon.mit.edu, dev@vax.ftp.com Subj: [2654] Future Shock Blasts In the 4/88 issue of Progressive Architecture: Security: The Next Stage [...] Not Just Bricks and Mortar Highly developed design tools are beginning to emerge in areas related to security. As has been the case in other areas of design (structual and energy systems, for example), engineers are providing architects with computer-based techniques for analysis and design. One such example, apparently unique, is BombCAD(TM), developed jointly by the Evertt I. Brown Company and the Lorron Corporation to assess the possible effects of terrorist bombings on buildings and their components and Occupants. In demonstrations of the program, using a hypothetical building and site, BombCAD's developers are able to show a highly detailed diagram of bomb-induced overpressures and impulse loads at interior and exterior points of the building. The effiacay of new architectural and site elements - for example, placing an earth berm at the base of a building, or specifying stronger glazing and framing members for a lobby partition - can be assessed readily. Much of the knowledge used to develop this software has been available in other places (for example, in monographs and tables provided in various military design manuals and guidelines). And, as its authors redily acknowledge, BombCAD has limitations (one of which is that the program's estimate of human injury are based only on primary plast effects, while much empirical evidence suggest that an equal or greater number of fatalites and serious injuries may result from secondary and tertiary effects, such as flying debris or subsequent building collapse). Still there is no denying that the software integrates existing knowledge and gives it new applications. As security conerns continue to grow in priority among the traditional clients for design services, we can expect more design tools of this variety to emerge. - By Thomas Vanier, AIA [Accompanying the article are two examples of the program output from a video display] In a demonstration of BombCAD analysis, a car bomb (top, show as a white star) explodes outside a building lobby. The program sets shock impulse load and overpressures (figures in yellow and red) on key parts of the building exterior. BombCAD also can estimate interior blast loads and overpressures. Red stars indicate locations of other potential bombs, whose characteristics and effects can be modeled seperately. A second example (above) illustrates one of many possible placements of a so-called briefcase bomb. The program's flexibility allows examination of many possible bomb locations and charge weights. From: John Pershing 26-APR-1988 10:15 To: security@aim.rutgers.edu Subj: [516] ATM machines If your friendly, local department store takes 5 minutes to do a credit authorization, then there is something severly wrong with their system. Credit authorizations for the major credit cards are almost always processed in a matter of seconds: the systems that they use are FAST! If a request is not answered in some specified time limit it is an implicit authorization, and the issuing company will eat the loss if this turns out to be a mistake. John A. Pershing Jr. IBM Research, Yorktown Heights From: Stan Horwitz 29-APR-1988 10:16 To: security@aim.rutgers.edu Subj: [1031] Re: ATM machines I seems to me that ATM technology isn't at risk from hard core hackers doing damage as from share stupidity on the part of ATM card holders. I have several cards and use the regularly. The word INSTANTANEOUS is wrong. It takes me just as long to get a credit card authorization as it does to make a withdrawal with my ATM card, give or take a few seconds here and there. As far as ATM's go, I am not sure but I think that what happens is you enter an entire transaction and the machine reads some stuff off the card, then the whole batch gets sent via telecommunications line somewhere where the transaction is processed and verified, then if cash is wanted, a signal is sent to the actual ATM machine and you get your bucks and a receipt. Just about the only transaction I ever make at ATM's is withdrawals. If I happen to type in my PIN incorrectly, it does not immediately warn me, I have to enter the entire transaction, then wait for the central ATM host to bounce a warning back to me. This is hardly instantenous. From: ZSYJKAA%WYOCDC1.BITNET@CUNYVM.CUNY.EDU 26-APR-1988 14:35 To: security@aim.rutgers.edu Subj: [2765] Kermit versus login passwords I recently got the following from our people in our micro-computer section. I'm no expert on Kermit, but it smells like security, so I thought somebody on the SECURITY list might be able to help -- CAN YOU HELP US? Script files can be used with KERMIT on microcomputers to do many things much more efficiently. Micro Resource Center staff have been developing script files to log in automatically to the VAX and CYBER mainframes. We are quite stumped by one problem and wondered if you had any suggestions? Script files can be set up in one of two ways: (1) the password to complete your log-in is contained in the script file, or (2) you manually enter your password each time you log in. Our concern is protecting the security of access to your mainframe accounts. When the password is contained in the script file itself, it is not visible on the screen during the execution of the log in procedure. Security is protected as people watch you log in, (they can't see the password, and they can't even watch your fingers because you aren't typing anything). However, for those of us with microcomputers that cannot be locked or are located in semi-public areas, it would take a very few minutes for a "hacker" to find the script file and identify a password to any mainframe computer account, if the script file was left on the hard disk. Typing the password in manually does nothing to solve this problem. In Kermit, apparently when the script file is halted to permit typing from the console, there is no way to prevent the password from being visible on the screen. In addition, we have not been successful in clearing the entire screen rapidly enough or changing the colors on the screen at that point to prevent users from viewing the password as they watch you log in. This is a section of the script file we have been using to log in to the VAX with the password included in the script file: input 5 Local> output c\13 input 20 Username: output MYUSERNAME\13\10 input 5 Password: set input echo off output MYPASSWORD\13 set input echo on pause 1 This is a section of the script file we have been using to log in to the VAX and enter the password manually: input 5 Local> output c\13 input 20 Username: output MYUSERNAME\13\10 input 5 Password: output @con; type in password here output \13 pause 1 I would really appreciate any ideas you might have on how we can successfully protect access to our passwords to either the VAX or CYBER mainframes under these conditions, without totally abandoning the concept of automating our log in procedure through use of Kermit Script Files. If it isn't possible, I guess that's useful to know, too! Thanks. From: NET%"Postmaster@aim.rutgers.edu" 29-APR-1988 20:00 To: JMS@mis.arizona.edu Subj: [1320] Failed mail Date: Fri, 29 Apr 88 16:18 MST From: Watching the Detectives---now we *know*! Subject: RE: Security in X.400 MHS To: security-list@aim.rutgers.edu >Get hold of a copy of the new 1988 draft X.400 and X.500 (directory) >standards. In the US we order these from ANSI (New York) or a company >called Omnicom (Vienna, VA) - not sure what the Italian source is. Actually, you can't get copies of the correct 1988 versions of X.400 and X.500 series from ANSI; they have not been published by the CCITT. The latest versions, approved March 21-31 in Geneva, almost certainly haven't made it back to ANSI for distribution. Hal Folts of Omnicom has copies of the draft standards, and if you call and specifically ask for those versions, you may get what it is you want (but beware that the hand-written comments do have the force of law...). Also, remember that nothing, particularly in the area of security, is final until the November Plenary in Melbourne. Some errors in your titles: F.400 (also numbered X.400) is ISO 10021-1 (DIS ballot expected shortly) X.402 is ISO 10021-2 (DIS Ballot expected shortly) X.411 is ISO 10021-4 (DIS Ballot expected shortly) (see also ISO 10021-3,5,6,and7 for additional X.400 cross-lists) Joel Snyder DECUS representative in US delegation, CCITT Study Group 7 From: Rob van Hoboken 13-MAY-1988 22:37 To: SECURITY@aim.rutgers.edu Subj: [3531] File: "SECURITY MAIL" being sent to you I have found many bugs and/or security exposures in MVS and as such have had to think up a reaction to such finds. I have done the following: 1. create a proof for submission to the manufacturer, 2. send in a documented error report to the technical rep. and a high ranking management type of the manufacturer. When after several weeks nothing has happened: 3. send the above mentioned trouble report to colleages in other computer centers, and have them submit a similar report to the manufacturer. I have made a policy of never going with such exposures because of the seriousness of the situation. Consider a computing center being faced with an exposure in one of its key software systems (e.g. their transaction system). What options do they have? 1. They can not remove the software from their systems, that would lose them millions of dollars PER DAY. 2. They could try to hack a fix for the exposure. Estimated time of success several weeks of syspro work. Risks of malfunction of the entire transaction system, no support from supplier. No dice. 3. Monitor abuse of the exposure. Difficult. 4. Contact the supplier, explain the predicament and suggest you go looking for a replacement of his product. Usually successful, but it takes about half a year for a security fix to arrive. I think it is immoral towards colleages in your site and other centers to publicly announce a security leak. Even discussing it with too many syspro types is risky, because one of them may be a blabbermouth and spill the news to an unfriendly hacker or newspaper type. It happens to be our reality that you cannot close down a system on account of a security exposure if that system is earning you money. Fixing it is risky and difficult, so waiting for you friendly supplier is the best you can do. In this respect IBM has the best policy I know of: each contract contains a clause that a security exposure shall be dealt with within a specific time. I've seen it work and I am impressed. Of course some sites never apply the fix, so not everybody will be covered, but that is their risk. Other suppliers (on the IBM market) do not have a similar policy. I know of several instances where an exposure was not even fixed after three years. In one case I persuaded some of my friends to remove the product from their systems and terminate the contract with the supplier. I don't want to sound too gloomy, but the morally acceptable method will not always yield results. The (in my view) immoral way yield long term results, but in the period between public exposure and fix your systems are extremely vulnarable to practically every hacker with assembler knowledge. In no way can you guard against that many possible perpetrators. The only argument I can come up with to defend a security through ignorance policy, is the small number of attempts that will be made on your system. I be better to keep relatively inexperienced hackers unaware of exposures when knowledgable folks can find out. In the worst case it will save you unscheduled IPLs. From: edelheit%community_chest.mitre.org@gateway.mitre.org 3-JUN-1988 12:54 To: goldstein%star.DEC@decwrl.dec.com Subj: [1643] Re: Reporting Security Problems Cc: security@aim.rutgers.edu Andy - Many (most?) of the large vendors are on the internet. (Look at the .com domain; even IBM is there!!). DoD Instruction 5215.2, dated 2 Sept. 1986 establishes the Computer Security Technical Vulnerability Reporting Program (CSTVRP). It's purpose is to establish "procedures for reporting all demonstrable (sic) and repeatable technical vunerabilities of Automated Information Systems (AIS)" and establish "methodologies for dissemination of vulnerablility information." Given 5215.2, one might successfully disagree with you regarding vendors not being able to use the internet for reporting. I tend to agree with many of your statements, but I hope that I am slightly more optimistic. Jeff Edelheit (edelheit@gateway.mitre.org) The MITRE Corporation 7525 Colshire Drive McLean, VA 22102 (703) 883-7586 From: Bob Dixon 29-APR-1988 14:59 To: SECURITY@aim.rutgers.edu Subj: [842] Encryption Software We are looking at encryption software for IBM MVS systems. We are aware of Kryptonite, DEF, Psypher and IBM's product. 1. Are there any others available? 2. Does anyone out there use any of these, and if so would you be willing to share your experiences with us, to help us make a choice? 3. Many encryption packages use the DES algorithm. Does this imply any kind of compatibility between packages? IE - if a file is encrypted by one package using the DES algorithm, can it be decrypted by another package which also uses the DES algorithm, assuming that you know the key? This is very important if one wants to exchange encrypted files over networks between dis-similar computers. Bob Dixon Ohio State University From: darrell%odin@ucsd.edu 6-MAY-1988 19:30 To: misc-security@cs.ucsd.edu Subj: [667] Security of TV broadcasts I have a question about the security of TV broadcast systems. We've all heard of "Captain Midnight" and his interruption of HBO (or was it Showtime?) using a satellite up-link. The other night, while I was watching "Conan the Destroyer" (no comments about my taste in movies please), a message came on in plain white letters overlaying the bottom of the screen: "This program brought to you by the association of american leprosy societies." This was on cable, watching a LA broadcast channel. Does anyone know how this could have occured? Sorry, I don't have a video tape to back up my claim, it was out on loan (why do you think I was watching Conan?). DL From: _*Hobbit* 11-JUL-1988 20:58 To: security@aim.rutgers.edu Subj: Administrivia For the second time in six months, I'm being forced to flee yet another doomed machine. We're selling the Vax 785 called aim.rutgers.edu, and moving to a sun 4. The boss-man wanted a faster machine, liked the other sun 4's we already have, and decided to get one; in addition, the resale value of the 785 drops daily, so all of this comes at somewhat short notice. Needless to say the Security list has to move somewhere too, and since the rest of the world seems to be going to Unix, I might as well sit down and learn how to make sendmail stand on its head and handle the list. This transition in theory will be transparent -- I'll move the list's mechanism and messages to the new machine at some point and start sending from there. That machine will probably answer as aim.rutgers.edu when we get everything going right. I don't want to announce an official change until I know how to handle things over there and write a zillion emacs macros, but things may fall fairly silent with regard to remailing while I'm teaching myself and the new machine how to deal with it. Your harried moderator... *Hobbit* From: GREENY 10-JUN-1988 19:38 To: security@aim.rutgers.edu Subj: [710] Cryptography BBS Please bear in mind that I am in *NO* way related to this BBS, I have merely been in the same room when a friend of mine logged into it and I thought that the people on this list might be interested in making use of some of the topics on it. 'nuf with the legal stuff....heres the vital stats... The Crypto BBS 1-703-237-4322 This BBS is centered around a cryptography basis, and has GOBS of PD programs and source relating to such.....Have fun. Although most of it is for PC's :-< -- leaving us Macites out in the cold... bye for now but not for long... Greeny Bitnet: miss026@ecncdc Internet: miss026%ecncdc.bitnet@cunyvm.cuny.edu Disclaimer: Call it if you want, but don't blame me for problems.. From: ZSYJKAA%WYOCDC1.BITNET@CUNYVM.CUNY.EDU 10-JUN-1988 19:56 To: security@aim.rutgers.edu Subj: [4358] Sonogramming locks I'd bet that the sonogram equipment and techniques used on people would be pretty useless on a Medeco-sized lock. First, the things you're looking at are much smaller. Second, the speed of sound in metal is, I believe, much higher than water (people), meaning the electronics must switch between pulsing and receiving much faster (definitely not impossible, just the "baby-watching" stuff probably won't hack it). Third, you probably only have access to the front face of the lock (if you have access to the sides and top, just open it up) and that means you'd be "looking" at the pins all at once; you'd rather have a side view so as to see them individually. I sent a long response to the original poster of the question about using sound waves; I guess I should have kept a copy to send to the group. My own speculation of such techniques involves using one of two methods. First method: The "time domain reflectometry" type. Using a key-shaped holder if possible, hold a transducer against the bottom of a pin. Repeatedly (1 kHz?) send a pulse out of it, switch to receive mode, and display the echos on a 'scope and time them. Second method: resonance. Again hold a transducer against the pin. Sweep a range of frequencies (50-250 kHz or so) and look for resonances as indicated by peaks and dips in the induced voltage (you'd have to play with the impedances to get the right "Q" for optimum sensing). Several factors effect how well either method works. Keep in mind that round-trip time for a pulse in a .1" pin made of metal with speed of sound around 3000fps is 5 microseconds; corresponding resonant frequency is 200 kilohertz. Very thin pins (as used in some mastering methods) would be even "quicker". You must (or should) know the pin material, since I would guess speed of sound is quite different in steel versus brass, and maybe significantly so in differing types of brass (I don't have the proper references handy). Some "pin assemblies" consist of a steel ball contacting the key followed by a brass pin, so that can be nasty (but easy to discover with a flashlight); perhaps the ball would yield a distinctive "signature" on the instrument, or perhaps it would obscure desired signal. The pins should ideally be isolated from the lock body but that's impossible, so I'd guess it would be best to thoroughly clean the lock with a fast-drying liquid that leaves no residue. On the other hand, getting some graphite or teflon particles in there might help "insulate" the pins. You'd have to try it and see. I have no idea how badly misleading or mangled a signal would be from mushroom pins. You might get a false sense of a possible shear line from locks constructed with a second cylinder (a better mastering technique, as used at least on better Russwins) depending on how much signal got conducted from the pins into the body. Such diversion of signal would also degrade the system's response (e.g. echo strength). If there are many pins involved, the multiple echos and/or resonance modes could be pretty hairy to sort out, except for the first pin or two. Question: "WHY?" Sounds a bit like a high-tech B&E tool. Yeah, but even a screwdriver can be used for illicit gains. It is obviously a useful item to ponder for legitimate locksmith use, such as very secure installations where the key was lost and no copy existed. This would be very expensive to buy if it were available, or non-trivial to build in either case, and most of the bad guys couldn't cut a key if you handed them the cut numbers or a blueprint. Significant skilled "interpretation" might be required as well, if the methods work at all. One last thought: Yes, knowing the pin heights on a Medeco doesn't get you in. But there's only three possible rotations for each pin, so heights gets you a lot farther than knowing nothing. A neat feat of miniature machining would be to make a Medeco key (as keys go they're rather big) with shim-adjustable heights and rotatable "seats" for the pins. Making one that could be adjusted while seated in the lock would be even better, best if you could transmit back some "feel" to the operator. P.S. I probably have the speed of sound in metal way off. Air is 1100fps I think, and I vaguely recall it is 6 times that in steel. Maybe one could steal techniques from reflection seismology too. From: blblbl!zonker@EDDIE.MIT.EDU 20-JUN-1988 20:09 To: bloom-beacon!elbows@mit-eddie Subj: [4004] how not to rob a bank RULES FOR BANK ROBBERS According to the FBI, most modern-day bank robberies are "unsophisticated and unprofessional crimes," comitted by young male repeat offenders who apparently don't know the first thing about their business. This information was included in an interesting, amusing article titles "How Not to Rob a Bank," by Tim Clark, which appeared in the 1987 edition of The Old Farmers Almanac. Clark reported that in spite of the widespread use of surveillance cameras, 76 percent of bank robbers use no disquise, 86 percent never study the bank before robbing it, and 95 percent make no long-range plans for concealing the loot. Thus, he offered this advice to would-be bank robbers, along with examples of what can happen if the rules aren't followed: 1. Pick the right bank. Clark advises that you don't follow the lead of the fellow in Anaheim, Cal., who tried to hold up a bank that was no longer in business and had no money. On the other hand, you don't want to be too familiar with the bank. A California robber ran into his mother while making his getaway. She turned him in. 2. Approach the right teller. Granted, Clark says, this is harder to plan. One teller in Springfield, Mass., followed the holdup man out of the bank and down the street until she saw him go into a restaurant. She hailed a passing police car, and the police picked him up. Another teller was given a holdup note by a robber, and her father, who was next in line, wrestled the man to the ground and sat on him until authorities arrived. 3. Don't sign your demand note. Demand notes have been written on the back of a subpoena issued in the name of a bank robber in Pittsburgh, on an envelope bearing the name and address of another in Detriot, and in East Hartford, Conn., on the back of a withdrawal slip giving the robber's signature and account number. 4. Beware of dangerous vegetables. A man in White Plains, N.Y., tried to hold up a bank with a zucchini. The police captured him at his house, where he showed them his "weapon." 5. Avoid being fussy. A robber in Panorama City, Cal., gave a teller a note saying, "I have a gun. Give me all your twenties in this envelope." The teller said, "All I've got is two twenties." The robber took them and left. 6. Don't advertise. A holdup man thought that if he smeared mercury ointment on his face, it would make him invisible to the cameras. Actually, it accentuated his features, giving authorities a much clearer picture. Bank robbers in Minnesota and California tried to create a diversion by throwing stolen money out of the windows of their cars. They succeeded only in drawing attention to themselves. 7. Take right turns only. Avoid the sad fate of the thieves in Florida who took a wrong turn and ended up on the Homestead Air Force Base. They drove up to a military police guardhouse and, thinking it was a toolbooth, offered the security men money. 8. Provide your own transportation. It is not clever to borrow the teller's car, which she carefully described to police. This resulted in the most quickly solved bank robbery in the history of Pittsfield, Mass. 9. Don't be too sensitive. In these days of exploding dye packs, stuffing the cash into your pants can lead to embarrassing stains, Clark points out, not to mention severe burns in sensitive places--as bandits in San Diego and Boston painfully discovered. 10. Consider another line of work. One nervous Newport, R.I., robber, while trying to stuff his ill-gotten gains into his shirt pocket, shot himself in the head and died instantly. Then there was the case of the hopeful criminal in Swansea, Mass., who, when the teller told him she had no money, fainted. He was still unconscious when the police arrived. In view of such ineptitude, it is not surprising that in 1978 and 1979, for example, federal and state officers made arrests in 69 percent of the bank holdups reported.