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…
The latest quarterly computer-security report card put together by Congressman Steve Horn's House Reform Committee government efficiency subcommittee and the GAO and OMB gives the government an F grade (down from a D- a year ago), based on lax protection of federal computer networks against hackers, terrorists, and others. Two-thirds of the federal agencies flunked this time, including the departments of Defense, Commerce, Energy, Justice, Treasury, Agriculture, AID, Education, Health and Human Services, Interior, Labor, Transportation, Small Business, and Veterans Affairs. The B+ given to the National Science Foundation was tops, with Social Security getting a C+ and NASA C-. As expected, the GAO found systems with no passwords, with ``password'' as password, and with unencrypted accessible password files. [Source: AP Online via COMTEX, 9 Nov 2001, PGN-ed]
[From David Farber's IP
http://www.interesting-people.org/archives/interesting-people/]
IPers might be interested in something that happened to me today. I am
planning a trip to Denver, and wanted to stay at the Adam's Mark hotel. Not
knowing the toll-free number for the chain, I called 800-555-1212 (toll-free
information) to ask for the number.
"Toll-free directory assistance, powered by TellMe!" said a recorded
message. I told the recording that I wanted the number of the Adam's Mark.
However, instead of receiving the correct number for the chain (listed on
their Web site as 800-444-ADAM), I received a different number:
800-866-5038. This number was not actually the number of the hotel chains,
but rather that of a third party room wholesaler in Orlando, Florida.
Calling the correct number, I confirmed that the hotel chain had no idea
that calls were being diverted to a third party.
As the economy continues into recession, we are likely to see more and more
instances of "customer hijacking," in which companies — perceiving their
markets as a zero sum game — work to grab customers from one another in any
way possible, regardless of ethics. "Slamming," and the hijacking of ISPs'
DSL customers by ILECs, are only two of the many other hijacking techniques
which are now becoming prevalent in slowly growing, or shrinking, markets.
Brett Glass
I recently opted for paperless (i.e., e-mailed) billing from both British
Telecom and my electricity provider, and am now finding that's it's much
harder for me to convince some financial institutions of my identity.
Many banks insist on a "recent utility bill" [1] as partial proof of ID, and
the application processing staff seem to be trained to reject anything that
looks remotely unusual. Unsurprisingly, they rejected a printout of my
"e-bill" as well as my (paper) gas bill, as I'm not on mains gas and they
hadn't heard of the supplier. The only way I could satisfy them was to ask
the electricity company to provide a printed copy of my bill (something they
tried to charge me for).
Ironically, this was an application for a paperless account!
[1] Of course, this means that the bank have an implied trust in the utility
companies to do some checking of their own.
Ian Chard, Unix Systems Administrator, European IT, Cadence Design Systems Ltd
The Alba Campus, Livingston, Scotland EH54 7HH +44 (0)1506 595019
A flaw was discovered in the way Internet Explorer's about: protocol handles javascript requests, enabling a malicious web site to gain access to cookie information on the client's hard drive. http://www.securityfocus.com/cgi-bin/vulns-item.pl?section=discussion&id=3513 MS has set the record for the fastest patch issuance: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms01-055.asp I wonder which correlation is better: patch issue time vs. possible publicity problems, patch issue time vs. problem solvability, or patch issue time vs. problem severity?
The 01 Nov 2001 edition of Metro (a free newspaper in London) had this
article on the front page, which began as follows.
"Hackers cracked and copied Microsoft's much-lauded new Windows
software within hours of its launch, it emerged last night.
Black market copies of the supposedly uncrackable Windows XP,
which took 16 years to develop, are already on sale for 5 pounds."
After making a reference to Microsoft's advertising, the article goes on
to mention that:
- Hackers were exploiting two "simple security loopholes"
- One of these was a security key "now widely available on
the Internet"
- Microsoft had admitted that illegal copies were already
on sale in China.
Not being an expert on such things, I cannot comment on the "security
loopholes", but I thought that the "16 years to develop" was a classic!
The Register has an entertaining article: http://www.theregister.co.uk/content/4/22863.html which, among other things, points out Microsoft Knowledge Base article Q293834: http://support.microsoft.com/support/kb/articles/Q293/8/34.ASP whose summary reads: "After you install Windows XP, you have the option to create user accounts. If you create user accounts, by default, they will have an account type of Administrator with no password."
> The difference with, say a toaster, is that there are far fewer interactions and controls to consider, but we still expect it to turn bread to toast without error. I'd like to know where Andrew gets his toasters! I have been married for over thirty years, and we average about five years per toaster (mean time between catastrophic failures). I have yet to own a toaster that will reliably produce evenly browned toast day after day. The more sensors and other gadgets the toaster has, the less likely it will be able to produce something between soft white and charred black. (Well, this actually supports Andrews overall point, I suppose.) I've noticed recently that some toasters will actually not turn off the heating elements until the toast is successfully "popped," with the result that if the bread should get stuck, the risk of fire is significant. I wonder that this hasn't caused become a recognized safety issue. The only toaster in our house that works satisfactorily is the one given to my in-laws for their wedding fifty-three years ago. It has no "doneness" sensors and a completely mechanical timer.
Summary: system messages in the bar above the headers I recently saw a couple messages from a friend that had this yellow bar at the top of the message (same place as outlook sticks other system messages, like that annoying stuff about extra line breaks, and the "You have replied to this message" comments) The message said: (i) Your mailbox is corrupt. Upgrade your mail software. Now, obviously, I was a bit disturbed by this. Tracking it down, it is the "X-Message-Flag" mail header. Seems to me it can be quite dangerous to allow a remote user to cause messages to be displayed on your mail client that appear to be generated by the system. (Think about what stupid users do when people send them forwards saying to do stuff.) (For reference, I don't use Outlook by choice, and at least I'm running it under VMWare on linux.) Nathan Neulinger, Computing Services, University of Missouri - Rolla 1-573-341-4841 nneul@umr.edu
> #2001-11-08# becomes #11/8/2001# (2001-11-08) > #11/8/2001# becomes #11/8/2001# (2001-11-08) > #8/11/2001# becomes #8/11/2001# (2001-08-11) > #15/11/2001# becomes #11/15/2001# (2001-11-15) > The first has reduced the comprehensibility of the code. The second and > third give no feedback that they're not conforming to the current locale. > The last two show that VB is not even being consistent in its parsing. Oh, but it *is* being consistent, if you assume that the algorithm is: - Find a number which could only be the month - Find a number which could only be the day - If there is ambiguity, assume the user typed the date in mm/dd order Now, of course, this is so wrong as to be bordering on the criminally negligent (not for nothing is MS sometimes known in France as "Crimosoft"). It shows what can happen even if you put millions of dollars into internationalisation (as MS undoubtedly has), but then hire a short-term contractor who has never set foot outside the US and let him or her write date validation code unsupervised. (I remember about 15 years ago seeing a Lotus 1-2-3 manual which proudly claimed that the program accepted various date formats, including "the international standard, mm/dd/yy")
These replies were directed to me. > From mark.lomas@tmalomas.com Mon Nov 12 07:57:57 2001 > From: "Mark Lomas" <mark.lomas@tmalomas.com> > To: <msb@vex.net> > Cc: <magical@rahul.net>, <davidhecht@prodigy.net> > Subject: Re: Excel and non-decimal dots > Date: Mon, 12 Nov 2001 12:54:09 -0000 > > In Risks Digest 21.74 you wrote: > > Date: Wed, 7 Nov 2001 13:43:25 -0500 (EST) > From: msb@vex.net (Mark Brader) > Subject: Excel and non-decimal dots > > > > * From: magical@rahul.net > > * Newsgroups: alt.usage.english > > * Subject: Re: Telephone Area Code > > * Message-ID: <7bqiutgjqqg1tu29qd6ak615c14pbcfavo@4ax.com> > > * Date: Wed, 07 Nov 2001 17:07:08 GMT > > > > On Wed, 07 Nov 2001 07:54:15 GMT, in alt.usage.english, David > > Hecht <davidhecht@prodigy.net> created > > > > > The US convention (AAA)BBB-CCCC is not just evolving into AAA-BBB-CCCC; > > > now I'm seeing more and more of the "international" style: AAA.BBB.CCCC > > > . This appears in some "chic" guidebooks. > > > > I tried using that format, until I pulled a text file into Excel and it > > changed all the phone numbers into "real numbers" and deleted terminal > > zeros. Excel also has this annoying habit with IP addresses, changing > > 10.0.0.10 to 10.0.0.1. I can't find a way, in the *import* function, to > > define these numbers as "text" so that Excel will leave them alone upon > > import. Sigh. > > I suspect that you may be using an old version of Excel. > > I have just tested this using Excel 2000 (version 9.0.3821 SR-1). > If I open a text file containing your example, the Text Import Wizard > appears. I accept its first two default suggestions (it correctly > deduced how I had delimited fields within the file), then it gives > me a choice of General, Text, Date (with six sub-choices), or Skip, > for each field; I then select Text for the field in question. > > There is an alternative way to do this which may work for older > versions of Excel. If you open a new spreadsheet, select the > appropriate column(s), then Format Cells Text, you can copy data > from a text file (e.g. from within Notepad) and paste it into the > cells you have already formatted. This works because Excel tries > to deduce the format of General cells but not Text cells. > > Mark > > p.s. For completeness, I have just imported the same test file and > accepted all of the Text Import Wizard's defaults. It correctly > deduced that IP addresses should be left alone (i.e. formats them > as text rather than numbers, even though the Format Cells dialogue > shows that they have General format rather than Text). > -- > Mark Lomas <mark.lomas@tmalomas.com> > > > From neil.maller@gte.net Mon Nov 12 08:26:52 2001 > Date: Mon, 12 Nov 2001 08:26:53 -0500 > Subject: Re: Excel and non-decimal dots > From: Neil Maller <neil.maller@gte.net> > To: <msb@vex.net> > > on 11/11/01 9:52 PM, RISKS List Owner at risko@csl.sri.com wrote: > > > Date: Wed, 7 Nov 2001 13:43:25 -0500 (EST) > > From: msb@vex.net (Mark Brader) > > Subject: Excel and non-decimal dots > > > > * From: magical@rahul.net > > * Newsgroups: alt.usage.english > > * Subject: Re: Telephone Area Code > > * Message-ID: <7bqiutgjqqg1tu29qd6ak615c14pbcfavo@4ax.com> > > * Date: Wed, 07 Nov 2001 17:07:08 GMT > > > > On Wed, 07 Nov 2001 07:54:15 GMT, in alt.usage.english, David > > Hecht <davidhecht@prodigy.net> created > > > >> The US convention (AAA)BBB-CCCC is not just evolving into AAA-BBB-CCCC; > >> now I'm seeing more and more of the "international" style: AAA.BBB.CCCC > >> . This appears in some "chic" guidebooks. > > > > I tried using that format, until I pulled a text file into Excel and it > > changed all the phone numbers into "real numbers" and deleted terminal > > zeros. Excel also has this annoying habit with IP addresses, changing > > 10.0.0.10 to 10.0.0.1. I can't find a way, in the *import* function, to > > define these numbers as "text" so that Excel will leave them alone upon > > import. Sigh. > > Mark, > > You're probably already aware of this, but preceding your would-be text in > Excel by a single <'> character (apostrophe) will define it as text and > suppress any reformatting. This apostrophe will not be displayed in Excel, > although it'll still be there if you export the cell contents. > > It may not be possible to insert the extra character as part of Excel's > import process, but I'm sure you can figure out a way to prepend the > apostrophe beforehand. For instance this would be easy in MS Word using the > Replace function. > > We use Excel extensively to compose tables for technical manuals, so face > its auto formatting quirks on a daily basis. RISKS of using a spreadsheet > program for non-mathematical tasks... > > Regards, > > Neil > From mchinni@pica.army.mil Wed Nov 14 11:42:55 2001 > From: "Chinni, Michael J [AMSTA-AR-CI]" <mchinni@pica.army.mil> > To: "'msb@vex.net'" <msb@vex.net> > Subject: Re: Risks Digest 21.74 > Date: Wed, 14 Nov 2001 11:43:08 -0500 > > Mark, > > Regarding your item in the Risks Digest 21.74 (see below), when > importing a text file into Excel (i.e. opening a text file from within > Excel) there's a step where you can define the data types for each column > (in Excel 2000, it's step 3 of 3 in the Text Import Wizard). In that step > just change the data type for the columns you want left alone to "Text" (the > default is General). > > ...Mike Chinni
I maintain a mail account at deja.com (continued by google), as spam protection for my real e-mail account. Every now and then I log on and delete the accumulated spam. I logged on the other day and found a bounce notification message. I was surprised at this and opened it. Imagine my surprise to find that the original (bounced) message had been spam, apparently sent from me! It seems that someone had somehow picked my e-mail address to use in forging their e-mail header. Worse yet, the spam was porn spam. How much worse can things get? Up till now, I at least had the comfort that unsolicited e-mail (spam, viruses, etc) was in my control, and that with a little care I could protect myself from most of it. Now, I don't even have that.
It's refreshing to see that Ernst and Young actually cared enough about the problem to do something about it. Back in May, the same pornographers bought up close to 2000 expired domains (that I could tell), including domains owned by respectable organizations with hundreds of inbound links, such as the TCL Consortium, XIII International AIDS Conference, Evian, Universal ADSL Working Group, and Craig's List. I tracked down the original owners of about 60 of these sites with the most inbound links and warned them of the problem (this wasn't entirely altruistic as I was operating a service at www.moveannouncer.com that could help them bypass the worst effects the problem). Five months later, only three of those 60 sites have done anything about their former domains, either buying them back from the extortioners or getting links changed to their new sites. Some of the former owners I talked to seem to have trouble seeing that their web sites did not stand in isolation, that people outside their organization had links to their web site and others had bookmarks and those links attached to their names were now serving up porn. I got responses to the effect of "We have a new domain name now, so we don't care what happens to the old one." One certainly takes a RISK in letting one's domain name expire, but when the gamble fails and what must be about the worst case scenario occurs, the indifference I've seen surprised me. I find it hard to believe that so many people have so little respect for their viewers and customers.
YaBB, a popular PERL web-based forum application, recently moved to <http://yabb.xnull.com/> from <www<dot>yabb<dot>org>, which is now pure pr0n. I've munged the link. Anyone is welcome to unmung it, of course. <puerile snigger> <http://yabb.xnull.com/community/?board=general&action=display&num=1000638654> says it all. Also it implies that the presence of pr0n on the "hijacked" site is a blackmail tool, which would explain why so many domain names obviously targeted at children become (apparently inexplicably) pr0n sites. I'd never thought of pr0n as a weapon. Perhaps the new US PATRIOT Act <http://www.zdnet.co.uk/itweek/columns/2001/42/bingley.html>, ridiculous though it may be, could be diverted against these amoral cybersquatters for a while before it gets repealed.
According to an editorial in the *London Daily Telegraph*, a combination of cumbersome bureaucratic systems and inaccurate map databases is to blame for the rapid spread of hoof & mouth disease in Britain. The essay details one incident of overreliance on poor quality data which led to a substantial loss to a shepherd's flock. It also blames delays and foolish acts on centralized decision making. Risk: Look out at the Big Room from your monitor once in a while. http://www.dailytelegraph.co.uk/dt?ac=006527651614093&rtmo=a5d9qChJ&atmo =rrrrrrrq&pg=/01/11/12/do01.html Charles Shapiro <charles.shapiro@numethods.com> [See also previous Foot-and-mouth virus propagation items, PGN, RISKS-21.31 and Ursula Martin, RISKS-21.33. PGN]
Back in the days of SNA I could tell when the Xerox tech was in to work on the Xerox in the basement because both IBM cluster controllers would fail simultaneously. They were about a meter away with their Gandalf modems on top. The Xerox tech would decide that the the pair of side by side tops of the controllers made an excellent surface for him to flop his huge folder of tech charts onto, toggling the power switches on both modems off. Power failures were sometimes an event to take advantage of. Our first IBM terminals were installed about the time that our corporate president decided that we could convert our largely Honeywell based applications from GCOS 4JS et al to to MVS for about $1 million and in less than a year (turned out to be not quite done 2 years and $10 million later, but that is another risk). We were a bit surprised to see the terminals turned on but blank and not responsive, for most of a week, until the power failed for longer than the motor generator flywheel could smooth out. The HIS terminals were in use within a few minutes of power being restored, but about 25 minutes later the MVS terminals all started showing netsol logos for the first time. We got a phone call shortly after asking us to confirm that. Apparently SNA at the time didn't recognize new terminals until the next IPL, giving rise to the short lived line about "if IBM designed the phone system...". Life is much more flexible with TN3270 these days.
BKWHTHSA.RVW 20010814 "White Hat Security Arsenal", Aviel D. Rubin, 2001, 0-201-71114-1, U$44.99/C$67.50 %A Aviel D. Rubin rubin@research.att.com %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2001 %G 0-201-71114-1 %I Addison-Wesley Publishing Co. %O U$44.99/C$67.50 416-447-5101 fax: 416-443-0948 bkexpress@aw.com %P 330 p. %T "White Hat Security Arsenal: Tackling the Threats" The distinctive of this book is that it approaches security as a series of specific problems or concerns. The non-distinctive, if you will, is that it attempts to address all audience levels; users, IT professionals, academics, and administrators. A series of icons identifies, at the beginning of each chapter and at particular sections of the text, who should read the various segments of the text. Part one examines the size and scope of the security issue. Chapter one starts out with perhaps our biggest problem, as security people: the insistence on secrecy by companies who get hit, and the fact that this obstinate refusal to discuss the facts makes our job, in protecting institutions, that much harder. A brief look at what may be at risk from security problems is given in chapter two. Recent e-mail viruses are reviewed in chapter three, but they get an interesting treatment. The material, while technically sound, concentrates on the general security attitudes and lessons to be learned, as they apply to computer use in general. Part two looks at information storage. Chapter four's problem is to ensure that information is kept private if an attacker gets hold of your machine, and Rubin gives a good introduction to symmetric encryption and provides tips on passwords. If you are concerned about storage at remote sites over an insecure network, chapter five touches on passwords again, and asymmetric encryption. Chapter six is supposed to deal with securing backups, but seems to get a bit confused, although it does provide some good tips, as well as an overview of some online backup services. Part three considers the problems of data transfers over an insecure net. Chapter seven introduces authentication and some of the problems of public key management. Session keys and key exchange are examined in chapter eight: it has an academic icon at the top of the chapter, and non-specialist users might get a bit confused here. The aspects of virtual private networks are reviewed in chapter nine, and the book begins moving towards the usual technology oriented model. Part four looks at network threats. Chapter ten explains firewalls while eleven discusses a variety of network based attacks. Part five doesn't really have a central theme. The title of chapter twelve is "Protecting E-Commerce Transactions," but most of the text deals with the Secure Sockets Layer for Web browsers. Privacy, in e-mail and Web browsing, is discussed in chapter thirteen, but many areas are left unexplored. For managers and users who are not specialists in computer and communications security, this book provides a readable and accurate introduction to a number of important topics. There are, unfortunately, a number of gaps in terms of the total security picture, but that is probably to be expected when taking the problem oriented approach. Rubin does not talk down to the audience and does not oversimplify, and this work therefore is superior to a number of the introductory books on the market. copyright Robert M. Slade, 2001 BKWHTHSA.RVW 20010814 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
Please report problems with the web pages to the maintainer