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…
Derailed train cars burning in a Baltimore tunnel have seriously damaged the area's fiber-optic cables, slowing Internet service and other communications traffic in the Mid-Atlantic states, with a ripple effect across the country. WorldCom, PSINet and AboveNet all reported problems with service, but said they had not yet been able to quantify the severity of the problems. Keynote Systems, which measures Web site performance, said the delay experienced by Internet users was the worst it has ever seen. "What we're seeing is a problem in the handshake between the backbones which serve as the Internet's infrastructure," said a Keynote spokeswoman. "These backbone providers hand off traffic to travel between them across the country." Keynote reported major slowdowns as far away as Seattle and Los Angeles that may be attributable to the train wreck [or Code Red? The fumes also resulted in cancellation of Orioles games. PGN]. [AP Jul 19 2001 http://news.excite.com/news/ap/010719/18/train-derailment-communications NewsScan Daily, 20 July 2001]
Calendaring software plays a critical role in any sizeable organization. Local governments, in particular, hold innumerable meetings — formal meetings of the local legislative body, of course, but also committee meetings, citizen board meetings, project meetings, and on and on. And many of those meetings involve members of the public, or officials external to the organization. The county government here in Washtenaw County, Michigan (county seat: Ann Arbor), has about 1,300 employees. Most or all county departments use Netscape Calendar version 4.6 to schedule and keep track of meetings. One particular county department, the Drain Commissioner's office (responsible for construction and maintenance of storm sewers and ditches all over the county) holds many meetings with local officials and property owners to discuss proposed or pending drain projects. A specific employee was responsible for putting these meetings on the calendar. A few weeks ago, this employee left the County's employment, and her account was deleted from the system. Here's the problem: all of the many meetings she had scheduled ALSO disappeared. As a direct result, the Drain Commissioner and other county officials, who relied on the automated calendar, were not in attendance at meetings where they were expected, resulting in inconvenience for the public and embarrassment for the officials and the County. Only then was this problem discovered. The number of future meetings that had also been lost was unknown. I asked if the deleted meetings could be retrieved from backups. Nope, individual calendars cannot be restored, only the entire system, which obviously would disrupt over a thousand individual calendars. The RISK: calendaring software that doesn't recognize (1) the likelihood of turnover among employees, including meeting schedulers, (2) that there are more stakeholders in a meeting than just the one person who adds it to the official calendar, and (3) that access to information in backups may be needed on a less than all-or-nothing basis. Lawrence Kestenbaum, polygon@potifos.com, Washtenaw County Commissioner, 4th District, Mailing address: P.O. Box 2563, Ann Arbor MI 48106 The Political Graveyard, http://politicalgraveyard.com
Bloomberg radio reports that Home Depot will do a targeted mailing synchronized with tax refunds. Apparently the tax refunds are being sent out in an order related to the Social Security Number (I think it may be just the last 2 digits). Home Depot has SSN information for a number of their customers (I believe those with Home Depot cards). So they will send out advertising flyers to their customers in the SSN order, timed to be viewed just when the customer needs help deciding what do with the refund check.
I work for a company which had purchased a digital certificate from BT Trustwise (now part of Ignite) 12 months ago, I now find that I am unable to renew it online. The problem is the "log in" passphrase contains some non- alphanumeric characters, this is a practice which would surely meet with industry-wide approval as it makes brute force attacks more difficult. At the time of purchase the BT Trustwise system accepted the passphrase and duly created and delivered a working certificate. Today the Web page where new passphrases are entered has a warning telling customers to use alphanumeric characters only, whether it stops users entering anything else is unknown at this time. I am told by the person who originally created the certificate that no such warning was displayed at the time of purchase. The software which processes the online renewals malfunctions if it sees anything but alphanumeric characters in an existing user's passphrase. It is possible to determine that the passphrase is being recognised as valid because after entering it correctly I get delivered to a mostly blank and useless page, entering something which isn't my passphrase takes me to a page telling me my passphrase is incorrect. If the system knows I am using the correct passphrase why won't it let me renew my certificate? It seems to me that Trustwise is covering up a minor programming error with a simple message saying "don't do this or it will break" rather than fixing the problem, something I find quite surprising given the business they're in. The risk of having no valid certificate became a different risk, that of having an insecure certificate, when the support person at the company concerned offered to enter the passphrase directly into their system if I read it over the phone to them. Then there is the risk of overlooking directions to use only insecure passwords... Philip Bragg
The security service the monitors the building where I work recently upgraded its alarm monitoring software. The people from their corporate office arrived, installed the upgrade, and left... Unfortunately, while they were here, they appear to have also deleted the configuration database and all backups... as the local people ended up manually re-entering all the system settings, for all their clients, by hand. A month later our computer room air-conditioning went out and the over-temperature alarm did not go off. They forgot to tell the computer to monitor that line. Fortunately one of our staff walked into the room before damage was done. (Our manual backup sensor.) They tell me that everything is now working correctly. Why am I still nervous? Bob Van Cleef, San Jose, CA www.garg.com
[For those of you who slept through it, the Code Red worm was intended to
attack the whitehouse.gov Web site at 5pm EDT on 19 Jul 2001. With
just-in-time reverse engineering, the code was discovered to contain the
target IP address, thus enabling the White House staff to reconfigure to
avoid the attack. (The attack clearly could have been more subtle.) It
is of course ironic that current efforts to outlaw reverse engineering
(DMCA, UCITA, etc.) could ban efforts to stave off this and other attacks!
The relevant CERT advisory is at
http://www.cert.org/advisories/CA-2001-19.html pointing out that Code Red
exploited a vulnerability noted earlier in CA-2001-13. YABO: Yet Another
Buffer Overflow, aimed at Microsoft IIS servers. PGN]
On the morning of 19 Jul 2001, I notified a small company (whom I sometimes
advise since they have no dedicated IT staff) of the then-latest Microsoft
advisory. An hour later, they proudly replied, reporting success and noting
that this hot fix was much easier to apply than most — especially since
this one didn't force a reboot.
Suspicious that they hadn't really applied the hot fix, I downloaded a
separate copy of the hot fix using Internet Explorer and sent it to them
via e-mail. This time they replied that the attachment I sent resulted
in an error message: ''not a valid Windows NT application.''
I soon realized that the connections were terminating prior to
completion and Internet Explorer was not reporting the failures. In the
user's mind, silence was equivalent to success.
We were able to successfully download the hot fix using wget on FreeBSD,
which restarted the transfer four times due to reset connections — each
time picking up where it had previously left off. The company's server
was soon patched, and they have had no problems with the Code Red worm.
I've confirmed that Internet Explorer 5.0 on Win2k reports no failures
in (at least) the following situations:
- When the user has selected 'Run this program from its current
location' and the connection is prematurely reset, the download
dialog silently disappears. This is the same visual behavior as a
program that was successfully transfered and completed execution
without pausing for user input.
- When the user has selected 'Save this program to disk' and the
connection is closed normally but prematurely (i.e., before the
number of bytes specified in the Content-Length header were
received), the total file size is silently changed. For example,
during the download, the dialog displays:
Estimated time left: 2 sec (87.2 KB of 236 KB copied)
but once the connection has closed, the dialog changes to:
Downloaded: 180 KB in 1 sec
An error does result in the inverse of these situations (i.e., when running
a program where the connection is closed normally but prematurely or when
saving a program where the connection is reset).
One wonders how many naive admins thought they *had* installed the hot fix,
but ended up with a truncated download and a Code Red worm infestation
instead.
P.S. As of 22 Jul 2001, transfers from mssjus.www.conxion.com (to which
download.microsoft.com at least sometimes redirects) still result in
frequent resets from some networks.
I recently received e-mail from a stranger with the following note at the end: > This message has been scanned for viruses with F-Secure Anti-Virus for > Microsoft Exchange and it has been found clean. RISKS: Someone could actually take such a note for real and blindly trust it! There is no way to tell whether any scanning has been actually done. I might as well add a similar note to my .signature! Secondly, who would trust virus scanning done by the *sender* anyway? Aaro Koskinen, aaro@iki.fi, http://www.iki.fi/aaro
In January 2001, I moved to the UK to take up a position as a Senior Lecturer of Computing at the University of Sunderland in the UK. Today, I got the first bill for a credit card taken out fraudulently in my name back in the US. I was fairly careful about these things — I suspect this is the tip of the iceberg. The first step, of course, was to file fraud alerts with the three major credit bureaus. Trans Union was very helpful, and even indicated that the incident I already knew about was the only one on my recent record. Experian was not as helpful — I had to provide an obsolete ZIP code to reach the point of actually filing the data they needed, but then they recorded my voice as I provided the rest. Equifax was hopeless. They couldn't handle (UK) rotary phones, and they required a US phone number for contact purposes. They also had problems reading my SSN, and they finally ejected me from the system, requesting a letter with about five pages of miscellaneous details, some of which (a pay stub with my SSN) are simply not available in the UK. I filed a complaint on that with the FTC. Next step is a letter to the credit-card issuer to follow up on my voice report. I suspect my notary will be busy. Harry Erwin, University of Sunderland. Computational neuroscientist modeling bat bioacoustics and behavior. <http://world.std.com/~herwin>
Major financial institutions routinely give out confidential customer account information to callers, using security procedures that authorities say are vulnerable to abuse by fraud artists. Regulators and law enforcement officials warned three years ago that identity thieves and information brokers were tricking clerks into giving them access to individuals' financial information. [Source: Robert O'Harrow Jr., Washington Post Staff Writer, 23 Jul 2001; Page A01, http://www.washingtonpost.com/wp-dyn/articles/A27475-2001Jul20.html]
I am a longtime customer in good standing with Nicor, a large natural gas utility serving portions of northern Illinois (United States). I recently had my gas shutoff, the meter locked, and the meter scheduled for removal from outside my house. Luckily I was home when the Nicor technician arrived to haul away the meter and I asked her to check the order. Armed with a telephone and e-mail client, I discovered anyone can cut anyone else's Nicor service off by supplying either an address or telephone number. One representative told me requests for shutoff are honored immediately. To a degree, this is understandable. Fire departments must, for example, kill the gas to a burning building. But the ease with which a cutoff under far less threatening circumstances can occur is remarkable. To their credit, Nicor is investigating the processes in place that allow this. Their default for each account, for example, is *not* to password-protect it (that is, mother's maiden name or some such checkpoint). Is this a software RISK? I think so. Shutoff requests are keyed into a system with under veil of the skimpiest verification. Systems with "screen pop," which display the telephone number of the caller, also act as a checkpoint. This system appears divorced from a screen pop function. In this case, the final checkpoint is an onsite technician who can only debug the problem if the homeowner happens to be in. That's the type of debugging I expect from, say Microsoft, not my utility company. William Paul Fiefer (and please don't cut my gas off)
Insight Magazine reports [1] that since 1997, the US Postal Service has been reporting innocent activity it deems "suspicious" to federal law enforcement officials. Evidence includes a training video with this chilling instruction: "It's better to report 10 legal transactions than to let one illegal transaction get by." The risks of a system that presumes guilt until innocence is proven are too numerous to list here. Not least of them is the impossibility of proving a negative (I did not intend this cash to be used for illegal purposes). A similar reporting system in the banking arena is known to generate ratio of 99,999 false positives for every true positive. Yes, I do mean a ratio of 10^5:1 errors to correct results. I can't imagine any other system in which that error rate would be acceptable. The information on suspicious activities is, of course, kept in a database controlled in secret and used for purposes no one is willing to discuss. The Post Office will not discuss the parameters used to flag "suspicious" activity, though the video states that unwillingness to give out personal information such as date of birth and/or produce identification papers is automatically suspicious. Someone help me verify that I'm still living in America, please? [*] [1] http://www.moreprivacy.com/editorials/postaleye.htm Alan Wexelblat <wex@media.mit.edu> http://wex.www.media.mit.edu/people/wex/ CHI'02 Panels Chair, moderator, rec.arts.sf.reviews [* Alex, Yes, you are. But privacy is continually being eroded, despite the best efforts of the Risks Forum, the Privacy Forum at http://www.vortex.com/privacy, EPIC at http://www.epic.org, EFF at http://www.eff.org, Zero Knowledge at http://www.zeroknowledge.com, to name just a few. PGN]
Recently my wife needed to redeem US Airways miles for a ticket on short notice. The fee for the last minute booking was $75, which I paid with a credit card at the airport. When the credit-card bill came, there were two charges for the $75. The US Air representative I spoke to cheerfully reversed one of the charges and explained that, due to a known "programming error," after the card was swiped, the record of the transaction was not cleared upon completion. When the next customer's card was swiped, the last transaction in the system (mine) was processed again, resulting in the double billing. He explained all of this to me so that I would not be concerned about seeing someone else's name as the passenger on the confirmation letter that would be sent. Sure enough, the letter arrived with the name of the person whose card was swiped after mine. One has to wonder how long this error has been known. Jed Graef <jgraef@att.net>
I live in Salmon Arm, British Columbia, Canada. Suppose you wanted to create a Web site for promoting the downtown Salmon Arm area. These names are a bit long: downtownsalmonarm.bc.ca salmonarmdowntown.bc.ca The most common (and presumably obvious) abbreviation of the community name is "SA". You could abbreviate — as someone did: sadowntown.bc.ca Unfortunately, this can easily be lexed to: sad own town The risk? When mapping a name to another set of rules, watch that you aren't now saying something other than what you mean to say. Gene Wirchenko [This is of course a very old problem — as in "together" vs "to get her". With the high price of fuel, the town may be dealing with "sa gas". Perhaps "sa les girls"? I presume the town song is "Salmon Chanted Evening". PGN]
A local Internet-based bank (a joint venture of South Africa's largest ISP and a local banking group) ran into a spot of trouble with a mass e-mailing list of a sister company, MoneyMax. MoneyMax provides online securities trading and securities-related information to the bank's customers. It appears the wires got crossed, and confidential information in response to one person's credit-card application made it onto MoneyMax's daily financial newsletter. Thankfully, somebody noticed after mailing to about 2% of the list, and pulled the plug on the mailserver. [The e-mail apology entitled "Please delete previous Moneymax Newsletter" blamed an "unforeseen software error", and included the customary "Measures have been taken to ensure that it will not happen again." PGN-ed]
In response to Henry Baker's aggravation, it would take a broad, concerted effort on the part of several industries to coordinate LCD screen angle with the linear polarization manufacture methods for lenses. It's my understanding that they come in sheets and their orientation is not a manufacturing concern when the sunglasses are manufactured. This answers hbaker's wondering as to why he cocks his head at only a 15-degree angle for his wife's screen but 40 for his and 45 for his laptop. He will see this (up to a full 90 degrees) for many to most of the LCDs that are so quickly emerging as standard equipment for displays, ATMs etc. This may be particularly RISKS relevant, since the "accutint" lenses or those that react with sunlight (UV rad.) may also react adversely, depending on the linear angle and whether it's merely arbitrary during manufacture. Imagine the risk, driving into a sunlit area (like after a tunnel or cloudcover or something). Ugh! Stephen A. Boyd, Chief Information Officer, Premier Heart, LLC [Re: Brewster's angle of incidence: perhaps the Brewster Rooster cocks its head cluckwise. PGN]
> ... the software is supposed to catch cases of the same person making two > reservations on the same flight but in this case that didn't work either. That in itself sounds risky - I was on a trip once where the group included two sisters, same surname, same initial; the hotel manager had assumed that one of the entries on the list was an erroneous duplicate and only allocated one room. Philip Anderson, Alenia Marconi Systems Cwmbrân, Cymru/Wales
What the EAA Web page does is quite common. The web-browser submits the information using SSL to the server, and the server e-mails that information in cleartext to some destination. I imagine that most small "registration" pages do similar things, with the main difference being that they hard-code the destination address in the server, rather than submitting it with the form. One risk is that users have been taught that a padlock on their browser means that _everything_ is secure. A greater risk is that some (most?) developers believe the aforementioned statement and do not worry about the treatment of user data once it arrives at the server. Jacob
My home account is with MSN. A couple of years ago, my address was blahblah@msn.com. After an upgrade, it became blahblah@email.msn.com. However, I could still use the old address as a return address, and people could still send mail to me at both addresses. Since then, I've joined a couple of mailing lists, with my e-mail address as blahblah@email.msn.com. Recently, MSN required all its users to upgrade to some new security configuration which is supposed to remove spam. (It hasn't, and for the first time I'm getting spam purporting to be from actual old e-mail address.) In the process, my e-mail address changed again back to blahblah@msn.com. The problem is that now I can no longer post to my mailing lists, which have me as blahblah@email.msn.com. Not only that, but although I can resubscribe with my new address, I cannot unsubscribe using my old address, since the MSN servers refuse to acknowledge it. (This is probably their spam-blocking.) I'm having to pester the administrators of several lists to unsubscribe me manually. Since this is probably happening to everyone who has an msn account, the problem is non-trivial. The risk? MSN's attempt to improve security (apparently by forcing spammers to modify their software to change fake msn addresses) has resulted in additional burden on list administrators. Ami Silberman (ami_silberman@hotmail.com)
Fourth Information Survivability Workshop (ISW-2001)
"Impediments to Achieving Survivable Systems"
http://www.cert.org/research/isw.html
The Delta Pinnacle Hotel
Vancouver, BC Canada
October 15-17, 2001
Sponsored by the IEEE Computer Society and the US State Department
With support from the Government of Canada
Organized by the CERT* Coordination Center, Software Engineering Institute
General Chair: John McHugh, CERT*/CC
Program Chair: Corey Schou, Idaho State University
Participation in the workshop is by invitation only. There are two ways to
obtain an invitation:
* Submit a position paper related to the theme of the workshop, by
31 August 2001.
* Submit a request for an invitation, accompanied by a qualification
statement, by 15 September 2001.
Please see the ISW Web site for the complete call for participation,
including detailed instructions on submitting a position paper or a
qualification statement. Check the Web site periodically for updates about
the workshop:
http://www.cert.org/research/isw.html
Please send any questions or comments about ISW-2001 to:
isw-2001@cert.org
* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent
and Trademark Office. Copyright 2001 Carnegie Mellon University.
Please report problems with the web pages to the maintainer