precedence: bulk Subject: Risks Digest 21.72 RISKS-LIST: Risks-Forum Digest Tuesday 30 October 2001 Volume 21 : Issue 72 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, caveats, etc. ***** This issue is archived at and by anonymous ftp at ftp.sri.com, cd risks . Contents: TD Bank Canada system crash (Richard Akerman) ANOTHER SRI-wide Power Outage (PGN) ACT Election Electronic Voting (Josh Polette) Project Liberty (Jay R. Ashworth) Re: Are spammers getting sneakier? (Crispin Cowan) Re: Are spammers getting sneakier? - Yes, they are (Greg Searle) USPS correction (Ken) NSF Trusted Computing program (Carl E. Landwehr) REVIEW: "Malicious Mobile Code", Roger A. Grimes (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 30 Oct 2001 09:53:43 -0400 (AST) From: Richard Akerman Subject: TD Bank Canada system crash This past weekend in Canada, one of our 5 major banks, the Toronto-Dominion, experienced a serious systems failure. This caused particular problems because Canadians use debit cards more than any other nation, in fact, many people (including me) carry only a debit card and credit card in their wallet, and no cash. The Tuesday, October 30, 2001 _Globe and Mail_ reports in "TD aims to clear backlog following system crash" that: 'The crash was caused by the failure of a single "motherboard" in one of the bank's central computers at about 11 a.m. Saturday [Oct 27, 2001]. This "gradually started to shut down the system" to "protect the integrity" of the data already there, Mr. Livingston [head of TD electronic banking] said.' Then this remarkable statement 'It was a purely random event," he said, adding that hardware failures are rare. "This has never happened before, and it will likely never happen again."' and ending with 'As TD sought to identify and fix the problem, "a few million transactions" were rejected by the bank's systems, which, on a busy Saturday, process up to 500 transactions a second, he said. The bank's computer systems have all sorts of "redundancies" built in to try to protect against failures, but the incident on Saturday "just shows you can't protect against the random element," Mr. Livingston said.' This seems to me to be a remarkable design philosophy. Richard J. Akerman http://www.chebucto.ns.ca/~rakerman/ ------------------------------ Date: Sat, 27 Oct 2001 13:45:33 -0700 From: "Peter G. Neumann" Subject: ANOTHER SRI-wide Power Outage Despite our carefully conceived phased UPS systems, standby generators, and co-generation plant designed to keep SRI in continuous power, we experienced a site-wide power outage Saturday morning that took everything electrical down with it. Thanks to Dave Stringer-Calvert for sharing the punch-line from an SRI facilities memo: "The power outage was caused when Cogen staff pressed the wrong button and took the facility off-line." ------------------------------ Date: Thu, 25 Oct 2001 19:54:31 +1000 From: joshpolette@ozemail.com.au Subject: ACT Election Electronic Voting The recent ACT Assembly Elections created a first in Australian political history by introducing electronic voting. It was not a full scale implementation with electronic voting limited primarily to pre-poll voting and to a small number of polling stations on election day. Electronic voting was intended to provide great benefits in vote counting because of the complexity of the Hare-Clark system. However, this was not to be. There was a floor in the architecture of the system. The system was designed to allow live results to be viewed on the Internet. Unfortunately, the same server that was doing the number crunching (ie, counting the votes) was also the one serving information to the Internet. As a result, the rate of vote counting was severely impacted by the load placed on the server by voters eager to see the results. URL: http://news.ninemsn.com.au/Sci_tech/story_20717.asp There are several causes for concern in this article, primarily because of the sensitivity of the subject (ie, election vote counting). After the fiasco in the US Presidential elections over ballot paper design and counting, there was a call for electronic voting to be introduced. The theory being that computers are never wrong. However, the ACT experience shows that it is not guaranteed. While there is no evidence that vote tampering has occurred it is of concern that Internet activity can affect the counting process of an election. Surely, the counting system should be isolated from the Internet with only a copy of the interim results stored in a separate, Internet accessible server? What is really worrying is that the article doesn't say whether the actual web server was running on the vote counting server or not. Given the severe impact on counting performance, one has to wonder. Josh Polette, Engineering Manager, JCSS, ADI Limited, C4ISR, IS3 Phone: 02 6247 6854 Fax: 02 6247 7864 joshpolette@ozemail.com.au ------------------------------ Date: Tue, 23 Oct 2001 14:17:16 -0400 From: "Jay R. Ashworth" Subject: Project Liberty In last week's Linux Weekly News, there was some preliminary coverage of Project Liberty, an "open" alternative to Microsoft's Hailstorm, which is -- very roughly -- an a attempt to embed Passport into everything on the planet. The short version is: a repository of information about your person, life, and preferences which can be accessed by people and companies you authorise, to provide authentication that you are you, and information about, for example, your purchase default desires (credit-card numbers, which card to use, do you prefer first class or coach, etc). Now, this is, fundamentally, not an especially bad idea. But how it is implemented is -- given the sort of information which it might end up holding -- pretty crucial to your personal privacy: do you want anyone except your doctor and your pharmacist knowing that you have a prescription for protease inhibitors? (Drugs used to control AIDS and related conditions.) You probably don't even want your *health insurer* to know that, even though perhaps you want them to know *other* things about you, and therein lies the major problem: Hailstorm will be run by Microsoft. And we all know how pristine Microsoft's track record is for placing the interests of individuals above that of large corporations off of whom Microsoft makes lots of money. Right? So here comes Project Liberty, an "open" alternative to this. They've not much design done yet, I don't think, so we don't know what *specific* goals PL will be aiming towards. But that's good, because it means that this is the exact time for private individuals to be casting their bets on what they think is important: personal privacy and control are good choices there, IMHO. I know that in our New World, it's almost unpatriotic to be concerned about personal privacy, but you know what? That's a wrongheaded, short sighted, and dangerous outlook to have. Our country became something to be proud of, protect, and defend precisely *because* it attempted to secure such liberties to the people against government control, and corporations should be given no extra leash -- they work for *us*, in the final analysis, just like the government. But the most fundamental tenet of Project Liberty's operation must be, for it to succeed, that it will always favor the desires and interests of those one billion people whose identities it likes to tout it's representation of *over* the interests of the corporations with all the money. >From a design standpoint, it must make it possible to break down your information to a sufficiently fine granularity to allow you to authorize access for someone to only the data which you want them to have... and indeed, to make it as difficult as possible for different providers to cross-correlate the information the hold privately about you with one another. (Why do I get my cablemode service from one company, my wireless Internet from someone else, and my cellphone service from yet another company? Because I *can*, and because it one bill is late, I don't get cut off from all three. Do I want to give that flexibility up? Certainly not.) Ensuring that the provision of the convenience of "single-sign on" won't deprive me of rights and conveniences I now have won't necessarily be easy for the Project Liberty folks. But if they don't do it, and stick to it, then I will not -- and you should not -- give them any more quarter than Microsoft. Regardless of whom they have on their side. Jay R. Ashworth, Member of the Technical Staff Baylink, The Suncoast Freenet Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 jra@baylink.com ------------------------------ Date: Fri, 26 Oct 2001 16:43:10 -0700 From: Crispin Cowan Subject: Re: Are spammers getting sneakier? (Slade, RISKS-21.71) The "may be forged" note is a standard indication from the MTA (Mail Transfer Agent, i.e., mail server) that the host the MTA is receiving this mail from cannot successfully be reverse-DNS'd. If the MTA did reverse DNS on the originating IP and got a different name, it would have told you that. As it is, it is just saying that it doesn't trust the claim that this is from triton.net. Given the fairly prolific amount of inaccurate reverse DNS info out there, this isn't even a reliable indication that a give piece of e-mail is spam. But in the context that Slade provides (multiple forged headers, stupid generic query) it is a good bet. I've seen it many, many times in the last couple of years of spam-fighting. The earliest instance I have a record of is August 1998, but that's only because that is literally the oldest archived spam that I have. Since then I have logged approximately 2000 occurrences of such spam. An interesting result of this investigation: the frequency has dropped sharply in recent years, although spam frequency certainly has not. Whatever spam technique causes this to occur appears to be falling out of favor. Crispin Cowan, Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org ------------------------------ Date: Fri, 26 Oct 2001 12:28:45 -0400 From: "Greg Searle" Subject: Re: Are spammers getting sneakier? - Yes, they are Here's the bag of tricks that many spammers are using to keep you from finding out who really sent you the spam: 1. The obvious - find an open e-mail relay, and use it for "e-mail laundering". Forge the e-mail headers, and the e-mail becomes untraceable. All you see is the IP for the open relay, and whatever the spammer wants you to see afterward. The "From" header is always forged, and complaining to the ISP behind the "From" address is pointless. The most you can do is complain to the company that owns the open relay, and hopefully they will close it. Unfortunately, new mail servers appear on the net every day, and many IT "professionals" setting up these systems are just not aware of the open relay problem. There are many web pages which have the sole purpose of finding and listing these open relays. 2. Include a "relay" URL in the spam for potential customers. This URL is typically a "throwaway" account opened on one of the many free webpage services (tripod, geocities, angelfire, etc.) with false credentials. The spammer only expects this URL to exist for a day or two, as the provider will quickly terminate the page once complaints start coming in. The URL typically points to a file or page that will redirect the customer to the true page. 3. There are some businesses that are specifically set up to relay URLs for spammers. One of these is 1freesite.net (G Stubberfield Enterprises). Spammers hire the business to set up a relay page on their server, so they can include this page in their e-mails. 4. Obfuscate the URL in an attempt to make it untraceable. Do you know that IP addresses can be expressed as a single, decimal digit? Browsers will accept this digit and translate it into a valid IP address. Encoding the URL in hex is another trick. Browsers will convert two-digit hex digits that are preceded by a percent sign into a valid character. The URL specification also allows usernames and passwords in a URL. This can be used to mislead. For instance, the URL http://www.webservice.com:www.server.com@192.168.10.10/spampage.html seems to point to "webservice.com", but the piece of the URL before the second colon is really the "username", the piece before the at sign is the "password", and the real web server is the IP after the at sign! Most web servers simply ignore the user name and password if they don't need it. These techniques can be combined to make a URL really hard for a person to decode. 5. Compose the relay webpage in JavaScript. Encrypt the "real" web page and any URL's, and have a JavaScript function decode it. 6. Ask customers to respond to the message. Include a valid "Reply To" header that is different from the "From" header. The e-mail client will recognize this and send any responses to the "Reply To" address. The e-mail account set up to receive these messages is usually a "throwaway" address set up on a free mail service with false credentials. 7. Include an unlisted phone number, which is protected by the telephone company and is untraceable. 8. Included an executable at the URL enclosed in the message. This executable is typically compressed to obfuscate its contents from prying binary file editors. The executable then forwards the customer's computer to the business's true URL. Anybody who opens this executable file is too ignorant to know any better. All of these methods, except for the telephone number and the reply-to address, are completely reversible to expose the company behind the e-mail. If the computer can get to the final page, then so can the person operating the computer, given enough knowledge of the technology involved. There is one particularly nasty spammer, hosted at sexmansion.com and web69.com, that includes a doubly-compressed executable in the page that they set up on a "throwaway" site. Their extremely explicit e-mailings point to this executable's URL. This executable is a dialer application that redirects the user's modem to an offshore telephone number and sends their browser to one of the above mentioned domains. This appears as a charge on their telephone bill. This business was rather clever with the obfuscating technology used to hide their presence, but the same technology can be used to unravel the obfuscation and find the business behind it. ------------------------------ Date: Wed, 24 Oct 2001 22:30:54 -0400 From: Ken Subject: USPS correction (Re: Improper address-change validation) >... the advisory went to the new address, along with all the old mail. Actually, their policy is slightly better than this; they send advisories to both the old and the new addresses. So, in theory, you can rush to the post office upon receiving the advisory and at least stop them from forwarding any additional mail. Not terribly secure (no attempt is ever made to verify your identity), and it depends on you successfully receiving the advisory, but it's still slightly better than cutting your old address off altogether. kenzo@free-music.com [... but not much help if you are away for a month. PGN] ------------------------------ Date: Thu, 25 Oct 2001 14:56:01 -0400 From: "Landwehr, Carl E." Subject: NSF Trusted Computing program [Carl Landwehr, erstwhile security guru at the U.S. Naval Research Lab and more recently at Mitretek, is now on a one-year leave at the National Science Foundation, as Director of the Trusted Computing program. NSF is a good source of funding, and this procurement should be of interest to many RISKS readers. As always, I recommend that we focus on developing TRUSTWORTHY systems, not just UNTRUSTWORTHY systems that have to be TRUSTED because we have no alternative. PGN] The initial announcement for the new Trusted Computing program is at: http://www.nsf.gov/pubs/2001/nsf01160/nsf01160.html The deadline for proposals is 5 Dec 2001; if you are in a position to conduct research in this area, I encourage you to consider submitting a proposal. NSF focuses on funding research at universities and not-for-profit organizations. I also hope you will consider helping me staff the review panels for the proposals that are submitted. My new contact information is provided below; please use this e-mail address for future correspondence. Carl E. Landwehr, Program Director, Trusted Computing, CISE/CCR, Suite 1175 National Science Foundation, 4201 Wilson Blvd., Arlington, VA 22230 e-mail: clandweh@nsf.gov phone: 703-292-8936 fax: 703-292-9059 ------------------------------ Date: Mon, 29 Oct 2001 08:00:43 -0800 From: Rob Slade Subject: REVIEW: "Malicious Mobile Code", Roger A. Grimes BKMLMBCD.RVW 20010814 "Malicious Mobile Code", Roger A. Grimes, 2001, 1-56592-682-X, U$39.95/C$59.95 %A Roger A. Grimes roger@rogeragrimes.com %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 2001 %G 1-56592-682-X %I O'Reilly & Associates, Inc. %O U$39.95/C$59.95 800-998-9938 fax: 707-829-0104 nuts@ora.com %P 522 p. %T "Malicious Mobile Code: Virus Protection for Windows" I have to admit to a very definite bias. My co-authors and I have just finished a book that attempts to provide up to date virus protection information to sysadmins. As I understand it, ours will be printed about three weeks after this one. I also have a problem with the title. Grimes appears to be trying to carve himself out a niche by promoting a term that nobody else is currently using. And the subtitle should more properly be, "Risk Mitigation for Microsoft Software." However, if you are using Windows, there is a good deal of information is this book that, with some diligence and additional work on your part, can help improve your security. Grimes starts off the book by listing some fallacies that we have always believed. "You can't get a virus by simply reading an e-mail." (OK, Microsoft has amply demonstrated that they've added virus capabilities to their mail software.) "Malicious code can't harm hardware." (Well, quibbles about terminology aside, it usually can't.) "A virus can't hide from a booted write-protected diskette." (Ummm, I'm not sure that sentence even *means* anything.) Melissa and the Love Bug were serious nuisances, and even worse, but is it really accurate to say that they shut down tens of thousands of networks? This book is intended for intermediate and advanced users and system administrators, and addresses only the Microsoft Windows operating systems. While I would agree that Windows is the system most in need of virus protection and help, this focus does limit the audience. Grimes also tries to avoid the virus/worm/replicating trojan argument with the use of the term malicious mobile code, and states that the book does not deal with attacks and security holes, but the coverage of trojans, RATs (Remote Access/Administration Trojans/Tools), and browser attacks seems to contradict that position. (In fact, the more detailed description of "malicious mobile code," and the MMC acronym that Grimes creates, seems to be amply covered under the more commonly used term malware.) Chapter one provides a very brief outline of some malware related concepts. Most of the chapter concentrates on the virus writing community, although only in a superficial way. Grimes obviously feels sympathetic towards virus writers, and presents their own stories without criticism or analysis. Some details of the MS-DOS operating system, as well as basic virus technologies, are given in chapter two. The programming particulars, and a bit of virus source code, are likely to be of more help to budding virus writers than to the defending sysadmins. There are copious errors in the information listed about specific viruses. Sometimes the material is careless, such as the assertion that Michelangelo formats hard drives (the original version overwrites sections of the disk, and only the disk booted from on the trigger date). In other places the wording is slipshod, such as the implication that a seldom seen screen artifact of the Jerusalem virus is somehow responsible for file deletion. (Oddly, while Grimes does not appear to have done serious research he has obviously read my stuff at some point: one of the examples is taken almost word for word from my writings. Other passages originating in my work are recognizable, although not quite as blatant.) The recovery advice is also suspect: he reiterates the rather dangerous suggestions to format the disk or use FDISK /MBR. Some very useful information about Windows, particularly the 9x, NT, and higher versions, is presented in chapter three. The material does not often deal with malware as such, and, in a number of cases, details are either too particular or not specific enough. A few "native" Windows viruses are described in chapter four, along with some useful general security and recovery tips. Unfortunately, the virus detection and recovery tips are derivative, vague, and not always comprehensive. Chapter five has explanations of the VBA (Visual Basic for Applications) macro system in Microsoft Office applications, and lists some common macro viruses. Chapter six lumps trojans, worms, backdoors, and DDoS (Distributed Denial of Service) packages together in a somewhat confusing manner. One useful inclusion in the material is a list of RAT utilized port numbers. The invention of real-time conferencing, or instant messaging, appears to be credited to AOL, in chapter seven, although various forms existed long before AOL's existence. All forms of chat or messaging seem to be lumped together in the chapter, although it concentrates on the technology and examples from IRC (Internet Relay Chat). Chapter eight contains a reasonable overview of Web browser technologies, although Grimes makes the usual mistakes, such as confusing Secure HyperText Transfer Protocol (S-HTTP) with the https protocol specifier actually used by Secure Sockets Layer (SSL). A number of old program bugs and exploits are described in chapter nine. Most relate to browsers, although some depend on HTML enabled mail clients. The preventive measures listed, however, deal strictly with the settings on recent versions of Microsoft's Internet Explorer, and do not mention other browsers at all. Since Java applet bugs and exploits have been confined to implementation errors, it is difficult to understand why chapter ten was included in the book. Again, some older exploits are described, and there is a bit of confusion in the text between the applet sandbox model and the full Java security model. Chapter eleven examines the possibility of the malicious misuses of the ActiveX system, but first it spends a lot of time and space presenting the one security aspect of ActiveX: digital signatures. By doing so, Grimes is giving Microsoft way more than the benefit of the doubt. The text does, eventually, get around to pointing out some of the flaws in the Authenticode system, but the structure of the chapter works to downplay the dangers. In chapter twelve, the Microsoft chauvinism that has been evident in prior sections ramps up to full throttle. Grimes states that it isn't just Outlook that can be exploited for e-mail viruses, any mail client could be so abused. (He later has to tacitly admit that almost no other e-mail client has been so utilized, and none to the same extent.) There is even a paean of praise to Windows Script Host, the application that made the Love Bug possible. The material on virus hoaxes, in chapter thirteen, is a bit of a mix, but does have a good list of signs to watch for. Defence consists mainly of a generic security planning process and a reasonable, though brief, outline of the types of antiviral software, in chapter fourteen. Chapter fifteen finishes off with the usual look to the future. Overall, the content is wide-ranging, but not complete. There is coverage of a broader range of topics than was the case with other recent books, such as Dunham (cf. BKBVRTPR.RVW) and Schmauder (cf. BKVRSPRF.RVW). However, depth of research and understanding of the problem is not in evidence. The material is very questionable in view of the number of errors Grimes makes in his retailing of details of specific viruses. While some support and background content is included, the book is written in a very field independent style: at the end of the chapter you are simply supposed to do what Grimes tells you to, and believe what he says. There is virus code in the book. Not extensively, perhaps, but it is there. Grimes justifies its presence by saying that it is not code for an entire virus, and that he has made changes to disable it in any case. Unfortunately, it is real code, for some important sections of viruses, and the missing and changed bits aren't all that hard to spot. While it would not allow wannabe vxers to compile a complete virus right off the page, it would help any semi-competent code dweeb write a more functional virus. And, all protestations notwithstanding, it doesn't provide any help to the user or network manager. Aside from problems with the content, Grimes' organization and writing is careless and difficult to understand. The chapters address individual topics, and have a standard structure, but the structure is only a template. Within each topic the flow of sections and even paragraphs does not always course logically. The illustrations and figures are not very informative. This is not a good book on viruses or malware. The breadth of coverage and detailed content on macro and e-mail virus technology does save it from being really awful: up to the summer of 2001 no other book has dealt with those topics in sufficient depth. And the MS-centrism does have one very positive advantage. If you absolutely must use Microsoft software and applications, the prevention sections of the various chapters do contain a lot of detail that will be useful in reducing the risk that you face. copyright Robert M. Slade, 2001 BKMLMBCD.RVW 20010814 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 12 Feb 2001 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@CSL.sri.com . [If E-mail address differs from FROM: subscribe "other-address " ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .MIL users should contact (Dennis Rears). .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 21.72 ************************