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]
[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
http://www.because-we-can.com/ebayla/default.htm  http://www.news.com/News/Item/Textonly/0,25,35321,00.html
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
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.
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.
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 email@example.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:firstname.lastname@example.org 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 email@example.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).
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, <firstname.lastname@example.org>, <http://www.crecon.demon.co.uk> Birmingham, UK, EU +44-121-242-3832 (mobile - 07979-521-106). Freelance
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 (email@example.com) and myself (firstname.lastname@example.org) 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
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 <email@example.com>
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 firstname.lastname@example.org %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 email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer