Text File

precedence: bulk Subject: Risks Digest 20.08

RISKS-LIST: Risks-Forum Digest Sunday 15 November 1998 Volume 20 : Issue 08

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 http://catless.ncl.ac.uk/Risks/20.08.html and at ftp.sri.com/risks/ .

Contents: Sweden recommends banning mobile telephones on ships (Heinrich Hetzel via Robert Hettinga) *Very* hairy bug in Excel 4.0 and Excel 98... (Lindsay Marshall) Identity theft defeated by victim's wife (Jim Griffith) Electronic Commerce: The Future of Fraud (Bruce Schneier) Password capturing (Bill Carton) REVIEW: "Virus Alert of the Day", virus-alert@optimator.win.net (Rob Slade) REVIEW: "VirusHelp", Henri Delger (Rob Slade) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Sat, 14 Nov 1998 22:58:54 +0100 From: "Heinrich Hetzel" <hwh@email.com> Subject: Sweden recommends banning mobile telephones on ships

[Forwarded to RISKS by Robert Hettinga <rah@shipwright.com>. PGN]

The Swedish National Maritime Administration has recommended that shipping firms ban the use of mobile telephones aboard ships. In Norway recently, a man aboard a ship used a phone on the foredeck, at which time the ship's rudder suddenly swung hard over while the vessel was on autopilot. After the ship returned to its course, he again tried to use the phone and the autopilot again made a course change. It is believed that the phone's magnetic pulse interfered with the autopilot's operation. While Det Norske Veritas is studing the problem, Sweden is recommending such phones be banned for the time being.

Above copied from notice to mariners.

I had a few turns close to an airport, but I never found out what triggered them.

Anyone else with unexplained unexpected course changes?

From WORLDCRUISING SUBSCRIPTION PAGE - http://window.to/worldcruising CHAT ROOM: http://www.infohouse.com/amelia/cruisers-connection/wcchat.htm

------------------------------

Date: Fri, 13 Nov 1998 10:14:50 +0000 (GMT) From: Lindsay.Marshall@newcastle.ac.uk Subject: *Very* hairy bug in Excel 4.0 and Excel 98...

This from Macintouch: http://www.macintouch.com

> We have verified a serious Excel bug reported on the Mac Managers mailing > list today: If you have a hard disk and a floppy both with the same name, > Excel will save a file onto the hard drive when you tell it to save to the > floppy. Among other nasty problems, this may succeed in bypassing disk > security controls provided by such programs as At Ease. More details: > "Excel is the only application I've seen that exhibits this behavior. Both > Excel 4.0 and Excel 98. It gets worse. If you create a folder hierarchy on > the floppy that mimics the hard drive, you can save files anywhere on the > hard drive. It gets even worse. It lets you replace a file with the same > name. It doesn't even prompt you with the "file already exists" > dialog. For example, I just saved an Excel spreadsheet called Finder. I > tried to save it in a folder called "System Folder" on an otherwise empty > floppy disk called "Macintosh HD." It did exactly what you'd think it > would do."

------------------------------

Date: Fri, 13 Nov 1998 15:48:20 -0800 (PST) From: Jim Griffith <griffith@netcom.com> Subject: Identity theft defeated by victim's wife

AP reports an unusual ending to an identity theft case. A man in North Carolina attempted to open a checking account at a BB&T branch by presenting relevant information, including birthdate and Social Security number. One of the bank's tellers examined the paperwork, and she called the police after she realized that the information described her husband, who had died three weeks earlier. Police charged the suspect with two charges of obtaining property under false pretenses, and they are investigating how the suspect obtained the dead man's information and birth certificate.

------------------------------

Date: Fri, 13 Nov 1998 18:31:03 -0600 From: Bruce Schneier <schneier@counterpane.com> Subject: Electronic Commerce: The Future of Fraud

[This appeared in my November newsletter, CRYPTO-GRAM, http://www.counterpane.com/crypto-gram.html, but I thought it is of general enough interest to send it here.]

Electronic Commerce: The Future of Fraud

Fraud has been perpetrated against every commerce system man has ever invented, from gold coin to stock certificates to paper checks to credit cards. Electronic commerce systems will be no different; if that's where the money is, that's where the crime will be. The threats are exactly the same.

Most fraud against existing electronic commerce systems -- ATM machines, electronic check systems, stored value tokens -- has been low tech. No matter how bad the cryptographic and computer security safeguards, most criminals bypass them entirely and focus on procedural problems, human oversight, and old-fashioned physical theft. Why attack subtle information security systems when you can just haul an ATM machine away in a truck?

This implies that new commerce systems don't have to be secure, but just better than what exists. Don't outrun the bear, just outrun the people you're with. Unfortunately, there are three features of electronic commerce that are likely to make fraud more devastating.

One, the ease of automation. The same automation that makes electronic commerce systems more efficient than paper systems also makes fraud more efficient. A particular fraud that might have taken a criminal ten minutes to execute on paper can be completed with a single keystroke, or automatically while he sleeps. Low-value frauds, that fell below the radar in paper systems, become dangerous in the electronic world. No one cares if it is possible to counterfeit nickels. However, if a criminal can mint electronic nickels, he might make a million dollars in a week. A pickpocketing technique that works once in ten thousand tries would starve a criminal on the streets, but he might get thirty successes a day on the net.

Two, the difficulty of isolating jurisdiction. The electronic world is a world without geography. A criminal doesn't have to be physically near a system he is defrauding; he can attack Citibank in New York from St. Petersburg. He can jurisdiction shop, and launch his attacks from countries with poor criminal laws, inadequate police forces, and lax extradition treaties.

And three, the speed of propagation. News travels fast on the Internet. Counterfeiting paper money takes skill, equipment, and organization. If one or two or even a hundred people can do it, so what? It's a crime, but it won't affect the money supply. But if someone figures out how to defraud an electronic commerce system and posts a program on the Internet, a thousand people could have it in an hour, a hundred thousand in a week. This could easily bring down a currency. And only the first attacker needs skill; everyone else can just use software. "Click here to drop the deutsche mark."

Cryptography has the potential to make electronic commerce systems safer than paper systems, but not in the ways most people think. Encryption and digital signatures are important, but secure audit trails are even more important. Systems based on long-term relationships, like credit cards and checking accounts, are safer than anonymous systems like cash. But identity theft is so easy that systems based solely on identity are doomed.

Preventing crime in electronic commerce is important, but more important is to be able to detect it. We don't prevent crime in our society. We detect crime after the fact, gather enough evidence to convince a neutral third party of the criminal's guilt, and hope that the punishment provides a back-channel of prevention. Electronic commerce systems should have the same goals. They should be able to detect that fraud has taken place and finger the guilty. And more important, they should be able to provide irrefutable evidence that can convict the guilty in court.

Perfect solutions are not required -- there are hundred of millions of dollars lost to credit card fraud every year -- but systems that can be broken completely are unacceptable. It's vital that attacks cannot be automated and reproduced without skill. Traditionally, fraud-prevention has been a game of catch-up. A commerce system is introduced, a particular type of fraud is discovered, and the system is patched. Money is made harder to counterfeit. Online credit card verification makes fraud harder. Checks are printed on special paper that makes them harder to alter. These patches reduce fraud for a while, until another attack is discovered. And the cycle continues.

The electronic world moves too fast for this cycle. A serious flaw in an electronic commerce system could bankrupt a company in days. Today's systems must anticipate future attacks. Any successful electronic commerce system is likely to remain in use for ten years or more. It must be able to withstand the future: smarter attackers, more computational power, and greater incentives to subvert a widespread system. There won't be time to upgrade them in the field.

[Note: Why Cryptography is Harder Than it Looks appeared in RISKS-18.59, and is also at http://www.counterpane.com/whycrypto.html ]

Security Pitfalls in Cryptography: http://www.counterpane.com/pitfalls.html

Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com

------------------------------

Date: Thu, 12 Nov 1998 10:14:21 -0800 From: Bill Carton <bill_carton@credence.com> Subject: Password capturing

A new web site was featured on the 10 Nov 1998 morning TV spot, Bloomberg Tech Report: www.thatweb.com. It purports to be a single site from which you can download POP mail from your personal ISP, in case you're behind a firewall at work, for instance.

It asks for your e-mail address and password, and in response to signing up, spits out seven pages of legal boilerplate that says you agree to not use their service to spam, harass, or other "illegal or immoral purposes". The typos made me think it was not a native English-speaker who set this up, and indeed, the Webmaster replied from Singapore. The site is not secure, of course.

So why did Bloomberg's reporter feature this GAPING security hole? Unclear.

I wrote them:

> > From: bill_carton@credence.com > > Sent: Thursday, November 12, 1998 7:04 AM > > To: webmaster@thatweb.com > > Subject: Privacy and Security > > > > Since you have the capability to capture and archive individuals' > > passwords, common sense requires you to provide a privacy and > > security statement. > > > > I see none on your Web site. Please supply your potential users with > > something that can be verified by someone of an unimpeachable > > reputation who is known by net security experts. > > > > Otherwise, your site seems indistinguishable from a login screen > > spoofer - and will only be used by clueless newbies. Is that the > > audience your advertisers want to be paying for? A very poor > > demographic indeed. > > > > At the very least, it needs to be a secure site, but you will have > > to do a LOT more to gain the trust of the net community. Do you > > read comp.risks? You should. > > > > Bill Carton

Mun Hon Pheng - PO wrote: > > Dear Sir, > > Thank you for your suggestion. We are indeed working on making this site a > secure site with the necessary protection for data privacy and security.

No, I believe you do not understand. Your Web site should not have been placed on the Web in its current condition. It MUST have been secure on Day #1. You cannot make it secure now, and have anyone trust it. Your reputation is already damaged, and you have no credibility with anyone who has been thinking deeply about security issues.

> Would appreciate it if you can recommend someone with unimpeachable > reputation for knowledge of net security that we can consult regarding > verification of our security procedure and set up.

Again, are you familiar with the usenet newsgroup comp.risks? You should have had someone on your staff already to answer these questions and prevent you from going public until they were adequately answered.

> We value your comments and suggestion. As we are incrementally improving > our Web site, would appreciate your regular visit and follow up comments to > help us improve.

My most basic comment is that this site should not be on the Web today. It is a serious security risk to anyone who is thoughtless enough to use it. E-mail security is a serious professional issue, and you have shown your disregard for those issues by your appearance on the net.

Please tell me what prevents you from keeping a file containing your user's e-mail addresses and passwords, and then downloading their mail for your own purposes? The public has NO ASSURANCE that you cannot or will not steal their mail, read their messages, and use any information you discover for your own purposes. Claiming you will not do these things is not sufficient! You are indistinguishable from thieves who might claim the identical things.

The burden of proof is on *you* sirs, to prove your good intentions, and demonstrate you have taken proper precautions for data privacy and security. You should be familiar with an old trick, used for decades at computer centers at colleges. A program is left running on a terminal, whose entire appearance is identical to a login display. Then the thief leaves the room. A second user, the victim, then sits down and innocently types in his login name and password. The running program captures this information, e-mails it to the first person, and then exits. The victim thinks his login attempt has just failed, and tries again. This time it works OK. But the first person now has the victim's login name and password.

To a security-thinking individual (and there are thousands like me) - you have just created a Web-based version of this. It is up to YOU to convince US that it is not true. If you cannot, then we will do everything possible to educate your potential victims to avoid using your site. These issues are already being discussed on the usenet newsgroup news.admin.net-abuse.email.

We await your reply at your earliest convenience.

Thank you, Bill Carton

Credence Systems Corporation, 9000 SW Nimbus Ave., Beaverton;OR;97008 bill_carton@credence.com 1-503-350-7655

------------------------------

Date: Thu, 12 Nov 1998 09:45:53 -0800 From: "Rob Slade" <rslade@sprint.ca> Subject: REVIEW: "Virus Alert of the Day", virus-alert@optimator.win.net

MLVAOTD.RVW 981016

"Virus Alert of the Day", virus-alert@optimator.win.net, 1998, http://www.tipworld.com/changes.html %A virus-alert@optimator.win.net %C City (place of publication) %D 1998 %I TipWorld %O http://www.tipworld.com/changes.html %P 1 paragraph daily %T "Virus Alert of the Day"

Aside from VirusHelp (cf. MLVIRHLP.RVW) and the rather noisy alt.comp.virus, there is one other regular source of virus information. No discussion, since this is a one way list, but one more source of clutter for your mailbox.

Virus Alert of the Day is one of the (very many) TipWorld mailing lists. Like all of them, it is primarily an advertising tool, so expect a lot of ads. In the case of the virus alert list, you can expect roughly a one paragraph tip per day, along with several screens of commercial announcements of various types. Actually, that is not quite true. There is usually about a screenful of viruses due to go off on the day in question. However, this is only a list of names, without descriptions, and there are, of course, a great many viruses that can go off on any day, or are not subject to date alerts.

The information provided by this list is highly suspect. The author, and the closest I've been able to get to an identity is virus-alert@optimator.win.net, provides very little information, and does not betray much basic fact, let alone conceptual, checking in the postings. (Yes, doing it on a daily basis is hard, but remember that I ran the CVP postings for three solid years, week in and week out, and wasn't even close to running out of material.) Some comes from recycled press releases alerting users to new viruses or types. Sometimes the tip of the day is simply an announcement of a new antiviral release, ensuring that the entire message for the day is one long string of ads. But sometimes when the list actually tries to help it does the greatest disservice.

Let's look at three postings from the recent past. On September 10th, readers were advised to "Lock your floppies." Apparently, if you just "flip the `switch' up on the top-left corner on the back of the diskette ... you can prevent diskette-transferred viruses from being loaded onto your PC." Now, it's very nice that the instructions were that detailed, but, unfortunately, they were flat out wrong. If your computer is already infected, then locking your floppy disks may keep viruses off the floppy. But if your diskette is infected, locking it will do nothing to protect your computer. (This tip was later corrected by a reader.)

September 16th saw a note from a reader wondering what to do about an infection by a stealth, boot sector virus. He had tried various antivirals and none had removed it. The advice was to wait until the antiviral vendors got around to a release that did deal with it. Unfortunately, a number of the antivirals the reader had mentioned do deal with the virus, and quite effectively. The real secret in this case is to ensure that you "boot clean" and ensure that the virus is not resident in memory before you try to run the antiviral. The secret to booting clean is to ensure that your boot disk was created before the virus infected the system.

October 2nd saw the relaying of Symantec's report of the world's first Java virus. This viral non-event was widely ignored by the virus research community, since everyone had already known it was possible. Java is a computer language much like any other, and you can write anything you want in it. The potential threat of a Java virus lies in Java's ability to create applets for the Web. Fortunately for Web users, and unfortunately for "Strange Brew," applets submitted over the Web and run in browsers are confined to a "sandbox" that restricts some of the operations which "Strange Brew" needs in order to run.

On October 16th, users of Microsoft Word were told, in order to avoid spreading MS Word macro viruses, to save files in RTF (Rich Text Format) if they were going to send them to other users. Now, while this advice might be inconvenient (RTF is not capable of saving all possible MS Word formatting information), there is some valid reasoning behind using it as a security precaution. RTF does not support MS Word macro viruses, either, so an RTF file wouldn't transmit them. A *true* RTF file, that is. A number of common macro viruses intercept the FileSaveAs call. CAP, for one, will save the file as a template document, with the infection present, in spite of the RTF extension on the filename.

Should you wish to chronicle the further misadventures of the virus alerts, check out the TipWorld signup page at http://www.tipworld.com/changes.html.

copyright Robert M. Slade, 1998 MLVAOTD.RVW 981016

------------------------------

Date: Fri, 13 Nov 1998 11:22:02 -0800 From: "Rob Slade" <rslade@sprint.ca> Subject: REVIEW: "VirusHelp", Henri Delger

MLVIRHLP.RVW 981011

"VirusHelp", Henri Delger, 1995, http://goodstuff.prodigy.com/Mailing_Lists/virushelp.html %A Henri Delger henri_delger@prodigy.com %D 1995 %O http://pages.prodigy.com/virushelp/vhelp.htm %P ~ 10 p. monthly %T "VirusHelp"

VirusHelp does not predate the creation of the alt.comp.virus newsgroup, but with the current suspension of the VIRUS-L/comp.virus list it forms the oldest and most reliable ongoing interactive virus information resource on the net. Moderated by Henri Delger, it is not something you can set your watch by, but you can generally expect at least two issues per month.

Each issue contains several questions or comments from readers, generally with answers or expansion from Mr. Delger. However, there are numerous leading antiviral experts who subscribe to the list as well, and who may write in with answers or information. Because of the moderation the quality of the discussion is very high, although traffic is relatively low.

In comparison to other virus lists and groups, many messages relate to the operation, strengths, and weaknesses of specific antiviral software. Other discussions include the usual calls for help when noticing some strange happening, as well as warnings about new viruses or trojans on the loose. Debate about potential, but not actual, new virus operations or concepts related to viral or antiviral technology is not unknown. Although the majority of messages are associated with Wintel systems other platforms are not excluded and messages about Macs, for example, are proportionately much higher than on other lists.

Generally the moderator will comment on all messages received, even those providing, or purporting to provide, information. Virus "experts" seem to grow under every bush, so Delger is quite free with correction when it is called for. He is free with opinion, but clearly indicates it as such.

Each issue also contains a large, if not exhaustive, list of recent antiviral software releases for a number of operating systems. The inventory specifies software, filename and release date, although the location of the file is left to the reader. (If you are a Prodigy subscriber, all of the listed files are available from a library there, and Delger does provide a list of vendor sites.) A recent addition has been a consistent warning against Internet hoaxes, particularly false virus alerts.

Subscriptions are free of charge, and may be obtained via the Web at: http://pages.prodigy.com/virushelp/vhelp.htm General virus information and back issues of VirusHelp are available at http://pages.prodigy.com/virushelp/ or the mirror at http://pages.prodigy.net/henri_delger/index.htm. Messages to the list itself can be addressed to virushelp@listserv.prodigy.com.

copyright Robert M. Slade, 1998 MLVIRHLP.RVW 981011

------------------------------

Date: 23 Sep 1998 (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 DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => 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.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

------------------------------

End of RISKS-FORUM Digest 20.08 ************************