The RISKS Digest
Volume 23 Issue 43

Monday, 28th June 2004

Forum on Risks to the Public in Computers and Related Systems

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

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…

Contents

AOL worker sold customer list for spam, US charges
via Monty Solomon
Swedish social insurance computers disabled by virus
Peter Håkanson
Terror over Internet Protocol?
NewsScan
Canada's largest bank has "processing disruption"
Yves Bellefeuille
PFIR "Preventing the Internet Meltdown" Conference Info Online
Lauren Weinstein
Attacking the attackers: maybe not a good idea
NewsScan
Shocking laptop horror stories
Aahz
Hacker hits South Korean defense
NewsScan
/Not/ keeping security information up to date
TFB
Wyoming woman arrested on false federal charges
Dirk the Daring
Exploding vending machine emits phosgene gas
Cheryl Hoefelmeyer
Irresponsible traffic announcement
Steve Friedman
Who am I?
Erann Gat
Re: Autorun evil?
Thomas Wicklund
Risks of testing
Thomas Wicklund
Re: Whom do I tell?
Chris Brand
REVIEW: "Security Warrior", Cyrus Peikari/Anton Chuvakin
Rob Slade
Info on RISKS (comp.risks)

AOL worker sold customer list for spam, US charges

<Monty Solomon <monty@roscom.com>>
Fri, 25 Jun 2004 13:37:21 -0400

An America Online employee, Jason Smathers, has been charged with
stealing AOL's list of 92-million customers and selling it it to an
Internet spammer/marketer/online-gambling purveyor Sean Dunaway (who
then resold it for $52,000 a pop).  Dunaway was also charged.
Smathers has been fired.
  [Sources: Monty provided several items, which were PGN-ed.]
  Reuters, 23 Jun 2004
  - http://finance.lycos.com/home/news/story.asp?story=42133939
  Andrew Orlowski, 24 June 2004, UNITED STATES v. JASON SMATHERS, SEAN DUNAWAY
    http://news.findlaw.com/hdocs/docs/cyberlaw/ussmthrs604acmp.pdf
    http://www.theregister.com/2004/06/24/aol_spam_insider/
  ]


Swedish social insurance computers disabled by virus

<Peter Håkanson <peter@hk.ipsec.se>>
Wed, 23 Jun 2004 18:38:32 +0200

Today Riksförsäkringsverket (the central authority that pays all
social benefits and illness-related salary-supplements) was disabled
by virus attacks.

This concerns all of Sweden's population of 9M persons.  Not all of us
rely on this money, but every Swede who happens to be eligible for any
payments is.

A lot of errors seem to contribute. One of the larger is basing a
national insurance system on computers that are defenseless against
any external threat, another that those "toy-computers" are exposed to
external threats.

Maybe the golf-tours made the difference during the purchasing procedures??

  There's never money to do it right, but always money to do it
  again ... and again ... and again ... and again.
  ( Det är billigare att göra rätt. Det är dyrt att laga fel. )


Terror over Internet Protocol?

<"NewsScan" <newsscan@newsscan.com>>
Thu, 17 Jun 2004 08:45:44 -0700

A senior Justice Department official has told a Senate committee that
law enforcement faces new threats from Internet-based telephone
services, and warned that legislative efforts to deregulate VoIP
(Voice over Internet Protocol) services could undermine the ability of
law enforcement officials to investigate criminal or terrorist
activity. The Justice Department has asked the FCC to require Internet
phone companies to design electronic conduits in their networks that
would make it easier to tap conversations.  James X. Dempsey of the
Center for Democracy and Technology says that a better approach would
be for investigators to work cooperatively with Internet phone
providers. (*The Washington Post*, 16 Jun 2004; NewsScan Daily, 17 Jun
2004]
  http://www.washingtonpost.com/wp-dyn/articles/A47882-2004Jun16.html


Canada's largest bank has "processing disruption"

<Yves Bellefeuille <yan@storm.ca>>
Sun, 20 Jun 2004 22:46:47 -0400

[Written on 4 June, but only sent now because of a problem with my
Usenet server. :-(]

Canada's largest bank, the Royal Bank of Canada, has been unable to
process deposits or report balances for the last five days. The bank is
blaming "a processing disruption during a routine programming update to
one of our computer systems".

Direct deposit to a bank account is a common way to pay salaries here,
especially for large employers, and among those affected are employees
of the Government of Ontario, Canada's largest province, which
apparently uses the Royal Bank for its payroll.

The Royal Bank has 10 million customers, about a third of Canada's
population. It says that it "processes tens of millions of transactions
each day". The bank confirms that "the processing disruption was
national in scope so we expect a significant number of clients have been
affected".

The bank promises that: "We will fully refund any service fees or
overdraft interest charged to RBC clients' accounts due to this
processing delay. Any other reasonable costs incurred as a result of
this delay will be handled on an individual basis". It also says that:
"All the other banks are aware of this situation and we have asked them
to be as accommodating as possible". (There are seven major banks in
Canada.)

More information at:
http://www.royalbank.ca/client_faq.html
http://www.globeandmail.ca/servlet/story/RTGAM.20040604.wrbc0604/BNStory/Business/


PFIR "Preventing the Internet Meltdown" Conference Info Online

<Lauren Weinstein <lauren@vortex.com>>
Sat, 26 Jun 2004 10:01:44 -0700

Peter,

I'm pleased to announce the availability of detailed registration,
schedule, program, hotel, and other information relating to our People
For Internet Responsibility (PFIR) "Preventing the Internet Meltdown"
conference here in L.A. from July 26 through 28, 2004.  The
registration period for the conference commences immediately.

The conference information is all available from the Meltdown
official announcement document and related linked pages via:

   http://www.pfir.org/meltdown

In the time since you, Dave Farber, and I originally suggested this
conference, the situation with many issues related to the Internet
have become even more complex and controversial.  These range from
Internet governance and control to Homeland Security issues; from
VoIP, WHOIS, DNS, and privacy to spam, viruses, and other attacks on
the Internet infrastructure and its users; and much more.  The
Internet and the global populations who depend upon it are at real
risk.

We hope that this gathering will aid in mapping out some specific
courses of action that can help us all avoid the many negative impacts
that an Internet meltdown would impart.

We're looking forward to a most interesting and productive
event.  Thank you very much.  Be seeing you!

--Lauren--
Lauren Weinstein
lauren@pfir.org or lauren@vortex.com or lauren@privacyforum.org
Tel: +1 (818) 225-2800
http://www.pfir.org/lauren
Co-Founder, PFIR - People For Internet Responsibility - http://www.pfir.org
Co-Founder, Fact Squad - http://www.factsquad.org
Co-Founder, URIICA - Union for Representative International Internet
                     Cooperation and Analysis - http://www.uriica.org
Moderator, PRIVACY Forum - http://www.vortex.com
Member, ACM Committee on Computers and Public Policy


Attacking the attackers: maybe not a good idea

<"NewsScan" <newsscan@newsscan.com>>
Mon, 21 Jun 2004 09:00:56 -0700

A company called Symbiot Security has created "Intelligent Security
Infrastructure Management Systems" (iSIMS) that not only provide
traditional defensive measures against viruses, worms, and other kinds
of network vandalism — but also offer the victims of vandalism a
gradual escalation of retaliation measures. These include the ability
to flood the attacking computers with data. However, some experts say
that retaliatory actions could be a very bad idea. Adrian Vanzyl of
the security firm Seclarity comments: "So you are in effect breaking
into each of those systems as you follow this person back. Are you
legally liable for that? It's a very, very good question." And Dorothy
Denning, professor of defense analysis at the Naval Postgraduate
School, warns: "We've seen worms that have had major impact like
causing delays in airline schedules, shutting down ATM machines, 911
systems and so on. Putting any kind of worm out there would be
dangerous." (AP/*San Jose Mercury News*, 18 Jun 2004; NewsScan Daily,
21 Jun 2004]
  http://www.siliconvalley.com/mld/siliconvalley/8957335.htm


Shocking laptop horror stories

<Aahz <aahz@pythoncraft.com>>
Mon, 21 Jun 2004 23:07:05 -0400

Press release dated June 11 (plus other stories found through Google):
http://www.newsroom.ucla.edu/page.asp?RelNum=5275

The story says that a laptop was stolen from the University of
California, Los Angeles in 11/2003, containing a database of 145,000
blood donors that was password-protected but not encrypted.  The database
contained names, birthdates, and social security numbers.  The victims
were not notified until a week before the story was filed, roughly six
months after the theft.

The laptop was stolen from a locked van.  A second laptop was stolen in
late May from an office, putting another 62,000 people at risk — UCLA
will notify these people, "...in the next few weeks."

Nothing really new here.  Question is, when will these stories stop
getting resurrected from the grave?  Of even more interest to me is that
none of my usual sources have popped up with this story; I learned about
it during a trip to LA this past weekend, more than a week after it hit
the news.  Are we getting that blase about this?

Aahz (aahz@pythoncraft.com)  http://www.pythoncraft.com/


Hacker hits South Korean defense

<"NewsScan" <newsscan@newsscan.com>>
Tue, 22 Jun 2004 10:03:31 -0700

A network vandal has broken into computers at sensitive South Korean
research institutes and government agencies, infecting more than 60
PCs with a variation of the Peep Trojan program. The National Cyber
Security Center (NCSC) said the hacker had broken into computers at
the Agency for Defense Development, which develops weapons, the Korea
Atomic Energy Research Institute, the Korea Institute for Defense
Analysis and three other government agencies.  [*The Australian*, 21
Jun 2004; NewsScan Daily, 22 Jun 2004 ) Rec'd from John Lamp
  http://tinyurl.com/24wyw


/Not/ keeping security information up to date

<tfb@cley.com>
Mon, 28 Jun 2004 12:04:21 +0100

Some time ago, in 2003, CERT announced a WAP service, so you could
check current CERT alerts and so on from your phone, at
http://wap.cert.org/.  WAP hasn't been wildly successful, of course,
but all phoes have it, at least in the UK.  Since I'm away from home a
lot, and I'm responsible for the security of our machines (and
sometimes of clients' machines too), I thought it would be useful:
it's nice to be able to check that there is nothing to panic about
from a device I carry all the time anyway.  This is also potentially a
nearly-ideal use of a phone-type interface - the amount of information
needed is absolutely tiny (`sendmail issue, patch now!'), and
promptness is very important.  Push would be better than pull, but you
can't have everything.

Fortunately, although I put the URL in my bookmarks, I didn't use it
very often, because something completely toxic happened.  For whatever
reason, CERT obviously lost interest in the WAP interface, and *left a
static version of it in place*.  If you check that URL (from a phone)
now, you'll find some information from November 2003, and *no
indication at all* that all the information is hopelessly out of date.

This is the worst possible scenario for a system like this.  A system
which is meant to be providing alerts of some kind needs to either
work, or fail in such a way that its users know it's failed.  This is
the equivalent of the coolant level meter reading `full' while coolant
pours from some fractured pipe and the core melts.  If the coolant
meter is broken it's way better to have sparks and smoke pouring from
it than for it to quietly repeat the last reading...

I'd urge anyone who provides security information over the net to
arrange life so that when the system breaks or they lose interest, it
fails in a way that is extremely visible to its users.


Wyoming woman arrested on false federal charges

<Dirk the Daring <dirk@psicorps.org>>
Sat, 19 Jun 2004 18:01:27 -0400 (EDT)

http://www.billingsgazette.com/index.php?id=1&display=rednews/2004/06/19/build/wyoming/55-arrest.inc

Summary: A vacationing Wyoming teacher's aide was rousted from her
cruise ship bed, shackled and dragged into federal court based on
information in a federal warrant database that wrongly accused her of
failing to pay a fine after she was cited in a US national park last
year.

The RISKS: Federal agents apparently blindly relied on the database,
even though the court had a copy of the citation showing she had paid.
The US Attorney even continued to ask for the woman to have to appear in
court in Wyoming after being told that the citation showed she had paid,
and standard procedure for the park is that visitors must pay fines
before they can leave.

Clearly, federal law enforcement authorities continue to place too much
reliance in computer databases and not enough on the information in
front of them. Further, the fine was a matter of US$50 for failing to
properly store her hot chocolate and marshmallows, yet the federal
authorities saw fit to drag the woman out of bed, shackle her like a
mass-murderer, and haul her into court.


Exploding vending machine emits phosgene gas

<"Cheryl Hoefelmeyer" <hoefelmeyer@hotmail.com>>
Sat, 26 Jun 2004 01:14:51 +0000

A repairman working on a soft drink vending machine in Park Place
Medical Center in Port Arthur, Texas apparently triggered an explosion
which converted the freon in the machine to phosgene gas, a poisonous
gas that was used in WWI as a weapon.

Reference: (*Houston Chronicle*)
http://www.chron.com/cs/CDA/ssistory.mpl/metropolitan/2647290


Irresponsible traffic announcement

<Steve Friedman <steve@adsi-m4.com>>
Thu, 3 Jun 2004 13:51:03 -0400 (EDT)

On the way to work this morning, around 9:45 am I heard a surprising
traffic announcement on the radio (WAMU).  On this road, one is
legally allowed to drive on the right shoulder (aka breakdown) lane
until 10am.  To indicate when it is permissible, lights over the lane
either indicate a red X or a green arrow.

Apparently, today the lights were showing red (thus closing down one
lane).  The announcer indicated that, since it was still legal to
drive on the right shoulder until 10am, motorists should ignore the
computerized signs and drive on the right lane anyway.

It wasn't clear whether the insight into letting motorists decide to
ignore the signs was made by the announcer or Virginia state police;
however, it doesn't seem like a good idea to train motorists that the
only reason why the lane might be closed is because of computer
malfunction and thus ignore the signs when the motorist "knows" that
the lane should be open.


Who am I?

<Erann Gat <gat@flownet.com>>
Fri, 18 Jun 2004 11:35:41 -0700 (PDT)

I just completed the process of legally changing my name.  I am no longer
Erann Gat.  I am now Ron Garret.

The interesting thing (I have been reading RISKS far too long for this to
be shocking or even surprising) is that the only time during the entire
process that I was asked to produce any identification was when I tried to
pay the court fees with my credit card.  If I had paid in cash I could
have gone through the entire process without ever having to produce an ID.

And, of course, so could anybody else.

Ron Garret f.k.a. Erann Gat


Autorun evil? (Re: da Silva, RISKS-23.42)

<Thomas Wicklund <wicklund@eskimo.com>>
Mon, 21 Jun 2004 09:20:05 -0700 (PDT)

Peter da Silva questions who would think autorun a good idea.  The
answer should be obvious.  Most computer users aren't technically
sophisticated and want to have "plug and play" devices.  A few minutes
with market research or support personnel will show that a typical
consumer wants to plug a device into a computer and user it.  The
consumer doesn't want to have to perform a software installation step
using a CD which was probably lost months ago, nor answer a bunch of
"do you want to enable this device you just plugged in" questions.
Anybody with non-technically inclined relatives who's been asked to
help setup a system should also see the reasons for plug and play
features.

Obviously this opens up security concerns.  Autorun is subject to
abuse.  So is the lack of autorun (just create a CD with a virus named
"setup" and tell the user to install it).

There is a fundamental conflict between security and convenience.  Many
common system features are security holes such as programmable access
to network features, copy/paste clipboards, I/O redirection, and
allowing default "other read" file access.  Most features which allow
one to do useful work can also be abused.  Similarly, the feature of
the automobile which allows one to travel faster than a walk also
allows one to be more easily killed in a collision.

In the same Risks edition, Aahz objects to labeling Verity technology
as data mining software.  Yet in some sense, any search program is a
form of data mining.  And as with any search, it can be used (find the
best price for product X) and abused (find all information about John
Doe).


Risks of testing (Cohen, RISKS-23.42)

<Thomas Wicklund <wicklund@eskimo.com>>
Mon, 21 Jun 2004 09:25:08 -0700 (PDT)

Fred Cohen mentions wanting to be able to prove things like "the green
lights will not be on in non-parallel directions at traffic lights".
One thing software professionals must always remember, and may easily
forget, is that software is dependent on hardware.  No amount of
software will protect against a short in the hardware, and even with
fault tolerant techniques one must ultimately ensure that the hardware
is properly designed or provides the proper interlocks.

In the traffic light case, while software may be cheaper, hardware
interlocks may ultimately be the most reliable solution.


Re: Whom do I tell? (Jerry James)

<"Chris Brand" <Chris_Brand@spectrumsignal.com>>
Fri, 18 Jun 2004 10:21:11 -0700

> ... when I dial a number I know is good, I get the
  message that I am calling a disconnected number.

This sounds similar to a problem I have.  Here in BC, in November
2001, we switched to 10-digit dialing, where you always have to dial
the area code even if your area code is the same.  If you get it
wrong, you get a polite message telling you that you need to redial
with the "604".

The problem is that I occasionally get the same message when I have
dialed the 604. Just as Jerry described, I hang up, press "redial" and
the call goes through.

I haven't actually bothered trying to report it. In this age of
Windows, "try it again", "it worked that time", "well ok,
then. Goodbye" seems to have become the norm.


REVIEW: "Security Warrior", Cyrus Peikari/Anton Chuvakin

<Rob Slade <rslade@sprint.ca>>
Thu, 24 Jun 2004 12:48:24 -0800

BKSECWRR.RVW   20040509

"Security Warrior", Cyrus Peikari/Anton Chuvakin, 2004, 0-596-00545-8,
U$44.95/C$65.95
%A   Cyrus Peikari
%A   Anton Chuvakin
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2004
%G   0-596-00545-8
%I   O'Reilly & Associates, Inc.
%O   U$44.95/C$65.95 800-998-9938 fax: 707-829-0104 nuts@ora.com
%O  http://www.amazon.com/exec/obidos/ASIN/0596005458/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0596005458/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0596005458/robsladesin03-20
%P   531 p.
%T   "Security Warrior"

The preface isn't a really clear piece of writing, but does,
eventually, get around to stating that the book focuses on security
from an attack, rather than defence, perspective.  I have, in numerous
other reviews, pointed out the errors and limitations in this
position.

Part one deals with cracking software, primarily involved with
breaking copy protection.  Chapter one explains a few concepts about
assembly language quite well, and then ends abruptly.  Some Windows
tools for reverse engineering are listed in chapter two, plus a couple
of poorly explained examples.  The material on reverse engineering in
Linux is longer and more detailed, but still has very limited tutorial
value, and is padded with extensive code listings of dubious worth.
Chapter four is supposed to deal with reverse engineering for
Windows CE, but contains an odd mix of CE operating system
architecture, a partial list of ARM CPU opcodes, and a description of
how to crack the registration code check in a program written solely
to allow you to crack the registration code check embedded within it.
Overflow attacks, in chapter five, explains buffer and other overflow
conditions, and gives an example of a buffer overflow as a crack in
another fake program.

Part two presents information about networks.  Chapter six is a rather
unstructured overview of TCP/IP and a listing of some sniffing tools.
(TCP is explained before IP itself, and the relationship of the
various protocols in the suite is not discussed.  A section on "covert
channels" emphasizes a strange misuse of header fields, and then
drifts into something like session hijacking.)  Social engineering can
be used in a variety of ways, so it is strange that chapter seven
should be here rather than in the "Advanced Defence" of part four.
The random content provided has little organization and a fair number
of errors: the authors insist that social engineering attacks can be
divided into active and passive types, but, by its nature, social
engineering is almost entirely active.  (The book does seem to tacitly
admit this: there is a list of example "active" attacks, but no
corresponding "passive" list.)  Chapter eight mentions a few methods
of reconnaissance with differing levels of detail.  Some more advanced
techniques for identifying the operating systems in chapter nine, but
the particulars are similarly inconsistent.

Part three lists attacks against specific platforms.  The authors
betray their lack of study once again in chapter eleven: UNIX is *not*
"reborn from" MULTICS (although it was heavily influenced), and TCSEC
(the Trusted Computer System Evaluation Criteria) is definitely *not*
the Common Criteria.  The various security related aspects, tools, and
hardening of UNIX are not bad, but lack definition.  The UNIX attacks
listed in chapter twelve are good: ironically, because of the generic
nature of the descriptions the examples are probably useful as a guide
to defensive measures, rather than being outdated tricks.  The Windows
client attacks listed in chapter thirteen, because they are specific,
have limited the material both in scope and utility.  Chapter
fourteen, listing Windows server attacks, notes some interesting
security bugs in Server 2003 and other programs (and one bit on
smartcards.)  "SOAP XML Web Services Security," in chapter fifteen, is
a long title for a short piece on XML digital signatures.  "SQL
Injection," in chapter sixteen, has some examples of malformed data
attacks, and also points out the dangers of adding programming
functionality to applications.  As with social engineering, the tie to
networks is thin, seemingly limited to the PHPNuke program.  Some
aspects of wireless antennae, sniffing, and a brief review of the
weaknesses in WEP (Wired Equivalent Privacy) are in chapter seventeen.

Part four looks at more advanced defence.  Miscellaneous thoughts on
logging are in chapter eighteen.  Chapter nineteen has a confused
explanation of intrusion detection systems (IDS).  There is no mention
of rule (or activity monitoring) based engines, signature based
engines are said to be restricted to net-based IDS, different terms
are used for anomaly detection engines on hosts versus networks, and
there is a muddled attempt to tie Bayesian analysis to odd
mathematical ratios of false positive (false rejection) and false
negative (false acceptance) errors.  The installation of a simple
honeypot is described in chapter twenty (which probably *should* be in
part two).  There is a good initial outline of incident response in
chapter twenty one, but it breaks down when getting into specifics.
Forensics and antiforensics, in chapter twenty two, gives some
background and tools for data recovery and obfuscation.

It is ironic that the book starts out with a quotation from "The Code
of the Samurai," stating that "[a]ll samurai ought certainly to apply
themselves to the study of military science.  But a bad use can be
made of this study to puff oneself up and disparage one's colleagues
by a lot of high-flown but incorrect arguments that only mislead the
young ..."  This assessment fits Peikari and Chuvakin's work almost
perfectly.  There is a lot of interesting information in this volume:
if you have limited technical background in the fields examined, you
will find that a quick perusal will provide you with some superficial
familiarity with the topics.  However, the uneven coverage ensures
that the information is spectacular, rather than tutorial.  The
disjointed jumps from one subject to the next prove the technical
erudition of the authors, but do not help the reader very much.

copyright Robert M. Slade, 2004   BKSECWRR.RVW   20040509
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

x
Top