The RISKS Digest
Volume 20 Issue 08

Sunday, 15th November 1998

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

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
Info on RISKS (comp.risks)

Sweden recommends banning mobile telephones on ships

"Heinrich Hetzel" <hwh@email.com>
Sat, 14 Nov 1998 22:58:54 +0100
  [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


*Very* hairy bug in Excel 4.0 and Excel 98...

<Lindsay.Marshall@newcastle.ac.uk>
Fri, 13 Nov 1998 10:14:50 +0000 (GMT)
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."


Identity theft defeated by victim's wife

Jim Griffith <griffith@netcom.com>
Fri, 13 Nov 1998 15:48:20 -0800 (PST)
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.


Electronic Commerce: The Future of Fraud

Bruce Schneier <schneier@counterpane.com>
Fri, 13 Nov 1998 18:31:03 -0600
  [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


Password capturing

Bill Carton <bill_carton@credence.com>
Thu, 12 Nov 1998 10:14:21 -0800
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


REVIEW: "Virus Alert of the Day", virus-alert@optimator.win.net

"Rob Slade" <rslade@sprint.ca>
Thu, 12 Nov 1998 09:45:53 -0800
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


REVIEW: "VirusHelp", Henri Delger

"Rob Slade" <rslade@sprint.ca>
Fri, 13 Nov 1998 11:22:02 -0800
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

Please report problems with the web pages to the maintainer

x
Top