Forum on Risks to the Public in Computers and Related Systems
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Volume 20: Issue 33
Saturday 24 April 1999
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
- Info on RISKS (comp.risks)
Expert warns of safety glitch in shopping carts
"Keith A Rhodes" <rhodesk.aimd@gao.gov>
Fri, 23 Apr 1999 14:52:05 -0500
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]
The CIH virus will strike Monday, April 26!
"Satomi Hamamoto" <toni.hamamoto@sri.com>
Fri, 23 Apr 1999 19:04:49 -0700
[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
IP: eBayla virus
"Jeff E. Kinzli" <kinzli@cisco.com>
Thu, 22 Apr 1999 17:34:41 -0700
[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 Sandershttp://www.because-we-can.com/ebayla/default.htm [2] http://www.news.com/News/Item/Textonly/0,25,35321,00.html
Use a cable modem, go to jail
Lenny Foner <foner@media.mit.edu>
Fri, 23 Apr 1999 17:26:27 -0400
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
Risks of over-helpful software (Re: RISKS-20.32)
Jim Horning <horning@intertrust.com>
Wed, 21 Apr 1999 11:22:55 -0700
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.
More on running a PKI (RISKS-20.32)
"Steven M. Bellovin" <smb@research.att.com>
Wed, 21 Apr 1999 16:15:23 -0400
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.
CompuServe responds to password-solicitation fraud
Mich Kabay <mkabay@compuserve.com>
Thu, 22 Apr 1999 06:44:08 -0400
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).
"In order to make it easier for you"
T Bruce Tober <octobersdad@reporters.net>
Sat, 24 Apr 1999 06:57:15 +0100
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
Melissa, GUIDs, and VicodinES
"Richard M. Smith" <smiths@tiac.net>
Fri, 23 Apr 1999 18:12:15 -0500
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
Re: GUIDs and Melissa (20.32)
Jiri Baum <jiri@baum.com.au>
Thu, 22 Apr 1999 02:36:50 +1000 (EST)
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>
REVIEW: "Y2K Risk Management", Goldberg/Davis/Pegalis
Rob Slade <rslade@sprint.ca>
Wed, 21 Apr 1999 08:27:03 -0800
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
Report problems with the web pages to the maintainer