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 23 Issue 15

Monday 2 February 2004

Contents

E-mail activity: VaVaVoom MyDoom!
PGN
Risks of virus scanners
Steve Bellovin
AP blames virus transmission on users
Kevin Dalley
US-CERT warns of worm, forgets to mention operating system
Kevin Dalley
More controversy over SERVE Internet voting project
Dan Keating via Lillie Coney
Finally! The Nigerian e-mail scammers caught
NewsScan
Re: Spirit Rover humbled
Paul Czyzewski
Mark Brader
Dan Riley
Re: UK data protection laws and ... Unintended Consequences
Richard Pennington
Dave Harris
Mark Brader
Google targeted by pranksters
Monty Solomon
On paypal and eBay scams
John Sinteur
Postbank spoofing
Talmon
Disciplinary action for teaching someone to use the address bar?
Neil Youngman
REVIEW: "The Hanged Man's Song", John Sandford/John Camp
Rob Slade
REVIEW: "Defense and Detection Strategies Against Internet Worms", Nazario
Rob Slade
Info on RISKS (comp.risks)

E-mail activity: VaVaVoom MyDoom!

<"Peter G. Neumann" <neumann@csl.sri.com>>
Mon, 2 Feb 2004 9:41:36 PST

SpamAssassin is now trapping over 1100 e-mail spam messages to me and RISKS
each day.  IN ADDITION to that, the recent malware activity (MyDoom, etc.)
is awesome.  After putting out RISKS-23.14 on 27 Jan, I did not get a chance
to look at the RISKS mailbox until this morning, and there were 2528 NEW
messages, of which only about 40 were legitimate postings.  Note that I run
absolutely *no* MS software, so don't bother to blame me for any of the
bogus e-mail that seems to come from RISKS.

Subject     Messages
-------     ------
test         407
hi           296
hello        240
status       197
mail deliv.. 188
mail trans.. 185
returned ma. 161
error ...     89
server report 85
undeliver...  77
failure not.  67
... virus ..  44
and many many more with gibberish that I deleted on the basis of their
subject lines alone.

Many thanks to those of you who remember to use the helpful tag string
[noted in the last message in each issue, and which will change as soon as
the spammers start using it].  That tag really encourages me to look at your
e-mail first -- or even at all.  It also enables me to scan through the
thousands of items that SpamAssassin traps, and I think I have found only
one legitimate message that got caught in its web.  (My sincere regrets if I
accidentally deleted any of your legitimate messages.)

Incidentally, RISKS is hugely backlogged at the moment, with material for
about three issues waiting for catching up -- without even thinking about
everything that this issue will generate.

Side note: MyDoom hit SCO yesterday at midnight, as predicted, infecting PCs
beginning in New Zealand.  SCO was reportedly completely paralyzed by the
denial of service attacks, which are expected to continue through 12 Feb.


Risks of virus scanners

<Steve Bellovin <smb@research.att.com>>
Wed, 28 Jan 2004 21:56:26 -0500

For fairly obvious reasons, I just upgraded a family member's anti-virus
software.  She asked me to check a suspicious message; when I saw that the
body said "The message contains Unicode characters and has been sent as a
binary attachment," I knew what I was dealing with.

Of course, the AV software did detect it, and dealt with it in an
appropriately permanent fashion.  But how did it notify the user of what it
found?  It created a .txt file -- as an attachment in the e-mail message...

How long, I wonder, till a virus uses that exact filename and syntax to
hide behind?  Recall that MyDoom is already calling itself things like
"document.txt                      .scr" and the like, to try to hide
the real extension.  Why are the good guys trying to teach people to
click on attachments?


AP blames virus transmission on users

<Kevin Dalley <kevin@kelphead.org>>
Wed, 28 Jan 2004 19:32:13 -0800

Anick Jesdanun, an AP Internet Writer, wrote an article stating:

  The continued spread of a cleverly engineered computer virus exposes a key
  flaw in the global embrace of technology: Its users are human.

The article is available at:
  http://story.news.yahoo.com/news
  ?tmpl=story&cid=528&e=4&u=/ap/20040128/ap_on_hi_te/e_mail_worm

The e-mail contacts an attachment marked
    application/octet-stream; text.zip
or
    application/octet-stream; data.zip

Unzipping the file gives you an executable, perhaps data.scr or text.pif,
again with a misleading name.  Unfortunately, the mail reader knows how to
unzip and execute the file without any warning to the user.

Anick blames the user's trust for the damage.  If the user were warned
before the file were executed, the problem would not be as serious.

comp.risks has covered this topic in 20:44, in June, 1999, where
Steven M. Bellovin says:

  The underlying problem is that there are two different mechanisms used to
  determine file type, and hence how it should be "opened".  One is what is
  displayed to the user; the other is what is actually used.  That way lies
  danger.


US-CERT warns of worm, forgets to mention operating system

<Kevin Dalley <kevin@kelphead.org>>
Wed, 28 Jan 2004 23:26:31 -0800

In one of its first actions, US-CERT issued a warning about the
MyDoom.B worm.  Unfortunately, US-CERT forgot to mention the operating
systems which are susceptible to attack from the worm.  The technical
warning is available at:

http://www.us-cert.gov/cas/techalerts/TA04-028A.html

The warning contains hints that the OS is some form of Windows,
mentioning the Windows System directory, but doesn't come out and
identify any operating systems.

On the other hand, CERT's (without "US") warning of Novarg.A worm:

http://www.cert.org/incident_notes/IN-2004-01.html

has a link titled "Steps for Recovering from a UNIX or NT System
Compromise".  CERT doesn't mention the susceptible operating systems,
either, but one could assume that UNIX is at risk.

Chew on these CERTs and you will be lucky to see a spark of light.


More controversy over SERVE Internet voting project (RISKS-23.14)

<Lillie Coney <lillie.coney@acm.org>>
Fri, 30 Jan 2004 12:35:12 -0500

In a joint letter being sent to several congressional committees, Republican
and Democratic party organizations for citizens living abroad are opposing
the Pentagon's SERVE system for Internet voting in the forthcoming
presidential election.  About 100,000 ballots are currently expected to be
cast using this system, in 50 counties.  [Source: Bipartisan Request Seeks
Halt to Internet Voting: Groups Fear Citizens Abroad Will Be Compromised,
Dan Keating, *The Washington Post*, 30 Jan 2004, Page A19; PGN-ed]


Finally! The Nigerian e-mail scammers caught

<"NewsScan" <newsscan@newsscan.com>>
Mon, 02 Feb 2004 08:52:18 -0700

Police in the Netherlands have arrested 52 people suspected of using the
so-called "Nigerian e-mail scam" to defraud Internet users by sending them
spam e-mails asking for their help in transferring a large sum of money out
of Nigeria or some other troubled country in exchange for a generous
percentage-fee. A task force of 80 officers raided 23 apartments, seizing
computers, fake passports and 50,000 euros ($62,000) in cash. Most of those
arrested were believed to be Nigerian.  [Wired.com, 2 Feb 2004, NewsScan
Daily, 2 Feb 2004]
  http://www.wired.com/news/ebiz/0,1272,62124,00.html?tw=wn_tophead_5

  [Observing how scam e-mail has increased, I suspect that this is still
  just the tip of the viceberg.  PGN]


Re: Spirit Rover humbled (RISKS-23.14)

<Paul Czyzewski <paulcz@speakeasy.net>>
Wed, 28 Jan 2004 00:57:15 +0000

The article mentioned,
http://spaceflightnow.com/mars/mera/040126spirit.html
contains this statement:

  "Spirit bogged down because it didn't have enough random access memory, or
  RAM, to handle the current amount of files in the flash -- including data
  recorded during its cruise from Earth to Mars and the 18 days of
  operations on the red planet's surface"

Does anyone reading RISKS know how they test mission software, and how
rigorously?  It's nearly unbelievable that "what happens when Spirit
accumulates lots of files?" apparently wasn't tested.


Re: Spirit Rover humbled (RISKS-23.14)

<msb@vex.net (Mark Brader)>
Wed, 28 Jan 2004 02:17:08 -0000

> ... variant of the classic "fixed length buffer" error?

Wouldn't this actually be a variant of the classic "failure to detect and
recover sensibly from a full disk" error?  Not at all the same thing.


Re: Spirit Rover humbled (RISKS-23.14)

<Dan Riley <dsr@mail.lns.cornell.edu>>
29 Jan 2004 19:07:34 -0500

I would have thought the reason it rebooted so many times is precisely
because there isn't a sysadmin handy.  Nothing terrible will happen if the
rover reboots--it doesn't fall flaming from the skies or fall over a cliff,
it doesn't threaten the lives of astronauts, it simply sits immobile on the
(apparently lifeless and inactive) surface of mars for a minute or two while
it reboots.  However, if the rover software gets locked into a state it
can't recover from, it is lost--there is no one there to push the reset
button (except, hopefully, a deadman timer).  Given those conditions, it
seems like sensible RISKS engineering practice to make the best try at
restoring a known system state--by rebooting--at the slightest sign of an
inconsistency in the system state.  It obviously also needs some sort of
"safe mode" that depends on as little hardware as possible and allows
mission control to intervene--and apparently that exists.


Re: UK data protection laws and ... Unintended Consequences

<Richard Pennington <richardhelen.pennington@virgin.net>>
Wed, 28 Jan 2004 23:26:03 +0100
  (Correction, RISKS 23.14)

I am afraid that I have to make a correction to my posting in RISKS-23.14.
My posting covered two particular cases, and the correction refers to case
1.

1. It has been brought to my attention that although the perpetrator's
earlier home town is in North-East Lincolnshire, the local police is not in
fact Lincolnshire Police but Humberside Police, and therefore Lincolnshire
Police were in no way responsible for the events described.  I therefore
offer my apologies to all concerned at Lincolnshire Police.

2.  It has also been brought to my attention that the Data Protection
Registrar has been re-titled the Information Commissioner.

I am also indebted to Graham Smith for pointing me at the following relevant
news item from the BBC news website (which explains both cases far better
than I ever could):
  http://news.bbc.co.uk/1/hi/uk/3395071.stm

There is certainly room for debate on the conflict between (a) the
presumption of an individual's innocence until proven guilty, and (b) the
requirement to protect society at large (and children and the vulnerable in
particular), in the case where an individual repeatedly attracts the
attention of the police without ever being brought to court.


Re: UK data protection laws and ... Unintended Consequences (R-23.14)

<brangdon@cix.compulink.co.uk (Dave Harris)>
Thu, 29 Jan 2004 19:55 +0000 (GMT)

> The caretaker later murdered two of the schoolchildren (aged 9 and 10).

This implies the children went to the school where the caretaker worked.
Not so. They went to a different school, and the murderer came into contact
with them through his girlfriend (who did work at their school).  It is
likely that the murders would have happened even if the caretaker was denied
his job.

You can discover more details of the case by searching on the caretaker's
name, "Ian Huntley". There is a summary at:
    http://en.wikipedia.org/wiki/Ian_Huntley

The previous accusations against Huntley were unproven. The risk to the
children has to be balanced against the risk of unfounded allegations being
allowed to destroy the career of an innocent man.


Re: UK data protection laws and ... Unintended Consequences (R-23.14)

<msb@vex.net (Mark Brader)>
Wed, 28 Jan 2004 02:40:28 -0000

> The resulting inquiry revealed that the caretaker, while in Lincolnshire,
> had been the subject of multiple relevant allegations (indecent assault
> and worse), none of which had ever been brought to court. ...

So "Innocent until proven guilty" is now an Unintended Consequence?  Remind
me never to have anyone make false allegations of serious offenses against
me next time I'm in England.  Oh, wait, how do I do that?

Not to say that what is described is not a tragedy, but if there is fault to
be found with the police, it's *not* for not telling the school about the
earlier cases.  It's for failing to get the criminal tried and convicted
back then.  And even this is only true if the earlier alleged offenses were
genuine.  (One can imagine an unlikeable person being the subject of false
allegations and later turning to actual crime.)

> As a result, the various investigations in Lincolnshire never heard
> about each other ...

And that'd be their fault too.  For police, it *is* reasonable to consider
that someone previously suspected should be suspected again: this is all
right precisely because a police suspect is not, ipso facto, a criminal.


Google targeted by pranksters

<"Monty Solomon" <monty@roscom.com>>
Mon, 26 Jan 2004 17:38:49 -0500

Google targeted by pranksters: Web site operators, bloggers skew results
Verne Kopytoff, *San Francisco Chronicle*, 26 Jan 2004

Who among the many candidates running for president is unelectable?  George
W. Bush -- if the search results on Google can be believed.

His biography is the first result to appear on Google for the Web query
"unelectable." It's just one in a long list of similarly bizarre results on
the search engine over the years that are the result of manipulation, not
their relevance.

Called Google bombs, these are pranks engineered by Web site operators and
creators of Web logs.  They take advantage of the way Google ranks search
results to get certain Web sites listed higher for specific queries than
they otherwise would be.

That's why President Bush's biography also appears as the top result for
the search query "miserable failure."  ...

http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2004/01/26/BUG3M4GVDS1.DTL


On paypal and eBay scams (Re: RISKS-23.13)

<John Sinteur <john@sinteur.com>>
Sat, 17 Jan 2004 11:16:05 +0100

>  [This is increasingly becoming a problem!  We desperately need
>  some greater authentication and accountability.  PGN]

It will get worse very soon. I've received several e-mails, apparently from
paypal, about a UK branch they are setting up, announcing the move of just
about all european customers to that branch instead of the US one.  None of
the messages so far have asked me to take any action, so I haven't bothered
to check if paypal is indeed moving to the UK or not.  Personally I will
check every move very carefully, DNS registry, https certificates,
etc... This is in itself already a Risk, since paypal must now assume on
every administrative mail they send that people will simply not believe
them, but the bigger risk is that I'm probably almost alone in these
checks. Anybody want to bet scammers will attempt to abuse potential
confusion round the move to paypal.co.uk (if it is real) for their own
phishing expeditions?


Postbank spoofing

<Talmon@MI.unimaas.nl>
Tue, 20 Jan 2004 08:54:36 +0100

Not only PayPal users are being tricked into providing sensitive
information. In The Netherlands an e-mail has circulated that asked Postbank
clients who use electronic banking to provide user identification and
password information.  They used a similar approach as in the PayPal
case. The e-mail contained what looked like a proper webaddress, but when
looking at the source (it was an HTML message) another web address was
hidden there. By clicking on the link, you got to a non-Postbank website,
with ordinary http: rather than https:.

I was warned by the fact that the e-mail was delivered to my work e-mail
address rather than my private e-mail address. In addition, the language of
the mail was more Flamisch (the Belgian variant of Dutch) than proper Dutch.

The Postbank had a warning about this e-mail on the home page of their
website on the same day as I received the e-mail.


Disciplinary action for teaching someone to use the address bar?

<Neil Youngman <n.youngman@ntlworld.com>>
Sat, 17 Jan 2004 09:43:20 +0000

On the Hertfordshire Linux User Group mailing list there is a bizarre story of
a teacher disciplined for teaching a student to use the address bar
(http://mailman.lug.org.uk/pipermail/herts/2004-January/000198.html)

"Early last year (during her previous stint at my school) I was accused
of "hacking the server" (FYI, there are at least 3 servers).

Investigation, letters and phone calls by concerned parents showed that
the actual concern was that I had informed a student in Year 9 how to
use "about:some_HTML_here" in the address bar, to test HTML on the fly
in IE.

He then used it to do "about:<a href="\\server1">server1</a>". For the
un-HTML-enlightened among us, this would create a blank page with a link
to \\server1, which would show a normal Explorer Window with all the
shared folders on server1. What else that student did I was never told."

I can't see that this offers anything you couldn't get via network
neighbourhood, but then I'm no Windows expert. FWIW, I tried this on IE6/W2K
and got no more than an error message.

RISKS here are more of technophobia than direct RISKS of technology.


REVIEW: "The Hanged Man's Song", John Sandford (John Camp)

<Rob Slade <rslade@sprint.ca>>
Mon, 26 Jan 2004 08:32:27 -0800

For a bit of lighter relief:

BKHGMNSG.RVW   20031112

"The Hanged Man's Song", John Sandford (John Camp), 2003,
0-399-15139-7, U$25.95/C$39.00
%A   John Sandford (John Camp) js@johnsandford.org
%C   375 Hudson Street, New York, NY  10014
%D   2003
%G   0-399-15139-7
%I   Berkley
%O   U$25.95/C$39.00 http://www.berkley.com/berkley online@penguin.com
%O  http://www.amazon.com/exec/obidos/ASIN/0399151397/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0399151397/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0399151397/robsladesin03-20
%P   321 p.
%T   "The Hanged Man's Song"

It is always a delight to find a new John Sandford/John Camp novel, a
pleasure that is unalloyed by any regrets and annoyances in regard to
technical goofs.  As was the quality of the technical material in "The
Fool's Run" (cf BKFLSRUN.RVW) and "The Devil's Code" (cf.
BKDVLSCD.RVW), so it is with "The Hanged Man's Song."

The technology is firmly grounded in reality.  The communities, both
blackhat and law enforcement, do not have the jarring quality found in
all too many works where the author becomes fascinated with "hackers."
(Having lugged around a number of "development" laptops in order to
demonstrate company products, I was wryly glad to find that someone
else knows that not *all* such machines are featherweights  :-)  There
is an intriguing idea for distributed backup of secure-but-secret
data, although I suspect that even very young computer wizards would
very quickly act to close loopholes and find anomalies.

I'm a bit surprised that a careful and paranoid group, such as is
described in the novel, did not take more care with authentication,
perhaps through a "web of trust" model, but I suppose that would have
gotten in the way of the plot.  Onion routing would also have been
handy for these people, but, again, would not be as exciting.  (I also
want to get my hands on that quad track DVD-R: the best I can find for
my own systems is the basic single track that only lays down 5-6
gigs.)

The main complaint I would have with this particular work is that the
technology seemed somehow divorced from the primary thread of the
plot.  This seems an odd statement to make, given the three-cornered
race by technically savvy people, turning primarily on computer
forensics and data recovery, but I was left feeling that this was more
akin to an old-fashioned chase thriller.  Albeit an interesting one.

copyright Robert M. Slade, 2003   BKHGMNSG.RVW   20031112
rslade@vcn.bc.ca      slade@victoria.tc.ca      rslade@sun.soci.niu.edu
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade


REVIEW: "Defense and Detection Strategies Against Internet Worms",

<Rob Slade <rslade@sprint.ca>>
Wed, 21 Jan 2004 07:35:36 -0800
  Jose Nazario

BKDDSAIW.RVW   20031128

"Defense and Detection Strategies Against Internet Worms", Jose
Nazario, 2004, 1-58053-537-2, U$85.00/C$131.95
%A   Jose Nazario jose@crimelabs.net
%C   685 Canton St., Norwood, MA   02062
%D   2004
%G   1-58053-537-2
%I   Artech House/Horizon
%O   U$85.00/C$131.95 800-225-9977 artech@artech-house.com
%O  http://www.amazon.com/exec/obidos/ASIN/1580535372/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/1580535372/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1580535372/robsladesin03-20
%P   287 p.
%T   "Defense and Detection Strategies Against Internet Worms"

The preface states that the book is intended for security
professionals, security researchers, and academics in the field of
computer science.  It is obvious that the author has attempted to
write the material in a scholastic tone, but the necessary rigour and
structure of thought is missing.

Chapter one, an introduction of sorts, provides random information of
questionable utility, such as the table listing the discovery of
vulnerabilities compared against the time that elapsed before those
loopholes were first released in active worms: no particular pattern
seems to be indicated.

Part one is supposed to be a background and taxonomy.  Chapter two
provides us with a definition.  Nazario has obviously taken the
Cohenesque definition of viruses (as attaching to files) and then
assumed that a worm is any self-replicating program that does *not* so
bind.  The definition therefore appears to include almost all current
viruses, and yet the author also attempts to ascribe certain
characteristics to worms, such as control and construction of a
network, and communication with other worm nodes.  His later examples
of worms, however, include a number that do not contain any of these
aspects.  He lists a number of components of worms, and yet the
communications, command, and intelligence elements are not inherently
part of much of modern malware, usually existing simply as specialized
payloads.  A simplistic growth pattern (and the fact that worms can
generate network traffic) is presented in chapter three, but the
actual traffic patterns examined do not fully correspond to the
projected graph.  The history and taxonomy given in chapter four has
numerous errors: even the fictional representative, the tapeworm from
Brunner's "The Shockwave Rider," is introduced erroneously, since it
didn't shut down the network in the book, but rather opened it.
Workstations affected by the infamous Xerox PARC worm could be
restarted, and a vaccine was not needed or produced.  The Morris Worm
was an enormous nuisance, but it hardly "crashed the Internet."  (And
Loveletter did the rounds in 2000, not 2001.)  There is a quick precis
of a number of lesser known worms, and this may be helpful as a
reference, but the analysis is very limited.  The construction of a
worm is described in chapter five, but the outline is often at odds
with that given in chapter two.

Part two reviews worm trends.  Chapter six reworks some of the
material from five in a facile listing of infection patterns (and
presents an artificial "Shockwave Rider" pattern that does not seem to
have any correspondence to reality).  "Targets of attack," in chapter
seven, simply enumerates network connected devices.  Nazario does
attempt to bring in abstract concepts related to network topologies,
but these have little practical bearing on worms in reality.  The
possible futures for worms, as expressed in chapter eight, deals
mostly with existing and already used technologies.  There is some
effort made to model effects, but these are not fully analyzed.

Part three turns to detection.  Chapter nine looks at traffic
analysis, but only in terms of network based intrusion detection with
rudimentary appraisal.  Honeypots and "dark networks" (ranges of
unused IP addresses) are said to be ways to detect and trap worms, but
the explanation and dissection of the topic in chapter ten is very
narrow.  Signature based detection, in chapter eleven, revisits
network based intrusion detection, and adds a brief mention of file
scanning.

Part four looks at defences.  Chapter twelve's review of host based
defence deals primarily with system hardening, antivirus scanners, and
the concept of throttling.  Nazario seems very loath, in his
discussion of firewalls in chapter thirteen, to admit that this is
simply another type of signature.  The use of scanning within
application level proxies is examined in chapter fourteen, although
there seems to be some confusion with circuit level proxies at points.
Chapter fifteen, entitled "Attacking the Worm Network," outlines a
number of active measures: except for the idea of "sticky" tarpits
(after the LaBrea program model) all of them require extensive
specific knowledge of individual worms.  A concluding chapter is
provided in sixteen.

Nazario's work does address the often neglected topic of worms, and he
does break away from the mass of virus books that are locked into the
traditional "file and boot infectors" model.  His examples are drawn
from more recent events, and he does attempt to analyze network
effects and complications, rather than simply looking at systems in
isolation.  While he is to be commended for all this, his definition
is too broad to provide for serious new modelling of the problem, and
his analysis fails to provide a basis for future work.  Still, for
those who need a more complete picture of the malware threat, this
work should be considered.  It does provide new information, and does
attempt to address the difference between worms, viruses, and other
forms of malware.  In this regard, it is a significant improvement
over such lackluster spacefillers as Skoudis "Malware" (cf.
BKMLWFMC.RVW), the "E-mail Virus Protection Handbook" (cf.
BKEMLVRS.RVW), Dunham's "Bigelow's Virus Troubleshooting Pocket
Reference" (cf. BKBVRTPR.RVW), Schmauder's "Virus Proof" (cf.
BKVRSPRF.RVW), and even Grimes' somewhat better "Malicious Mobile
Code" (cf. BKMLMBCD.RVW).

copyright Robert M. Slade, 2003   BKDDSAIW.RVW   20031128
rslade@vcn.bc.ca      slade@victoria.tc.ca      rslade@sun.soci.niu.edu
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

Top