[1464] in RISKS Forum
Risks Digest 20.33
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Sat Apr 24 20:55:53 1999
From: RISKS List Owner <risko@csl.sri.com>
Date: Sat, 24 Apr 99 17:52:58 PDT
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Saturday 24 April 1999 Volume 20 : Issue 33
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 <URL:http://catless.ncl.ac.uk/Risks/20.33.html>
and at ftp.sri.com/risks/ .
Contents:
Expert warns of safety glitch in shopping carts (Keith A Rhodes)
The CIH virus will strike Monday, April 26! (Satomi Hamamoto)
eBayla virus (Jeff E. Kinzli via Dave Farber)
Use a cable modem, go to jail (Lenny Foner)
Risks of over-helpful software (Jim Horning)
More on running a PKI (Steven M. Bellovin)
CompuServe responds to password-solicitation fraud (Mich Kabay)
"In order to make it easier for you" (T Bruce Tober)
Melissa, GUIDs, and VicodinES (Richard M. Smith)
Re: GUIDs and Melissa (Jiri Baum)
REVIEW: "Y2K Risk Management", Goldberg/Davis/Pegalis (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Fri, 23 Apr 1999 14:52:05 -0500
From: "Keith A Rhodes"<rhodesk.aimd@gao.gov>
Subject: Expert warns of safety glitch in shopping carts
Joe Harris of the Seattle-area Blarg! Online ISP has warned that commonly
used ``shopping-cart'' software has a vulnerability that when improperly
installed potentially exposes credit-card numbers and other personal
information. Harris found over 1000 sites on the Internet with this risk.
The article ends thusly: "When correctly installed, shopping cart software
creates a file for confidential information that is inaccessible to
outsiders." Well, maybe? Do you believe in PC security? [Source: item by
Jeff Wilson, Associated Press, 22 Apr 1999; PGN-ed]
------------------------------
Date: Fri, 23 Apr 1999 19:04:49 -0700
From: "Satomi Hamamoto" <toni.hamamoto@sri.com>
Subject: The CIH virus will strike Monday, April 26!
[From an internal SRI warning...]
Two variants of the W32.CIH.Spacefiller virus could seriously disable
unprotected PCs on Monday, April 26. Introduced in June 1998, variants 1.2
and 1.3 are set to detonate on April 26 and can affect Windows 95 and 98
executable files, bringing about data loss and system crashes. The virus can
spread over e-mail when infected executable files are sent as
attachments. IBM also recently reported that some Aptiva PCs manufactured in
March 1999 are infected with the virus.
To protect yourself against the CIH Virus, and to eliminate it
from your system:
Download kill_cih.exe, click here to direct link to the exec file:
http://insider.sri.com/is/antivirus/kill_cih.exe and save it at the
Desktop.
Double click on the file from your desktop.
After running kill_cih.exe, update your Norton AntiVirus virus
definitions, using the LiveUpdate feature.
To load Norton AntiVirus, go to Start --> Programs -->
Norton AntiVirus --> Norton AntiVirus
Click on the LiveUpdate button, and choose to update via the
Internet.
Then scan your computer using Norton AntiVirus.
Remember to select all drives then click on "Scan Now."
For more information, visit Symantec's Kill CIH website:
http://www.symantec.com/avcenter/kill_cih.html
------------------------------
Date: Thu, 22 Apr 1999 17:34:41 -0700
From: "Jeff E. Kinzli" <kinzli@cisco.com>
Subject: IP: eBayla virus
[From Dave Farber <farber@cis.upenn.edu>'s IP list]
>From http://www.tbtf.com/index.html
..eBayla
Canadian security enthusiast Tom Cervenka, who goes by the handle Blue
Adept, has invented a new flavor of virus: he has created an infected
eBay auction item [1] that he calls eBayla. The exploit works because
eBay allows JavaScript in the member-authored pages describing an item
offered for sale. When an eBay member bids on an infected item, his/her
username and password are e-mailed to Cervenka. EBay's response [2] to
the exploit sets a new low for bone-headedness. Not only does eBay
downplay the seriousness of the security hole; not only do they get the
technical details of the exploit's workings wrong; but they also make
vague threats in Cervenka's direction, because he brought this
vulnerability to their attention. EBay deserves to get slapped, hard, by
its mem- bers -- nothing else will make them rethink their cluelessness.
Thanks to Michael Sanders <msanders at confusion dot net> for the prod
on this story.
[1]
http://www.because-we-can.com/ebayla/default.htm
[2]
http://www.news.com/News/Item/Textonly/0,25,35321,00.html
------------------------------
Date: Fri, 23 Apr 1999 17:26:27 -0400
From: Lenny Foner <foner@media.mit.edu>
Subject: Use a cable modem, go to jail
A harrowing tale of serious criminal prosecution, unstoppable
bureaucracies, and the dangers of not wanting to watch cable TV:
http://members.home.net/maycomp/cablemodem.htm
------------------------------
Date: Wed, 21 Apr 1999 11:22:55 -0700
From: Jim Horning <horning@intertrust.com>
Subject: Risks of over-helpful software (Re: RISKS-20.32)
Microsoft's mail/calendar/contacts/tasklist program Outlook 98 has what
seems like a nifty feature: In addition to hand-constructed filters that you
can use to classify/move/delete/flag incoming mail according to its
properties, there is a built-in "Junk E-mail" filter, to which one can add
easily add new sources of spam as one identifies them (according to one's
own private criteria).
Shortly after activating this feature, I had a look at the file of Junk
E-mail messages it had shielded me from. To my astonishment, in the midst
of the spam, there were a couple of apparently innocent messages from
colleagues right here at work, which I rescued. Now I have formed the habit
of occasionally scanning the Junk E-mail folder to re-classify any non-junk
that lands there. (Of course, the need to do this makes the feature
somewhat less valuable.) After fairly diligent searching, I have concluded
that although one can ADD addresses that will be treated as Junk sources,
one cannot modify or REMOVE rules that cause messages to be treated as Junk.
Why am I reporting this to RISKS at this time? Simply because I discovered
this morning that Outlook 98 had classified RISKS vol. 20, no. 32 as junk,
for reasons that are not obvious to me. I think maybe I'll deactivate the
feature.
Jim H.
------------------------------
Date: Wed, 21 Apr 1999 16:15:23 -0400
From: "Steven M. Bellovin" <smb@research.att.com>
Subject: More on running a PKI (RISKS-20.32)
Today I decided to upgrade a copy of Netscape Communicator. That process
also involves certificates. They're not any better -- one of the packages
downloaded (mBED) was protected by a certificate that expired 21 July 1998.
I also noticed another certificate that expires tomorrow -- I declined
permission to do that update; I want to see what happens in a couple of
days.
There are other potential security problems with both update sequences.
Neither appears to use cryptography to protect the downloaded code, as
opposed to the installation program -- or, if cryptography is used, there's
no hint of it given to the user. Neither seems to check the expiration date
on these certificates. Neither gives any guidance on how to evaluate
certificates or CAs, or even that one should do so. Netscape, at least,
pops up warnings that the action you're about to take is dangerous -- but a
previous box tells you "click grant". Of course, that's all coming from an
http page (as is Microsoft's update screen), not an https page, which means
that a high-end attacker could substitute its own code and look-alike
instructions. The certificate would be wrong, but users don't know to check
that.
------------------------------
Date: Thu, 22 Apr 1999 06:44:08 -0400
From: Mich Kabay <mkabay@compuserve.com>
Subject: CompuServe responds to password-solicitation fraud
I recently received an obviously fraudulent e-mail request claiming to be
from CompuServe administration and demanding that I submit my user-ID,
_password_, and full credit-card information. After I forwarded it to
CompuServe support I received a response with the following key text:
> There are currently numerous e-mail messages circulating on
> the service claiming to be official CompuServe notices of account
> and/or billing problems being sent to members which contain
> a form that is supposed to be filled out and returned by e-mail
> or a termination of the account will occur. It is an attempt
> to steal your credit card and CompuServe account information!
>
> DO NOT respond to this or any similar e-mail!
>
> Instead forward a copy of the complete message by e-mail
> to the CompuServe Internet address actionteam@compuserve.com.
RISKS readers may want to remind naive users of any ISP be warned never to
respond to requests to reveal their passwords to anyone at an ISP or indeed,
on any network. Even in the rare cases where it would be useful to log into
a specific account for problem resolution, any authorized personnel who need
access to an account will have the capabilities required to change its
password themselves. They do not need to know the user's original password.
M. E. Kabay, PhD, CISSP, Director of Education -- ICSA, Inc.
>From: CompuServe, INTERNET:70006.101@compuserve.com
To: [unknown], mkabay
Date: 1999-04-20 14:34
RE: Feedback reply (Ref #1900)
Fr: T.J.
Customer Service Representative
I am writing in response to your question about Password or Credit Card
solicitation.
There are currently numerous e-mail messages circulating on the service
claiming to be official CompuServe notices of account and/or billing
problems being sent to members which contain a form that is supposed to be
filled out and returned by e-mail or a termination of the account will occur.
It is an attempt to steal your credit card and CompuServe account
information!
DO NOT respond to this or any similar e-mail!
Instead forward a copy of the complete message by e-mail to the
CompuServe Internet address actionteam@compuserve.com.
***IMPORTANT***
If you have responded to a message such as this and provided your
personal information, CompuServe recommends that you take the
following steps to secure your credit card and account information.
1. Contact your credit card company's customer service department and
notify them that your information has been compromised.
2. Change your CompuServe password, using the GO PASSWORD command. Your
password should not be something that is easily guessed. The best passwords
contain letters, numbers, and special characters (like ! or @).
3. Contact CompuServe Customer Service by calling 1-800-848-8990, to resolve
any issues which may have arisen as a result of your account being
compromised.
Please be assured that CompuServe is taking measures to prevent situations
such as this from happening in the future.
If you need further assistance, please write Customer Service again (GO
FEEDBACK).
------------------------------
Date: Sat, 24 Apr 1999 06:57:15 +0100
From: T Bruce Tober <octobersdad@reporters.net>
Subject: "In order to make it easier for you"
And this just in from the manager of a list to which I subscribe:
+++++++++++++++++++++++ Forwarded Message ++++++++++++++++++++++++
Since the migration to the new site, many of you have experienced problems
with the login process. In order to make it easier for you, we attempted to
create an e-mail with your username and password. However, due to a program
error, e-mails were sent to multiple users, disclosing other users'
information.
We sincerely apologize for this error and any inconvenience this may have
caused. In order to assure you that the site is secure, we will reset
everyone's password. A subsequent e-mail will follow with your new unique
password. You may keep this password, or once you login you may alter your
information by selecting Edit Your Profile from the Main Menu.
Again, we apologize for our mistake and we will correct this as soon as
possible. Please continue to visit xDSL.com as your source for DSL
information!
Dwayne A. Emerick, Manager of Web Development, TeleChoice, Inc.
TeleChoice...The Experience to Get You There http://www.telechoice.com
Bruce Tober, <octobersdad@reporters.net>, <http://www.crecon.demon.co.uk>
Birmingham, UK, EU +44-121-242-3832 (mobile - 07979-521-106). Freelance
------------------------------
Date: Fri, 23 Apr 1999 18:12:15 -0500
From: "Richard M. Smith" <smiths@tiac.net>
Subject: Melissa, GUIDs, and VicodinES
I saw the discussion in comp.risks about the Melissa virus and GUIDs and I
wanted to pass along some of the information that Rishi Khan
(rishi@udel.com) and myself (smiths@tiac.net) discovered during the week
after the virus was released.
First on the issue of the GUID, it turns out the GUID in the Melissa
document is identical to the GUID of Word document that carried another Word
macro virus named Shiver. The Shiver was created in August 1998 by someone
using the alias ALT-F11. Given that the 2 GUIDs are the same, Rishi and I
came to the conclusion that the Melissa document was created by copying the
Shiver document and replacing the Shiver virus code with the Melissa code.
This was confirmed by the fact that the list of Web sites in the two
documents are identical and the revision logs in the two files are the same
except that the Melissa document has one additional entry.
Because the last edit of the Melissa document occurred only 30 minutes
before the virus was posted to the Web, it looks like the Melissa virus was
developed in separate document and then combined with the Shiver Web site
list at the last minute.
The GUID then in the Melissa document most likely then contains the Ethernet
adapter address of ALT-F11's computer or a computer that he (or she) had
access to back in August, 1998.
What's the connection then between David L. Smith, the person alleged to
have released the Melissa virus, and VicodinES? It turns out there are many
connections because both David Smith and VicodinES posted extensively on the
Web and in newsgroups.
One of the more interesting connections was found on the VicodinES Web site.
I was pointed to this Web site a few days after the Melissa virus started
spreading by Fredrik Bjork of Sweden. He noticed many similarities between
the style of the VicodinES and the Melissa virus author. I was able to
download about 10 Word .DOC files from the VicodinES Web site that contained
various Word Macro viruses. In 2 or 3 the files I found David L. Smith's
name and his initials DLS. In particular, only his name showed up multiple
times in the hidden revision log of a VicodinES virus toolkit.
Here is a hex dump from the Word .DOC file from July 1998:
12F0:FF FF 12 00 00 00 0D 00 44 00 61 00 76 00 69 00 ........|D.a.v.i.
1300:64 00 20 00 4C 00 20 00 53 00 6D 00 69 00 74 00 d. .L. .|S.m.i.t.
1310:68 00 23 00 43 00 3A 00 5C 00 57 00 49 00 4E 00 h.#.C.:.|\.W.I.N.
1320:44 00 4F 00 57 00 53 00 5C 00 44 00 65 00 73 00 D.O.W.S.|\.D.e.s.
1330:6B 00 74 00 6F 00 70 00 5C 00 43 00 6F 00 6E 00 k.t.o.p.|\.C.o.n.
1340:76 00 65 00 72 00 74 00 20 00 42 00 65 00 74 00 v.e.r.t.| .B.e.t.
1350:61 00 2E 00 64 00 6F 00 63 00 0D 00 44 00 61 00 a...d.o.|c...D.a.
1360:76 00 69 00 64 00 20 00 4C 00 20 00 53 00 6D 00 v.i.d. .|L. .S.m.
1370:69 00 74 00 68 00 35 00 43 00 3A 00 5C 00 57 00 i.t.h.5.|C.:.\.W.
1380:49 00 4E 00 44 00 4F 00 57 00 53 00 5C 00 54 00 I.N.D.O.|W.S.\.T.
1390:45 00 4D 00 50 00 5C 00 41 00 75 00 74 00 6F 00 E.M.P.\.|A.u.t.o.
13A0:52 00 65 00 63 00 6F 00 76 00 65 00 72 00 79 00 R.e.c.o.|v.e.r.y.
13B0:20 00 73 00 61 00 76 00 65 00 20 00 6F 00 66 00 .s.a.v.|e. .o.f.
13C0:20 00 43 00 6F 00 6E 00 76 00 65 00 72 00 74 00 .C.o.n.|v.e.r.t.
13D0:20 00 42 00 65 00 74 00 61 00 2E 00 61 00 73 00 .B.e.t.|a...a.s.
13E0:64 00 0D 00 44 00 61 00 76 00 69 00 64 00 20 00 d...D.a.|v.i.d. .
13F0:4C 00 20 00 53 00 6D 00 69 00 74 00 68 00 35 00 L. .S.m.|i.t.h.5.
1400:43 00 3A 00 5C 00 57 00 49 00 4E 00 44 00 4F 00 C.:.\.W.|I.N.D.O.
1410:57 00 53 00 5C 00 54 00 45 00 4D 00 50 00 5C 00 W.S.\.T.|E.M.P.\.
1420:41 00 75 00 74 00 6F 00 52 00 65 00 63 00 6F 00 A.u.t.o.|R.e.c.o.
1430:76 00 65 00 72 00 79 00 20 00 73 00 61 00 76 00 v.e.r.y.| .s.a.v.
1440:65 00 20 00 6F 00 66 00 20 00 43 00 6F 00 6E 00 e. .o.f.| .C.o.n.
1B90:00 1E 00 56 00 69 00 63 00 6F 00 64 00 69 00 6E ...V.i.c|.o.d.i.n
1BA0:00 45 00 53 00 20 00 56 00 42 00 41 00 20 00 53 .E.S. .V|.B.A. .S
1BB0:00 74 00 72 00 69 00 6E 00 67 00 20 00 43 00 6F .t.r.i.n|.g. .C.o
1BC0:00 6E 00 76 00 65 00 72 00 74 00 65 00 72 00 00 .n.v.e.r|.t.e.r..
1BD0:00 00 00 00 00 00 00 0D 00 44 00 61 00 76 00 69 ........|.D.a.v.i
1BE0:00 64 00 20 00 4C 00 20 00 53 00 6D 00 69 00 74 .d. .L. |.S.m.i.t
1BF0:00 68 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .h......|........
The revision log in a Word document file is something that Microsoft
calls "Metadata" and cannot be viewed within Word itself. I found
it only by using a hex dump utility. Microsoft has an article talks all
about the problems of lingering metadata in Word documents:
http://support.microsoft.com/support/kb/articles/Q223/7/90.asp
It looks like the majority virus writers who create Word macro viruses
haven't read this Microsoft article. :-) I've seen many people's names in
other macro virus construction kits that are distributed as Word documents.
Richard M. Smith
------------------------------
Date: Thu, 22 Apr 1999 02:36:50 +1000 (EST)
From: Jiri Baum <jiri@baum.com.au>
Subject: Re: GUIDs and Melissa (20.32)
What's the point of a "Globally Unique ID" that isn't unique?
Presumably the algorithms that would benefit from a GUID can't use
Microsoft's one, because it's far from unique; copy-and-modify is far too
common a modus operandi for creating new documents, and creates collisions
exactly where they're most likely to matter...
Using a pure random number would probably be better than whatever fancy
schemes one may come up with, anyway. In simplicity there is strength.
Jiri Baum <jiri@baum.com.au>
------------------------------
Date: Wed, 21 Apr 1999 08:27:03 -0800
From: Rob Slade <rslade@sprint.ca>
Subject: REVIEW: "Y2K Risk Management", Goldberg/Davis/Pegalis
BKY2KRSM.RVW 990312
"Y2K Risk Management", Steven H. Goldberg/Steven C. Davis/Andrew M.
Pegalis, 1999, 0-471-33352-2, U$39.99/C$62.50
%A Steven H. Goldberg www.dr2000.com
%A Steven C. Davis www.davislogic.com
%A Andrew M. Pegalis www.consult2000.com
%C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8
%D 1999
%G 0-471-33352-2
%I John Wiley & Sons, Inc.
%O U$39.99/C$62.50 416-236-4433 fax: 416-236-4448 rlangloi@wiley.com
%P 312 p.
%T "Y2K Risk Management"
Bit late in the day for a Y2K book, wouldn't you say? Well, as the authors
point out, some action is better than none. And, as they also point out,
this marks your last chance to take a look at what you are doing, and make
sure you are getting the greatest benefit for your time and effort.
Chapter one is the fairly obligatory "sell or scare" piece. While similar
to others of the same ilk, it does stress the importance of interconnected
and interoperating systems, as well as emphasizing the business and legal
risks. On the other hand, it doesn't do a very good job of presenting the
background and technical aspects, for example discussing different types of
computers rather than various data structures or date usage. In the same
way as many essays on building a Y2K team, chapter two looks at starting a
risk management project directed at Y2K. The concepts are presented
reasonably, but the details aren't terribly useful. Starting a project, and
getting it up to speed as quickly as possible, is covered in chapter three.
Unfortunately, the advice consists, as usual, of "get the right people, have
the right plan, do the right things," with the particulars left as an
exercise to the reader. Chapter four, on legal aspects, is lengthy and
detailed, usually explains the concepts well, occasionally slips into
legalese, sticks primarily to common law, but does sometimes lapse into the
US-centric black hole. Dealing with suppliers and providers is handled much
better than in most books in chapter five. One issue hinted at, but not
adequately covered, is the possibility of a single point of failure removed
one or more layers of suppliers from you, such as having multiple grocery
suppliers--all of whose delivery fleets obtain fuel from the same source.
Chapter six, as did chapter three, gives the usual "do the right thing"
counsel for contingency planning. Large corporate decisions and Y2K are
reviewed in chapter seven, but not really tied together. "Due diligence"
was a large factor in chapter four: chapter eight looks at proving your
prudence. Insurance issues are definitely not made clear by chapter nine.
Chapter ten's overview of "alternative dispute resolution" (ADR: for pity's
sake, *everything* has a TLA [Three Letter Acronym]!) will probably have
value for many, although personally I found it rather obvious. Preparing
for litigation, in chapter eleven, has a lot of very useful background,
although much of it seems to assume you will be the suer instead of the
suee. Post Y2K planning is brief, but touches on a number of important, and
often unregarded, issues in chapter twelve.
Risk management is not really handled all that well in this book. A number
of risks are identified, but the control of those hazards is left vague. On
the other hand, a number of topics dealt with here get short shrift in other
year 2000 guides. Overall, while I couldn't recommend it as the only
reference for those just starting out, I would say that, for those seriously
into Y2K planning, the book should handily repay the price and time spent on
it.
copyright Robert M. Slade, 1999 BKY2KRSM.RVW 990312
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: 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.33
************************
