Subject: RISKS DIGEST 17.31 REPLY-TO: risks@csl.sri.com RISKS-LIST: Risks-Forum Digest Tues 29 August 1995 Volume 17 : Issue 31 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: US White House Hacked? (David Kennedy and Mich Kabay) REVIEW: Computer Crime: A Crimefighter's Handbook (R. Joseph Loughry) Warning on MSN Icons (Edupage) Information on Winword virus (PC/Mac) (Paul Ducklin) Taunting the lions [more on the year 2000] (Bear Giles) Re: Risks of automatic newspaper publishing (Bear Giles, Mark Seecof) Re: Dumpster diving on the Information Superhighway (Peter da Silva) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 28 Aug 95 23:01:50 EDT From: David Kennedy <76702.3557@compuserve.com> Subject: US White House Hacked? [German Press Agency, 20 Aug 1995, Received in German through the Executive News Service of CompuServe. First pass machine translation by GlobaLink Power Translator v. 1.0; errors in translation by David M. Kennedy & Michel E. Kabay] German Hacker in White House Computer Annoys the Internet By Justus Demmer, German Press Agency Hamburg (German Press Agency) - Among those familiar with the Information Superhighway, there are certain rules of behavior: Netiquette. In the last week, German hackers have broken with Netiquette, offending some users of the global network of some 30 million computer users by sending a message accusing users of attempting to penetrate the US White House's computers. The alleged sender of these messages? President Bill Clinton. An article in the German Computer Magazine "c't," published in Hanover, broke the news. However the messages leave telltales of their German origin, which tipped off the Systems Administrator in the White House who in turn notified the German Computer Emergency Response Team, DFN-CERT. DFN-CERT functions as a kind of fire department for the Internet. They identified the "Clinton-Mails" as fakemail according to the magazine's article. DFN-CERT acted but withheld news of the attacks. [DMK: So apparently did the White House. Possibly one of the many Sendmail holes?] DFN-CERT staff member Uwe Ellerman said Internet users, and especially magazines, have a responsibility to acknowledge attacks. However many do not want to admit they were penetrated. Ellerman said that the press should report these matters. The magazine should make their own computers available for such silly tricks if they wish. However, explained c't editor Georg Schnurer, that has not been the case. He claimed the White House uses an old version of software for electronic mail handling which is obsolete. This program makes it possible to falsify mail. Many other System Administrators also use this older version, leaving the network vulnerable to similar attacks. [DMK: More pointers towards Sendmail. More pointers to why it should be acknowledged so that the clueless will check for Sendmail holes. Possibly confirming fact, the recent US CERT Sendmail Alert.] Ellerman and Schnurer do not agree whether public notice of the White House error was necessary or not, they do agree that to maintain integrity over their mail, users should encrypt their mail. David Kennedy / Vol.SysOp Natl Computer Security Assn Forum on CompuServe GO:NCSAFORUM M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: Mon, 28 Aug 95 15:42:49 PDT From: loughry@seattleu.edu (R. Joseph Loughry) Subject: REVIEW: Computer Crime: A Crimefighter's Handbook REVIEW: Computer Crime: A Crimefighter's Handbook, by David Icove, Karl Seger, and William VonStorch. Published by OReilly & Associates, Inc., August 1995. 437 pages, with index. ISBN: 1-56592-086-4. COMPUTER CRIME: A CRIMEFIGHTER'S HANDBOOK was derived from an FBI training manual on the prevention and investigation of computer crimes. It delivers a wide-ranging, non-technical overview of computer system vulnerabilities, threat assessment, and the law. Covering the gamut from unlawful intrusion to poisoning of computer operations staff, this book provides an excellent introduction to threat assessment and security procedures for protecting an organization from computer crime. Unlike most computer security books aimed at system administrators, this one is written from the perspective of law enforcement, and describes what to do before, during, and after a computer crime is discovered. The book is divided into five parts. The first part of the book describes vulnerabilities, threats, and countermeasures, with equal emphasis given to the human components of a system as well as technical issues. The section on Social Engineering is well illustrated, if a bit too short, and some of the more obscure possibilities for covert channels and compromising emanations are well covered. The discussion suffers from a lack of references to documented attacks (see below), and a somewhat confusing explanation of the differences between Trojan Horses, viruses, worms, and logic bombs. Chapter 5, on risk assessment, nonetheless is excellent. Physical, personnel, and communications security are covered in the remainder of Part II. One exposure that I thought was not mentioned highly enough is the vulnerability of backup media to theft. Dumpster diving is discussed in some detail (together with a humorous and totally unnecessary diagram). I would have liked to see references given for many of the examples of computer crimes scattered throughout the book. Some of the descriptions edge toward hyperbole; more complete references would allow the reader to pursue further information if needed. Two of the appendices, written by John Gales Sauls and Michael G. Noblett, are liberally referenced. Part III of the book is the most unusual. It is essentially a checklist for the professional investigator who needs to collect and preserve evidence of a computer crime. Much detail is presented on the identification and preservation of anything even remotely related to a criminal investigation (within the bounds of the required search warrant, of course). Appendix D contains the full text of an actual search warrant used in an investigation in 1994, which makes for fascinating reading. It is interesting to compare these chapters with the Foreword, in which Chris Goggans describes a search of his home by the U.S. Secret Service in 1990. Part IV contains the text of laws covering computer and communications security in the United States at the level of Federal and State courts. The text of a proposed computer crime law from Ghana is also included, for completeness. Appendices list books, organizations, electronic resources and governmental agencies responsible for computer security. These appendices are not nearly as detailed as those provided in COMPUTER SECURITY BASICS, by Deborah Russell and G.T. Gangemi, Sr. (ISBN: 0- 937175-71-4), another book published by OReilly & Associates. Together, the two books complement one another perfectly. Joe Loughry, Distributed Systems Department, First Interstate Bank loughry@seattleu.edu [Usual disclaimers implied. PGN] ------------------------------ Date: Tue, 29 Aug 1995 08:04:38 -0400 From: info@ivory.educom.edu (Edupage) Subject: Warning on MSN Icons (Edupage, 27 Aug 1995) A new convenience included in Microsoft Network e-mail processing could present a loophole for invading computer viruses, warn some security experts. When an MSN user sends a binary file as part of an e-mail message, it appears as an icon on the recipient's screen. When the recipient double-clicks on it, it's automatically downloaded and executed. To download without executing the file, the recipient must click with the little-used button on the right of the mouse. "On the Microsoft Network, I can disguise an icon so that it looks innocuous," says the VP and chief technical officer for Interactive Data Corp. "The analogy I like to use is the Unabomber. If you get a package in the mail that's wrapped in duct tape and brown paper, you'd regard it as suspicious. But if it's a plain white envelope with Ed McMahon's picture on it, you wouldn't think twice about opening it." Microsoft responds that "There are risks of getting data off the network in any form. People have to be aware of what the source of information is." (Information Week, 28 Aug 1995, p24) [Also noted by Monty Solomon . PGN] ------------------------------ Date: Tue, 29 Aug 1995 12:49:11 EDT From: VIRUS-L Moderator Subject: VIRUS-L Digest V8 #73 FROM VIRUS-L Digest Tuesday, 29 Aug 1995 Volume 8 : Issue 73 Date: Thu, 24 Aug 95 12:45:15 +0100 From: Paul Ducklin Subject: Information on Winword virus (PC/Mac) As many of you will know, there's a Microsoft Word macro virus out there (variously known as "Winword.Concept", "WW6Macro" and "Prank Macro") that has apparently made it into the wild. The idea of macro-language viruses is not new -- indeed, AFAIR, Prof H. J. Highland, editor of Computers & Security, demonstrated the possiblity under Lotus 1-2-3 several years ago. What is new is that this Word macro virus seems to be in the wild, and that it seems to be driving people wild. Certainly, news wires are abuzz. If we believe what we're told, it's the End Of Computing As We Know It (again :-). The concept is obvious, and has been much discussed. Most products can read and write data files; some allow their data files to contain programmatic commands that would more typically be typed at the keyboard or issued with a mouse. The idea is that when you load a data file with a "command script" or "macro" in it, you can carry out a whole sequence of program functions automatically -- rather than having to type them in over and over again. Many programs with macro support allow their macros to access a substantial range of functions, such as opening, manipulating and closing files -- or even issuing direct operating system commands. Some macro systems go even further -- they allow macros to be mixed with regular data files, and they define special types of macro (typically identified by a predefined name, or position) which will automatically be fired up when a file is loaded or the system is started. DOS has such a system -- no prizes for guessing where the name AUTOEXEC.BAT comes from. No prizes, either, for working out that data-file + macro-language + autoexec-of-special-macros is a formula which works out to a security nightmare. Viruses, Trojan Horses, modification-of-service attacks -- all are remarkably possible in such an environment. MS Word 6.0 has a particularly rich macro language (WordBasic), and a number of "macro hooks" whereby an unsuspecting user can be lured into executing a hitherto unseen and unknown macro simply by loading a document. This is how Winword.Concept works -- we leave the actual details as an exercise to the reader, for safety's sake. Winword.Concept is obvious, and easy to handle. Most anti-virus software users should be able to contact their vendor for help on how to detect and clean it up (Sophos SWEEP clients certainly can: mail to technical@sophos.com if you're worried). There is a bigger issue, though, which you would do well to address *now*. Ask yourself if you are aware of any "automatic macro" facilities in the software your organisation uses. And ask yourself if you know how to control the operation and scope of these facilities. For example, if you're a WinWord user, did you know that: * a document can contain an AutoOpen macro, which may be executed transparently and automatically when that document is opened? * a macro, once running, can make changes to a set of global macros that may end up being transparently included in many or all documents created in the future? * there are numerous "automatic" triggers in addition to AutoOpen that malicious macro code might exploit? You can see the risk here. You may know, or be told, though, that: * holding down whilst opening a document will inhibit the invocation of its AutoOpen macro. * Tools/Options/Save includes an option ("Prompt to save NORMAL.DOT") which will make transparent changes to your global macros much less likely. * that you can instruct WinWord, when you load it, to switch off "automatic" macros altogether, by loading it with the command "WINWORD.EXE /mDisableAutoMacros", or by holding down the key as you fire it up. You may also, like me, try out these fixes and discover that the first and last don't actually seem to work as suggested! There is a good trick for WinWord, however: create yourself a global AutoExec macro (this is run when Word starts up) that looks like this: Sub MAIN DisableAutoMacros MsgBox "Auto Macros are turned off", "Safety First!", 64 End Sub WinWord.Concept -- and other malware based on AutoOpen -- will not work if you do this. Control is in your hands. Don't panic. Take the opportunity to learn more about features of the software you use, to test and verify any security features you plan to utilise, and then to configure accordingly. Don't treat this new Word virus as a nightmare; use it as an opportunity to take stock, and to learn. (Commercial sideline: you don't have to be a Sophos client to e-mail technical@sophos.com -- or try http://www.sophos.com :-) Paul Ducklin Sophos Plc + 21 The Quadrant + Abingdon OX14 3YS + England duck@sophos.com [Paul also has a followup message in the same issue of VIRUS-L. PGN] ------------------------------ Date: Tue, 29 Aug 95 17:14:53 GMT From: bear@fsl.noaa.gov (Bear Giles) Subject: Taunting the lions [more on the year 2000] Two telling excerpts from a Sunday, 27 August 1995 _Denver Post_ article (page 3B). 2000 May Hold Years of Trouble 4-digit dates bedevil computers By Patrick O'Driscoll Denver Post Staff Writer [Clayton Powers, staff director for Colorado Commission on Information Management] said "If you wrote really good code, you might put your date routine in one place. Another programmer may have a date routine 10 times in a program." Ironically, institutional computer geeks have known about "the year 2000 changeover" for years, to the point it even became an inside joke. The first paragraph explains why it's the big organizations we need to fear on the upcoming odometer rollover. Small companies tend to be much more insistent on at least minimal competence and efficiency. I have a hard time conceiving of any programmer needing to write a date routine more than once -- that's the type of code that goes into a library. Additionally, small companies tend to sell to many users, and some of us are warped enough to occasionally set the clock forward to 2012 or so, just to see what happens. :-) On the other hand, there's only one user of many government computer systems, and those systems are in continuous use. If they don't test their own software, nobody will. On a related note, 7 years ago I came across an Ada relational database which could handle most dates past the turn of the century, but had serious problems with dates from March 2000 through February 2001. How many people check for problems in that bit of logic? Don't assume that 01 Jan 2000 is the only problematic date. I would also check around 29 Feb 2000, 01 Mar 2000 and 28 Feb 2001. (The last two dates can be a problem due to day-of-week calculation which uses a year running from March through February.) The second paragraph is a rather interesting bit of institutional bigotry. The Denver Post also runs radio ads for their weekend classified section, referring to having plenty of jobs for "computer geeks." I'll freely admit to calling myself a "geek," but the meaning of that term as I use it is very different than the meaning implied by some hostile copywriter. And it _is_ "hostile" when that's the only term used and it's stretched to cover everything from a 13-year-old surfing the net to people with 20 years experience and advanced degrees. This article carries on that tone, with three paragraphs spent on this "inside joke," but absolutely no space spent on the substantial effort that has already gone into this effort, the lessons learned after the DOS "sign change" in 1989, or the fact that many software professionals have been fighting management for years over the need to start patching code _now_. BTW, the "inside joke" offered wasn't the "Ship of Fools." (Everyone goes on an extended cruise; the "fools" is a reference to the crucial role of the fool or court jester in medieval Europe, roughly what we would have as a "Devil's Advocate" today.) Instead it was a much more self-centered fantasy about programmers retiring before 2000 (to avoid the frantic phone calls from users?), and only when they realize it will affect their pension checks do they decide to take action -- fixing the pension system software. Overall, the tone of the article seems a lot like Christians taunting the lions. The author admits there's a problem, a big problem, and that it has the potential to harm him (with references to "income taxes, welfare, employment records and the like.") But rather than working towards a solution, he gratuitously insults the only people who could help him. Am I reading too much into this? Perhaps. But at the same time I've been aware of this problem for years, and have played no small part in helping to mitigate the problem. (I've found and reported several significant library bugs for dates after 31 Dec 1999.) I find it hard to understand how this reporter could spend several paragraphs on a joke, but not make a single mention of the fact that many people have already been working on this problem. Hmmpf, he didn't even mention the '89 meltdown, which would seem to be a good starting point since so many people had problems with it. It's a good model of the problems we face in '00. (For the curious, my project used DOS-style dates. A coworker and I both used "unsigned [short] int" for all dates and our packages had no problems. (The other guy also wrote the date package, fortunately.) It never occurred to either of us that our coworkers might not have understood why the "unsigned" was important, and one day their code suddenly started to fail. Our product was very schizophrenic for a couple days, but we were able to get fixed releases out quickly.) Bear Giles bear@cs.colorado.edu ------------------------------ Date: Mon, 28 Aug 95 22:10:14 GMT From: bear@fsl.noaa.gov (Bear Giles) Subject: Re: Risks of automatic newspaper publishing (Epstein, RISKS-17.30) >a writer, who had made up the fake story for internal distribution, The coverage in the local press suggests (to the sufficiently warped mind) that this was a prank article for a female friend's birthday. I guess the idea is that _she_ was the female in question, and the fact that the reporter scheduled the following day off only seems to strengthen this conjecture. ;-) >accidentally put the article in the directory where stories to be in the >next edition belong. That's not hard to imagine; that's probably a short sequence which is heavily used. He probably gave it as much thought as a "vi" user gives to ":wq". >Reaction by the newspaper readers has been >mixed...some have been amused, while others thought it was "pornography". That paper has a reputation for being laid back; the local coverage made it clear that everyone involved (except possibly the Chief of Police) was trying hard not to laugh too hard. I would treat claims it was "pornographic" akin to claims "that in a recent survey of 100 teenage Americans only 20% could identify Canada on a map." (Or something similar.) It's possible, but it's much more likely the people involved were having fun with a credulous reporter. (You have to remember that this was _Aspen_.) >In the meantime, the author of the particular piece is still working at the >newspaper. The editor-in-chief did not disclose what punishment, if any, >there would be. He probably left that up to the reporter's girlfriend. I hope she has a good sense of humor. (_We_ don't know the name of the woman... but I expect her friends recognized clues woven into the story :-) >The risk is that as newspaper production becomes more and more automated, >there's less need for people to do reviews, and hence a greater risk of an >error like this happening. No, it's an example of the risks of an overly-serious workplace. People _will_ play games with the computer system; in this case it's a reporter writing bogus stories for a friend on the computer. This is desirable because it helps the person develop new skills. There are very few jobs (and none of them are very desirable) where the skills you have on the first day are all you'll ever need. And it's often not realistic to expect the person to have a sufficient "mock up" available at home or elsewhere. But the American workplace is increasingly "serious." You can get into very real trouble for "screwing around," even if you can show that most of your recent major advancements (instead of yet more regurgitation of the same thing) directly followed such idle explorations. And because you don't have a chance to learn how to safely work outside of the main loop, if you do sneak in a bit of extracurricular fun you're much more likely to accidentally put the lark into the main data stream. That appears to be what happened here. Bear Giles bear@cs.colorado.edu ------------------------------ Date: Mon, 28 Aug 95 17:53:41 -0700 From: Mark Seecof Subject: Re: Risks of automatic newspaper publishing (Epstein, RISKS-17.30) At the Los Angeles Times (where I work but which I DO NOT (generally) represent at a policy level) we have several filters to avert the publication of bogus news stories. Basically, most writers do not have sufficient system authority to put stories directly into the paper (although, of course, certain editors do... but they are trusted). The organizational method of planning how to fill the space in each edition provides the basis for a later sanity check on the material which is actually sent to typesetting (cold) and pasted up. However, we no longer employ proofreaders. Any glitch which isn't caught by spell-check or a sharp-eyed editor will get into the paper and many typos and editing mistakes do. And, as with so many systems, a privileged person acting maliciously could put something inappropriate in (at least on an inner page). Actually, we print more wrong stuff because our writers are misinformed, or misunderstand their informants, or misrepresent something out of ignorance than we ever do because of deliberate or inadvertent sabotage. (We have printed errors, but never of any great magnitude. We have never printed an improper front-page story for any computer- related reasons. One reason we haven't yet replaced our TANDEM-based integrated software package timesharing-terminal system for news writing and editing is that we would have to address many system reliability and security requirements in a new system that most microcomputer-based client/server system vendors don't handle well or sometimes at all. We used to proofread display advertising matter, but we quit doing that a couple of years ago. I myself once caught an ad with incorrect dates in it when I walked through the composing room and glanced at the Travel section being made up (we had been asked to run an ad which had run before. The salesperson didn't realize that the dates--of cruise-ship sailings--were "out of date" and needed to be "updated"). I spotted the anomaly and alerted the composing people, who yanked the ad and called the salesperson. We were able to get the correction in time to run the ad. We do proofread classified (liner) ads--more to catch crooks (who attempt to cheat the public, or sometime us) and deadbeats (who owe us money and try to run more ads without paying us for the old ones), and to censor "offensive" stuff (e.g., real-estate ads that suggest some kind of racial exclusivity) than to find spelling errors. (Mind you, our classified salespeople don't key in very many spelling errors.) I might point out that we try pretty hard to keep advertisers who cheat the public out of our pages. Such advertisers often cheat us too, plus we think that readers who get cheated will be less likely to buy our paper and patronize our other advertisers, and that in turn would hurt our business. I like to think we would censor racist/sexist/whatever advertising no matter what, but we are given extra incentive to do so by the law (which I believe is a wicked, wrong law) that makes *the Times* liable to pay damages to victims of advertisers who violate civil-rights laws, and sometimes other laws, *even though the Times is not a party to the transaction*. (And before any of you get too huffy about the benefits of 3rd-party liability as a way of enlisting the otherwise indifferent in the war on -isms, realize that we censor anything vaguely suspicious and be glad you're not trying to rent out a house near a shopping center--'cause we may not let you advertise "walking distance to shops" since that might imply you would discriminate against cripples.) Mark Seecof Publishing Systems Department, Los Angeles Times ------------------------------ Date: Sat, 26 Aug 1995 15:31:13 -0500 From: peter@nmti.com (Peter da Silva) Subject: Re: Dumpster diving on the Information Superhighway (Peters, 17.30) Thomas Peters writes: > It is easy to get credit card numbers through dumpster diving, shoulder > surfing, dishonest retail employees, and telephone scams. All of these > methods are much easier and simpler than cracking Netscape encryption > with currently available technology. Unfortunately for this argument, they're also a lot riskier. You have to physically be in a location where the CC# is present for all but the social engineering attacks like telephone scams, and unless you're cold calling people and soliciting them (a low-return operation, and one unlikely to generate high-limit numbers) you're dealing with people who have a valid phone number for you. ------------------------------ Date: 9 August 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to the newly automated , with first text line SUBSCRIBE or UNSUBSCRIBE [with option of E-mail address if not the same as FROM: on the same line]. HELP gives instructions on using the Majordomo listserver in other ways, although not all are implemented for RISKS. CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.31 ************************