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 80

Saturday 1 December 2001


Badtrans "worm" can capture keystrokes
Records stolen in Auckland
Richard A. O'Keefe
Calif info: Ask and you shall be removed ... but you've got to ask
"Light turnout" for election
G R Rhodes
The destruction of 7 WTC
Jacob Harris
Connecticut Attorney General website wants Microsoft browsers?
Ed Ravin
How to crash a phone by SMS
Monty Solomon
The Web Never Forgets
Monty Solomon
Risks of computer security education
David Friedman
Re: Let's get really paranoid about e-mail and spam
Walter Dnes
Jason Bennett
Re: Risks of the space in Unix filenames
David A. Moon
Richard A. O'Keefe
REVIEW: "Hackers Beware", Eric Cole
Rob Slade
Info on RISKS (comp.risks)

Badtrans "worm" can capture keystrokes

<"NewsScan" <>>
Tue, 27 Nov 2001 08:28:53 -0700

A malicious program called Badtrans is moving around the Internet and
worming itself into vulnerable computers and using a keystroke logger to
surreptitiously record passwords, credit data, and other information.  A
virus manager at the security firm McAfee says that the worm "does no damage
to files but does drop a backdoor trojan on the machine which would allow a
hacker to come back and access personal information."  Badtrans spreads
through Microsoft's Outlook or Outlook Express e-mail programs and arrives
with an attachment that can be executed simply by reading or previewing it
and doesn't need to be double-clicked or opened separately.  [Reuters/*San
Jose Mercury News*, 27 Nov 2001; NewsScan Daily, 27 Nov 2001]

  [Incidentally, we received a lot of e-mail on Magic Lantern.  Let me
  summarize a little.  Rob Slade questioned whether it was a virus in
  RISKS-21.78.  This is an old battle, because "virus" has become
  overloaded.  Peter da Silva and PGN both insist it is a Trojan Horse.
  Let's get on with it, and use the terminology correctly.  There was some
  discussion on whether or not McAfee et al. will suppress detection of an
  FBI-planted virus, vague denials.  There were some comments about ML being
  used only against bad guys, so what's the problem (slippery slope there).
  Tony Harminc remarked that collection need not be real-time if a Trojan
  horse is collecting the info for later dissemination.  Dave Farber
  wondered about the possibility of disguising a really nasty virus so that
  it would slip through the mechanism that intentionally failed to detect
  ML.  Several folks resurrected the old argument that the ability to insert
  malware actually weakens security.  PGN]

Records stolen in Auckland

<"Dr Richard A. O'Keefe" <>>
Thu, 29 Nov 2001 14:24:35 +1300

  Thousands of people's financial details have been stolen in a myster
  burglary in Auckland.  Burglars broke through 24-hour security at New
  Zealand Funds Management's offices in the ANZ Centre the weekend before
  last.  They stole computer tapes with clients' names, addresses, bank
  account numbers, how much they had invested, as well as financial
  advisers' computer passwords.

  NZ Funds Management has about 25 000 clients throughout New Zealand, with
  about NZD 1.6 billion (about UDS 670 million) invested.  The high-rise
  centre has swipe-card access, video security cameras, and security guards
  24 hours a day, but the burglars got in at 4am the Saturday before last.
  They got away with computer taps holding the client information.  Only one
  office was broken into and only the computer tapes stolen.  Left behind
  were laptop computers and other equipment. ---NZPA
  [Source: *Otago Daily Times*, 26 Nov 2001, p. 28]

Strong cryptography wouldn't have helped.  Completely avoiding the use of
virus-friendly software wouldn't have helped.  As for physical security,
they had it.  And the information was stolen anyway.  Without knowing
anything about the people involved, or having any expertise beyond that
common to all readers of detective stories, I must say that it looks
uncommonly like an insider job.

The distributed techniques that have been worked out in response to the
Napster case, could they help to protect against loss of records like this?
But wouldn't having businesses distributed their data over thousands of
other business's machines create RISKS of its own?

Calif info: Ask and you shall be removed ... but you've got to ask

<"NewsScan" <>>
Fri, 30 Nov 2001 09:05:04 -0700

Responding to complaints by consumers and privacy advocates who protested
California's legal sale to the Web genealogy company of public
information containing such personal data as people's birth dates and their
mothers' maiden names, the company now says it will remove from its Web site
the names of anyone who makes a specific request.  A spokesman for the
company said: "The mission of our company is to create places to help people
reconnect with their families. We're not in any way doing anything except
helping our customers and if a customer is concerned about it, it doesn't do
any good to leave them up on the site."  A legal council for the Electronic
Privacy Information Center says that California's sale of data to the
genealogy Web site "a situation where all the residents of California have
now been exposed to a new risk of identity theft." [*San Jose Mercury News
30 Nov 2001*; NewsScan Daily, 30 Nov 2001]

  [The birth records of more than 24 million Californians are involved.  PGN]

"Light turnout" for election

<grr/sll <>>
Wed, 28 Nov 2001 16:45:55 -0500

During the recent election (November) here, a power outage occurred during
voting hours. It lasted several hours and affected an estimated 10,000
people in portions of northern Allegheny and adjacent counties (north of
Pittsburgh, Pennsylvania, USA). Initial news reports noted concerns that the
voting machines would not work without electricity. From what I've gathered,
most of the machines were lever-style machines, and had a provision for
manual power (i.e., a crank) to tally the votes and reset the levers after
each voter.

But what would have happened if they had used computer or other electronic
voting, or another machine that required electricity to work? It seems
dubious that backup power systems (15+ hour capacity) would be provided for
all the polling places. How would the election process be affected, and when
would the "powerless" voters vote? Would the election results be held up for
this? -- it seems that they would have to be. [Of course, no one can predict
how this might affect, or not, any election in Florida.  ;-)]

Coincidentally, it was a relatively "minor" election, with few major offices
or issues at stake, so fewer voters than normal showed up to vote. Around
here, that's called a "light turnout" of voters. But, as they read their
copy describing the local voting predictions and the "light turnout," not
one of the newscasters gave any sign that they understood the pun.

  [And yet it is not difficult to have a shocking experience even when there
  is no electricity!  PGN]

The destruction of 7 WTC

<"Jacob Harris" <>>
Fri, 30 Nov 2001 10:06:24 -0500

While we know all too well about the horrific destruction of the two main
towers at the World Trade Center (1 and 2 WTC), not as many people are aware
of the destruction of nearby 7 WTC nearby approximately 8 hours after the
initial impact. While the building sustained structural damage from falling
debris and the collapse of the main towers, it was also consumed by a raging
fire that seems to have caused similar catastrophic structural failure. This
article in *The New York Times*
  <> (reg required)
indicates that a likely cause of that fire was the approximately 42,000
gallons of diesel fuel (6K gallons on the seventh floor, 36K in the
basement) stored in the building to power backup generators for the City's
emergency command center located there. This fuel was apparently ignited
(the fireproof tanks may have been ruptured by debris) and burned intensely
in the building's core to cause the collapse. Of course, the aforementioned
emergency center was unusable in this emergency, and the city was left
scrambling to setup another facility for emergency coordination (City Hall
was too close to the accident site). Finally, according to an earlier NY
Times article, this building also housed a regional CIA office whose
destruction has hindered some intelligence and investigation efforts.

As has been noted previously, the 9/11 disaster has illustrated all sorts of
risks that are gruesome to contemplate. In hindsight, locating the emergency
coordination center at the location of a potential emergency was
unfortunate, and the lack of a backup emergency coordination center
compounded the problem. And it is ironic how preparedness for one common
emergency (power outages) can create a vulnerability in itself. I'm sure
there are a lot more sites looking more nervously at their backup fuel
supplies these days.

Connecticut Attorney General website wants Microsoft browsers?

<"Ed Ravin" <>>
Wed, 28 Nov 2001 12:48:47 -0500 (EST)

A friend just sent me a pointer to the announcement that the Connecticut
Attorney General is opposing the Microsoft settlement.  The URL for the
announcment is:

When I surf over there with my Opera 5.0 or Netscape 4.77 browser running on
Linux, I get this error page:

  This site requires JavaScript to be enabled.

  The Web browser that you are using does not have JavaScript
  enabled, or is not a JavaScript-capable browser.  [...]

The link to "upgrade your browser", naturally, suggests that I use Microsoft
Internet Explorer or Netscape.

(1) I shouldn't have to enable JavaScript just to read your press releases,
but more importantly, (2) both browsers that I tried, Netscape 4.77 and
Opera 5.0, running under Linux, have JavaScript enabled already.  Something
is clearly broken here.

It is ironic that the Attorney General's attempts to fight Microsoft's
market dominance are undermined by a Web site that insists that its users
switch to Web browser software provided by the market leaders.  Talk about
anti-competitive forces!

Ed Ravin  <>

How to crash a phone by SMS

<Monty Solomon <>>
Wed, 28 Nov 2001 22:22:08 -0500

How to crash a phone by SMS
By John Leyden
Posted: 28/11/2001 at 18:20 GMT

So now you can send an SMS and crash a mobile phone, so that the user is
locked out.  Job de Haas, a security researcher at ITSX, has adapted a
program called sms_client, which sends an SMS message from an
Internet-connected PC, in which the User Data Header is broken.

During a presentation during the Black Hat conference last week, he
demonstrated how a malformed message crashes a Nokia 6210 phone on its
receipt. Once the message is received it is impossible to turn on an
infected phone again.  ...

The Web Never Forgets

<Monty Solomon <>>
Wed, 28 Nov 2001 22:21:33 -0500

The Web Never Forgets, David Colker, Los Angeles Times, 27 Nov 2001

Government agencies have tried to remove sensitive information, only to
discover that copies have proliferated and they're virtually impossible to
eradicate.  Within days of the 11 Sep attacks, the federal Agency for Toxic
Substances and Disease Registry rushed to pull a suddenly sensitive report
from its Web site titled "Industrial Chemicals and Terrorism."  The agency
eliminated all traces of the document and its description of sources for
home-brew nerve gases and improvised explosives.  But on the World Wide Web,
almost nothing truly dies.  [...]

Risks of computer security education

<David Friedman <>>
Fri, 30 Nov 2001 13:29:06 -0500

When Gary McGraw gave a talk to our Cryptology/Computer Security class at
University of Virginia, one of the things he mentioned is that the "bad guys
are a lot better at sharing than the good guys."

On Monday we had project presentations, and a group of students told the
class how to exploit a serious security vulnerability present on any of the
Lab PCs on grounds. The students had not told the system administrators of
the machines about the vulnerability.

The RISK of educating people about computer security is nobody knows how the
people getting educated are going to use their knowledge.

In this case I don't think my fellow students were acting maliciously. They
simply didn't expect anybody to use the knowledge to do damage. It was a
case of the "good guys" not sharing.

David Friedman

Re: Let's get really paranoid about e-mail and spam (Hurst, R 21 78)

<"Walter Dnes" <>>
Fri, 23 Nov 2001 23:21:14 -0500

The general risk here is the use of software in conditions it was never
designed to be run under.  SMTP (*SIMPLE* Mail Transfer Protocol) is called
that for a reason.  It was designed to be run in a trusted environment --
i.e., for communications between researchers, professors, and military
people who had sufficient security clearance to be allowed onto the ARPANET
in the first place.  It was never designed to thwart misdirection and
forgeries by sleazy scammers, i.e. no built-in authentication.  Servers were
few and far between, run by a small community of administrators who probably
knew each other on a first-name basis.

There is a spammer sub-culture (I use the term "culture" rather loosely) and
also an anti-spammer culture, which are visible on various spam-fighting
forums/mailing-lists.  What you see here is probably the result of a
"dictionary attack".  The following description is a simplification, and is
not 100% technically exact.  A service paid for or run by spammers will set
up a script to probe an ISP's smtp server.

 - if the smtp server supports the EXPN and/or VRFY commands an effective
   procedure is to establish an smtp connection to "".  Then
   run those commands inputting addresses like,,, etc, etc.  A smarter script
   will use a dictionary of common names to increase the percentage of hits.
   The server will obligingly tell the connecting end which addresses are
   for real, and which are invalid.

 - if the smtp server has EXPN/VRFY disabled, another approach is to
   run a bogus mass-mailing.  Each e-mail transaction starts the
   process and gets as far as supplying the "To:" address.  If the
   receiving smtp server rejects an address, it's obviously invalid.
   If the smtp server responds OK, then the address is valid.  The
   script will abort and tear down the e-mail transmission in that
   case, and get on with testing the next e-mail address.

With today's fast computers and broadband, the above is feasible.

Spammers forge return addresses.  This prevents the originating machine from
getting e-mail-bombed if several percent of a multi-million spam run are
invalid addresses, or the targets' ISPs have spam-blocking of some sort.  At
first spammers put in gobbledygook into the return address.  Then ISP's
started refusing e-mail from domains that didn't exist (this is a quick
lookup against DNS).  So spammers resorted to forging random email addresses
at valid domains.  Occasionally, the forgery will be identical to a valid
e-mail address, and innocent people get the bounces.

>  how on earth did the spammers "harvest" my specific MyRealBox account name

They probably used some "" forgery, as
mentioned above.

>  (And are there any steps one can take to prevent it from happening again?)

Not very much.  You could try a long gobbledygook-type e-mail address that
is less vulnerable (nothing is invulnerable) to a dictionary attack that is
biased to common names.  The disadvantage is that your friends and business
associates will have problems remembering your e-mail

>  This also brings to mind the risk of using a "free" Internet e-mail

Actually, the risk is in signing up with any ISP/e-mail-service with
millions of valid e-mail addresses where a dictionary attack will return a
lot of hits.  You're less likely to run into this on a smaller ISP.

Walter Dnes <>

  [SMTP EXPN also noted by Doug Sojourner, in very similar discussion.  PGN]

Re: Let's get really paranoid about e-mail and spam (Hurst, R 21 78)

<Jason Bennett <>>
Tue, 27 Nov 2001 02:21:55 -0500

Allan's story about all his mailboxes getting hit with spam doesn't really
surprise me.  I strongly suspect that he was the victim of a dictionary
attack (mentioned several times before in RISKS).

When I started a new job last year, my e-mail account was set up a couple of
weeks before I started (I had to move several hundred miles for this
job). When I did start, I found my mailbox containing several hundred spams!
I had, unfortunately in this case, been assigned the e-mail address of
jason@domain. It was pretty much a given that most domains would contain an
address of "jason," and so I got caught in those spam dragnets. Whenever I
would go on vacation, I would come back to several hundred junk messages.

Lesson? An easier e-mail address is easier for everyone.

Jason Bennett,

  [We had a lot of e-mail on this topic.  PGN]

Re: Risks of the space in Unix filenames (Spinellis, R 21 79)

< (David A. Moon)>
28 Nov 2001 08:50:33 -0800

Some of Mr. Spinellis' suggested fixes won't help when a quote character
appears in a filename.

This "requoting problem" has been known since before Unix even existed, at
least within the Multics community.  I remember encountering it myself in
1971 or 1972 in the exec_com facility of Multics.

The root cause and the real source of the risk here is the attempt to use an
interactive command language as a programming language.  It's evidently a
very seductive temptation, since the mistake has been repeated many times by
many people, but in the end that approach just can't work.  A programming
language needs a syntax and semantics that don't confuse the data being
processed with the program doing the processing.

Re: Risks of the space character in Unix filenames

<"Dr Richard A. O'Keefe" <>>
Thu, 29 Nov 2001 14:15:21 +1300

I can't be the only RISKS reader with an MPW documentation set, can I?
Apple has had a UNIX-like shell for many
years.  Let me quote page 3-18 of "Introduction to MPW" (that's
*M*acintosh Programmer's Workshop):


  In general, when a parameter contains a space, you must enclose it in
quotation marks
  so that the MPW Shell recognizes it as a single parameter.

and page 3-19:

  Place quotation marks around parameters that contain spaces.

While UNIX may (perhaps!) have been new to Apple programmers, the need for
quoting parameters that contain spaces certainly wasn't.

REVIEW: "Hackers Beware", Eric Cole

<Rob Slade <>>
Mon, 26 Nov 2001 07:59:28 -0800

BKHKRBWR.RVW   20010829

"Hackers Beware", Eric Cole, 2001, 0-7357-1009-0,
%A   Eric Cole
%C   201 W. 103rd Street, Indianapolis, IN   46290
%D   2002
%G   0-7357-1009-0
%I   Macmillan Computer Publishing (MCP)
%O   U$45.00/C$67.95/UK#34.99 800-858-7674 317-581-3743
%P   778 p.
%T   "Hackers Beware: Defending Your Network from the Wiley Hacker"

It is difficult to maintain confidence in a book that, within six sentences
of the opening of the first chapter, misspells the word "brakes."  We are
told that two developmental editors, two copy editors, two proofreaders, and
no less than five technical reviewers had at this work.  Did any of them pay
attention to what they were reading?

Chapter one basically states that dangers are out there, security is bad,
and companies should be concentrating on prevention, detection, and
education.  Cole also nudges at the "hacking for protection" theory, without
ever really examining it.  A brief but reasonable list of security breaking
activities is given in chapter two.  Various steps and tools involved in
gathering information about a network connected to the Internet are
described in chapter three.  Unfortunately, this explanation, while helpful
to a potential attacker, has no utility for the defender: almost all of the
data discussed must be publicly available for the network to function, and
so there are no means of blocking this level of access.  Spoofing, or
masquerading, is dealt with in chapter four, but again, while some
protective measures are provided, much more time is spent on the disease
than the cure.  After twenty six pages of telling you how to hijack
sessions, including the best programs to use and how to operate them,
chapter five gives us two pages of simplistic advice (avoid remote
connections) on protection.  Chapter six lists a number of common denial of
service attacks and, while it does devote a lot of ink to describing the
exploits, the material is reasonably balanced, and the suggested defensive
measures realistic.  Chapter seven requires almost forty pages to tell us
that buffer overflows are not good, and you should apply software patches.
Password security is very important, but the material in chapter eight is
vague, disorganized, and has relatively little to say about good password
choice.  (Chapters nine and ten describe some NT and UNIX password cracking
programs.)  The examination of background fundamentals of NT, in chapter
eleven, is a terse and unfocused grab bag of information.  The analysis It
would be of little help in explaining the specific attack programs listed in
chapter twelve, a number of which rely on particular applications.  The same
relation is true of chapters thirteen and fourteen, relating to UNIX.  A
number of backdoor and remote access trojan programs are described in
chapter fifteen.  Chapter sixteen discusses log files, and lists some
programs for generating spurious network traffic in order to hide attacks.
Some random exploits are listed in chapter seventeen, and a few more in
eighteen.  An attempt is made to combine various attacks into scenarios, in
chapter nineteen, but these do not add anything to the material already
provided.  Chapter twenty is the usual vague look to the future.

This book takes the all-too-common approach of assuming that teaching you
how to break into systems will help you to protect them.  The work also
amply demonstrates the fallacy of that argument.  While the harried systems
administrator spends several hours coming to grips with the minutiae of the
attacks described, the vast majority of the exploits listed can be countered
simply by ensuring that software patches are up to date.  In addition, while
dozens of loopholes are listed in these pages, thousands more exist that are
not covered.  The material contained in these pages may be entertaining, but
it is of far more use to the attacker than to the defender.  This would be
upsetting, were it not for the fact that most of the exploits described are
old and not likely to remain unpatched if administrators are keeping up to
date.  (Of course, many small outfits can't commit a lot of resources to
keeping up to date ...)

For security specialists, this volume provides nothing that can't be found
elsewhere.  For non-specialists, it fails to supply a security framework and
strategy within which to work.

copyright Robert M. Slade, 2001   BKHKRBWR.RVW   20010829

As usual, a draft has been sent to the author.  He has requested that
this response be included, unedited:


First allow me to say thank you for taking the time to review the book
as criticisms are as crucial as praise. We take your feedback
seriously. That being said, let me see if I might speak to some of
your discussions on "Hackers Beware".

When you buy "Hackers Beware", you buy it for the technical content.  While
we maintain that this faction of the book is air-tight and well- supported,
we also admit that we could and should have done a better job with edits on
spelling and grammar. While we admit that shortcoming, we also ask that you
look at the eleven reviews posted on Amazon, praising the technical content
of my book and earning it FIVE- STAR rating.

The book starts opens with some introductory material but does that for a
reason. Much of the security information that companies need to protect
their site is straightforward. Yet companies systems are still hacked into
with a growing frequency because they fail to understand how to build a
proper defense. So my book aims to ensure that everyone is well, if not
over-educated on DEFENSE.

There are many books on hacking but what makes this book different is its
emphasis on defense. Yes, you need to understand how the enemy breaks into
systems, so you can build better defenses. Every section has an area on how
to defend against a certain type of attack. So I am not sure how a review
can say that defense is not covered when that is the thrust of this
book. There are plenty of books that show you how to break in. This book
clearly and explicitly explains the properties of a strong defense.

Thanks for letting me write a response.  Eric    or

Please report problems with the web pages to the maintainer