The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 21 Issue 54

Monday 23 July 2001

Contents

Tunnel fire derails Internet service
NewsScan
Calendar software and departed employee
Lawrence Kestenbaum
U.S. Tax refund inspires Home Depot snail-mail spam
Dawn Cohen
Renewal of digital certificate impeded by secure passphrase
Philip Bragg
Security system update leads to insecurity
Bob Van Cleef
Did download failures increase Code Red's success?
Scott Renfro
"This e-mail doesn't contain any viruses"
Aaro J Koskinen
The risks of moving and identity theft
Harry Erwin
Concerns for identity theft are often unheeded
Monty Solomon
What a gas!
William Paul Fiefer
"Know Your Customer" USPS style
Alex Wexelblat
US Airways credit-card snafu
Jed Graef
Bad domain name?
Gene Wirchenko
Banking and Internet broadcast technologies
Daniel Chalef
Re: Polarized sunglasses and LCD frustration
Stephen A. Boyd
Re: Even a fatal error can't kill it
Phil Anderson
Re: SSL encryption that isn't
Jacob Ofir
MSN security upgrade forces new e-mail address
Ami A. Silberman
ISW-2001 - Call for Participation
Howard Lipson
Info on RISKS (comp.risks)

Tunnel fire derails Internet service

<"NewsScan" <newsscan@newsscan.com>>
Fri, 20 Jul 2001 08:52:50 -0700

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]


Calendar software and departed employee

<Lawrence Kestenbaum <polygon@potifos.com>>
Mon, 23 Jul 2001 14:31:52 -0400 (EDT)

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


U.S. Tax refund inspires Home Depot snail-mail spam

<"Dawn Cohen" <COHEND@war.wyeth.com>>
Mon, 23 Jul 2001 10:08:36 -0400

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.


Renewal of digital certificate impeded by secure passphrase

<philip.bragg@technocom.com>
Fri, 20 Jul 2001 16:42:09 +0100

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


Security system update leads to insecurity

<Bob Van Cleef <vancleef@garg.com>>
Mon, 23 Jul 2001 10:41:20 -0700 (PDT)

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


Did download failures increase Code Red's success?

<Scott Renfro <scott@renfro.org>>
Sun, 22 Jul 2001 18:43:09 -0700

  [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.


"This e-mail doesn't contain any viruses"

<Aaro J Koskinen <akoskine@cc.helsinki.fi>>
Mon, 23 Jul 2001 16:59:02 +0300 (EET DST)

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


The risks of moving and identity theft

<Harry Erwin <harry.erwin@sunderland.ac.uk>>
Mon, 23 Jul 2001 18:08:04 +0100

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>


Concerns for identity theft are often unheeded

<Monty Solomon <monty@roscom.com>>
Mon, 23 Jul 2001 14:58:15 -0400

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]


What a gas!

<Paul <yamada@prairienet.org>>
Mon, 23 Jul 2001 14:10:45 -0500

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)


"Know Your Customer" USPS style

<Graystreak <wex@media.mit.edu>>
Sun, 22 Jul 2001 11:00:43 -0400

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]


US Airways credit-card snafu

<"Jed Graef" <jgraef@worldnet.att.net>>
Fri, 20 Jul 2001 16:40:32 -0400

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>


Bad domain name?

<Gene Wirchenko <genew@shuswap.net>>
Fri, 20 Jul 2001 19:06:34 -0700

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]


Banking and Internet broadcast technologies

<Daniel Chalef <daniel@zoo.co.za>>
Sat, 21 Jul 2001 09:00:01 +0200

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]


Re: Polarized sunglasses and LCD frustration (Baker, RISKS-21.53)

<Stephen A. Boyd <UncleHonus@aol.com>>
Mon, 23 Jul 2001 13:35:46 EDT

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]


Re: Even a fatal error can't kill it (Haynes, RISKS-21.53)

<phil.anderson@amsjv.com>
Fri, 20 Jul 2001 12:14:45 +0100

> ... 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 Cwmbrn, Cymru/Wales


Re: SSL encryption that isn't (Ron, RISKS-21.53)

<"Jacob Ofir" <jofir@nortelnetworks.com>>
Thu, 19 Jul 2001 19:30:18 -0400

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


MSN security upgrade forces new e-mail address

<"Ami A. Silberman" <silber@mitre.org>>
Mon, 23 Jul 2001 09:58:44 -0400

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)


ISW-2001 - Call for Participation

<Howard Lipson <hfl@cert.org>>
Fri, 20 Jul 2001 18:11:30 -0400 (EDT)

           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

Top