The RISKS Digest
Volume 23 Issue 17

Tuesday, 3rd February 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…


How to Hack an Election
UK: Vital e-crime evidence often destroyed
Iain Thomson via Keith A Rhodes
Security Holes at DMVs Nationwide Lead to ID Theft and Safety Concerns
Monty Solomon
Porn viewers work for hackers
Robin Burke
January clearance sale
Scott Nicol
Re: Spirit Rover humbled
Jim Griffith
A scary thing
Erann Gat
Phishing and a new IE security patch
Sidney Markowitz
MyDoom and SCO
Steve Wildstrom
RISKS actually gets *relatively little* MyDoom Traffic
Chris Smith
Re: Risks of virus scanners
Paul Tomblin
Alan J Rosenthal
Re: The risks of naming
Robert de Bath
Re: Drunk unlocks police car with own key
D. Joseph Creighton
David Hollman
"Loss of Identity" theft
Terry A. Ward
REVIEW: "Kerberos: The Definitive Guide", Jason Garman
Rob Slade
Info on RISKS (comp.risks)

How to Hack an Election (*NYT* editorial)

<Hendrik <>>
Sun, 1 Feb 2004 11:57:48 +0900

*The New York Times* had the following editorial on line on 31 Jan 2004, at - they conclude with
the remark "Given the growing body of evidence, it is clear that electronic
voting machines cannot be trusted until more safeguards are in place." I
wonder what safeguards they envision that would allow us to trust electronic

  How to Hack an Election

  Concerned citizens have been warning that new electronic voting technology
  being rolled out nationwide can be used to steal elections. Now there is
  proof. When the State of Maryland hired a computer security firm to test
  its new machines, these paid hackers had little trouble casting multiple
  votes and taking over the machines' vote-recording mechanisms. The
  Maryland study shows convincingly that more security is needed for
  electronic voting, starting with voter-verified paper trails.  [...]

  They were disturbingly successful. It was an "easy matter," they reported,
  to reprogram the access cards used by voters and vote multiple times. They
  were able to attach a keyboard to a voting terminal and change its vote
  count. And by exploiting a software flaw and using a modem, they were able
  to change votes from a remote location.  [...]

UK: Vital e-crime evidence often destroyed

<"Keith A Rhodes" <RhodesK@GAO.GOV>>
Fri, 30 Jan 2004 11:41:24 -0500

[I wonder if these are the same forensic experts who couldn't figure out how
the Bank of England scam software worked?]

Vital e-crime evidence often destroyed; National High Tech Crime Unit warns
firms to leave computer forensics to the experts
By Iain Thomson, vnunet, 29 Jan 2004,

Companies that fall victim to computer crime may be inadvertently destroying
evidence in their efforts to find the perpetrators. Detective Chief
Superintendent Len Hynds, of the National High Tech Crime Unit (NHTCU), said
that its Confidentiality Charter, launched in December 2002, was encouraging
more businesses than ever to report computer crime.  But there are sometimes
problems with gathering evidence if preliminary investigations have been
carried out before the police are called in.

Speaking at the Homeland and Corporate Security Summit in London DCS Hynds
said: "There are examples of companies which wrestle with problems for
months without calling us and that can lead to problems in the evidential
trail. The private sector is going to be key to being even more effective in
solving crimes. However, we need to develop common standards in terms of
dealing with high-tech crime between the private and public sectors."

Cyber-criminals are becoming ever more sophisticated in their
activities. Tactics include hiding files that are disguised as bad sectors
on a hard drive, and using other PCs as mail servers to shield illegal

Michael Colao, senior consultant at Dresdner Kleinwort Wassertein, said:
"What we see is well-meaning IT professionals going in and doing what you
see on every bad crime film: they muddy the waters. You only have one
opportunity to collect the evidence you need to prove your case. Human
resources send in well-meaning IT help desk staff who don't know what they
are doing and ruin the evidence. You need a professional computer forensic
team in there as soon as possible."

Security Holes at DMVs Nationwide Lead to ID Theft and Safety Concerns

<Monty Solomon <>>
Mon, 2 Feb 2004 09:50:52 -0500

CDT ( has issued a report entitled "Unlicensed Fraud"
( documenting rampant internal
fraud and lax security at state motor vehicle administration offices across
the country placing the reliability of all driver's license at risk. While
heavy public attention has been placed on new national standards and new
technologies for driver's licenses, studying local news reports from
throughout 2003 CDT finds that basic management processes to stop bribery
and theft are lacking. In the report, CDT offers policy recommendations to
address this dire issue. February 2, 2004

Porn viewers work for hackers

<"Robin Burke" <>>
Wed, 28 Jan 2004 13:48:42 -0600

The following article describes an attack against the web images (so-called
"CAPTCHAS") that are used to prevent robots from using certain web
applications such as the creation of free e-mail accounts.  The images are a
form of "Turing Test", easy for a human user of normal ability to process,
but difficult for a piece of software. The attack involves routing the
CAPTCHA image to a page that advertises free porn.  Users have to decode the
CAPTCHA to get the advertised images and in doing so, unwitting assist
spammers in creating bogus e-mail addresses.

"But at least one potential spammer managed to crack the CAPTCHA test.
Someone designed a software robot that would fill out a registration form
and, when confronted with a CAPTCHA test, would post it on a free porn
site. Visitors to the porn site would be asked to complete the test before
they could view more pornography, and the software robot would use their
answer to complete the e-mail registration." (Relevant section is
near the end)

One poster to a related thread in Slashdot
( reported that his
site shut down its (CAPTCHA-protected) free e-mail service recently due
to a sharp increase in spammer-generated accounts.

Robin Burke, Associate Professor, School of Computer Science,
Telecommunications, and Information Systems, DePaul University

January clearance sale

<Scott Nicol <>>
Sat, 31 Jan 2004 11:42:04 -0500

Buy something, get whatever you can stuff into your parka free!

That's right, go into a <name of big home-improvement store deleted to
protect the guilty> when the outside temperature is a little cold (say, 10
degrees F).  Pick up a $2 screwdriver and a $100 multimeter.  Pay for the $2
screwdriver, but stuff the $100 multimeter in your jacket.  When the fancy
schmancy EAS (Electronic Article Surveillance) system goes off as you are
walking out the door, don't worry, the clerks will ignore it and yell to you
"you're fine - that thing always goes off when its cold".

I saw this happen about a dozen times while waiting in line at <big home
improvement store>.  I have no idea if the customer had a $100 multimeter in
their jacket, but then again, neither did the employees of the store!

I couldn't find technical details on Checkpoint EAS systems
<>, but Sensormatic
<> provided details such as
< Pro-Max
DS NUS.pdf>, which states "Ambient Temperature: 0 C to 50 C (32 F to 122 F)"

This particular problem would likely only affect stores with sensors near
very large outside doors, such as home improvement and warehouse stores.

Re: Spirit Rover humbled (RISKS-23.15)

< (Jim Griffith)>
Tue, 03 Feb 2004 17:56:25 -0500

I'm so disappointed that PGN didn't go with the obvious pun --
  that Spirit was willing, but its flash was weak...

  [Thanks, but I didn't think Rover's park was worse than its plight.  PGN]

A scary thing

<Erann Gat <>>
Wed, 28 Jan 2004 17:44:28 -0800

I just had a scary thing happen to me.  I got the following e-mail:

  Return-path: <>
  Date: Wed, 28 Jan 2004 20:12:08 -0500 (EST)
  From: Netscape Registration <>
  Subject: Information you requested
  Original-recipient: rfc822;

  Dear User,

  The information that you requested from Netscape is below:


  Thank you,

  Netscape Registration

except that where the ******* is there was a password that I often use for
low security applications.

Trick is, I have never to my recollection signed up with Netscape.  To say
nothing of the fact that the e-mail didn't come from Netscape (none of the
received headers were from netscape).

Phishing and a new IE security patch

<Sidney Markowitz <>>
Wed, 04 Feb 2004 10:16:16 +1300

RISKS 23.16 mentioned phishing with URLs of the form which use
the username:password@hostname format of URL for social engineering.

Microsoft has just released a security update for Internet Explorer which
deals with vulnerabilities caused by some special characters preventing the
entire URL from being displayed in the browser's address bar and status
line. That vulnerability has been used with phishing URLs like the above to
suppress display the portion of the URL starting from the '@'.

They went one step further, however, and eliminated all support for the
username:password@hostname syntax in http URLs in the Internet Explorer
browser, with optional registry entries to allow or remove the support from
programs that embed IE as an object.

The Microsoft Knowledge Base article about the security update is at

It refers to information about the URL syntax at
"INFO: URL Syntax for Authentication Without Dialog Prompt"

I have seen some objections to Microsoft unilaterally dropping support for a
URI syntax allowed in RFC 2396, thereby breaking websites that use this form
of URL for user logins. I think in this case Microsoft did the Right Thing
for security. RFC 2396 applies to the generalized URI, which includes, for
example http:// and 
2616, etc.) do not use that syntax, while ftp: does. Username password
syntax in an http URL was always a nonstandard extension that introduced
various security vulnerabilities.

MyDoom and SCO

<"Steve Wildstrom" <>>
Mon, 2 Feb 2004 16:34:32 -0500

Writing on Feb. 2, it's very hard to assess what the real impact of the
MyDoom-generate denial of service was on SCO. We do know that,
notwithstanding the hype and heavy breathing from anti-virus companies, that
it had little or no impact on the performance of the Internet as a whole.

It's very hard to assess what is going on at SCO, because
<>  was mostly inaccessible from Wednesday, Jan. 28
on (I'm indebted to Netcraft <>  for their
site-performance reporting.). Darting on Wednesday, my efforts to reach
the SCO site variously generated forbidden access (403) errors, time
outs, or sporadic availability.  At some point on Sunday, DNS entries
for were removed; later traffic to the site was directed to a
Google search page. On Monday, SCO transferred the site to <> . According to
Netcraft, that server lies within the same IP address space as <> , so it would appear that whatever is
happening to the server, SCO's network is holding up fine.

Netcraft also reported on the afternoon of Feb. 2 that in anticipation
of the MyDoom.B phase of the attack, Microsoft has shortened the TTL for <>  to 60. MyDoom.B appears
to have gotten significantly less distribution than the A variant.

I think the real untold story of MyDoom is that network administrators,
especially at the big ISPs, have gotten much better at containing the
damage from these attacks. MyDoom may have been the fastest spreading
virus ever, but it seemed much less disruptive than SoBig.F last summer.
After the first few hours, the main virus-related traffic I saw was the
continuing stream of spurious bounce messages and the phony "you have
sent a virus" alerts. It wouldn't be hard to eliminate those messages
completely-turn off the virus alert feature, which has been rendered
worthless by return address spoofing, and don't sent bounce messages in
reply to messages bearing known signatures, like the MyDoom generated

Steve Wildstrom, BusinessWeek Technology & You columnist
1200 G St NW Suite 1100, Washington, DC 20005

RISKS actually gets *relatively little* MyDoom Traffic

<Chris Smith <>>
Tue, 3 Feb 2004 02:12:49 -0500 (Eastern Standard Time)

I note that you had 2528 new e-mails between Jan 27 and Feb 2, under a week.

Over the week beginning 26 Jan at 3PM, I *personally* received over 30,000
e-mails involving MyDoom.  That's just me — I'm not an ISP or anything.  I
haven't kept really close tabs, but I estimate this is between 700 and 1000

There are two reasons for this.  The first is subtle. As finally detailed at
the bottom of Symantec's info page on MyDoom at
one of the lesser known behaviours of MyDoom is the key. After finding an
e-mail address by searching locally on the infected machine, MyDoom then
also uses a combination of the domain and a list of common usernames. Almost
all of the names are common given names - except mine: smith

I maintain an address at a popular freemail/webmail site, using this
username. Thus whenever an instance of MyDoom finds any e-mail from this
site, there is a chance it has found me as well.  This isn't even one of the
REALLY BIG webmail sites. Although I've got lots, I expect anyone at hotmail
or aol with a name on the MyDoom list has even more.

The second reason everyone knows - bounces back to spoofed From:
addresses. I estimate that between 1/3 and 1/2 of my e-mails are of this

The volume of bounces and directs together makes clear that
MyDoom uses these made-up addresses both for From: and To: addresses.

It is worth noting that the vast majority of MyDoom traffic contains spoofed
From: and From_ (sender) information.  Implementation of something like
Sender Permitted From (SPF) could have stopped most of these in their
tracks. MyDoom has effectively converted me into an SPF evangelist - because
if the history of worms has shown us anything, it's that once a technique is
shown to be useful to worms, it isn't RISK that it will show up again - it
is pretty much certain.

Anyone who argues that there are too many RISKs with something like SPF will
have to provide me with a good alternative.

Even after all this, I refuse to accept that my name is a RISK.

Re: Risks of virus scanners (Bellovin, RISKS-23.14)

< (Paul Tomblin)>
Mon, 2 Feb 2004 21:29:16 +0000 (UTC)

> Why are the good guys trying to teach people to click on attachments?

I would think antivirus software companies would seem to have a very large
incentive to keep users doing the stupid things that get them infected.  If
people stopped clicking on attachments, the AV companies would be out of
business overnight.

Paul Tomblin <>

Re: Risks of virus scanners (Bellovin, RISKS-23.15)

< (Alan J Rosenthal)>
Tue, 3 Feb 2004 11:25:52 -0500 (EST)

> Why are the good guys trying to teach people to click on attachments?

But opening "attachments" is a fact of ms-win life.  The commonest text-like
file format is the Microsoft Word (.doc) format.  When people turn ms-word
files into e-mail messages, they generally do so by "attaching" them.  So
ms-win users are used to opening attachments, routinely.

I don't think it's useful to tell people not to open attachments, because
this is simply infeasible.  They _are_ going to open attachments.  In fact,
the message to all telling them not to open attachments is likely to be a
.doc file attachment (unless it's powerpoint, or a flash animation).

I think that what ms-win needs is a clearer separation between data and
program.  There need to be file formats which are not programmable, which
can be viewed safely.  Assuming that plain text is (for no real reason) not
an option, Microsoft could lead the way by releasing a version of its office
suite which does not implement "macros".  Very few users will miss them, and
everyone else will be impressed by Microsoft's technical mastery in
producing word processors which are incapable of transmitting viruses.

Re: The risks of naming (Anderson, RISKS-23.14)

<Robert de Bath <robert$>>
Wed, 28 Jan 2004 07:48:21 +0000 (GMT)

  R. de Bath
  R. Debath
  R. Bath
  R. De'ath

And thats in ONE language!  (The 'proper' surname is "de Bath")

Rob (Robert de Bath <robert$ @>) <>

  [In addition, Arabic names seem to have many variants.  PGN]

Re: Drunk unlocks police car with own key (RISKS-23.16)

<"D. Joseph Creighton" <djc@cc.UManitoba.CA>>
Tue, 3 Feb 2004 14:39:51 -0600 (CST)

I own a 1999 Sonoma and a 2000 Chevy Venture, both built by General Motors.

The combination ignition/pass key is interchangeable to open either vehicle's
door but will not start the other vehicle, presumably due to the chipped key
required by the newer model (the Sonoma does not have it).  One hopes that,
even though the mechanical door locks are being shared, the chips would have
a 1:1 mapping of keys to ignitions.

Incidentally, my dealer didn't think of it as a RISK when I first brought
it to their attention.  They felt I should consider it a feature since so
many others pay to have this done.

D. Joseph Creighton [ESTP] | Systems Analyst, Database Technologies, IST
Joe_Creighton@UManitoba.CA | University of Manitoba  Winnipeg, MB, Canada, eh?

Re: Drunk unlocks police car with own key

<"Dave Brunberg" <>>
Tue, 3 Feb 2004 15:39:28 -0500

Forget keys, one time I was on a business trip to St. John's, Newfoundland.
I rented a maroon Oldsmobile Alero from the National Car Rental at the
airport.  The car was equipped with a keyless entry system on the key-ring.
I rent so many cars that most of the time I forget what kind of car I'm
driving on any given trip.  One day, I went into a local supermarket,
leaving my rental parked in a spot near the entrance after locking it
remotely.  Upon exiting the store, I walked over to my Alero, pressed the
unlock button on the keychain, and hopped in.  I inserted the key and
started the engine.  At this point I noticed that my briefcase was not on
the passenger seat where I had left it.  After a moment of panic, it took
about three seconds to realize that I was in somebody else's car.  I turned
it off, got out, and pressed the lock button on the remote.  The car locked
itself and I went looking for my rental, which was in a spot two rows over
behind a big pickup truck.

What are the odds of having not only a matching door/ignition key, but also the keyless entry remote?

David W. Brunberg

Re: Drunk unlocks police car with own key (RISKS-23.16)

<David Hollman <>>
Tue, 3 Feb 2004 14:14:23 -0800 (PST)

This story SOUNDS quite apocryphal [, like urban legends noted in]  In fact, things might be much
worse than this story indicates, and I have a personal example to

Last year I took a train out to my parent's from the city; in the parking
lot they left me a car complete with a magnetic hide-a-key box for the car
key which I did not have. Upon opening the box, I found there was a house
key instead!

After fruitlessly searching for another key I decided to try the house key
on a lark, and to my great surprise it actually OPENED the driver's-side
door of the car (which was a 1991 Jeep Cherokee).

Sadly for me this key did not actually start the car. However, since I was
in an extremely out-of-the-box frame of mind, I jammed a paperclip in the
ignition, heard the distinctive buzzing, turned the "key" and STARTED THE

(See photo -

The blade on a friend's pocketknife later accomplished the same trick.

NB0: This was actually my dad's system of security through obscurity. Since
putting the car key in a hide-a-key box is very insecure he would leave a
house key which he knew would open the door, and then would hide the
ignition key inside the car. The flaw? Not telling me this in advance!

NB1: Getting into the car was never the primary concern anyway, since on a
Cherokee you can grip the rubber of the rear window and easily pull the
window out of the door, then climb into the trunk. Useful if you lock your
keys in.

NB2: On a Grand Cherokee (at least models from the late 90s) you can
*always* open the rear window using the button on the door. This will set
off the alarm if locked, but it opens regardless!

"Loss of Identity" theft

<"Terry A. Ward" <>>
Mon, 26 Jan 2004 21:55:32 -0700

I was recently the executor of a relative's estate and was shocked to
discover that I was able to cancel his private health insurance, his
veteran's health benefits, one dozen credit cards, and all of his retirement
direct deposit payments with simple phone calls. At no time did anyone ask
me to prove that I was who I said I was or whether I had executor power over
his estate. I simply presented a plausible sounding story, knew his social
security number and his account numbers and was able to close his accounts
over the phone. To make it even more interesting our last names are not even
the same!

The possibility for mischief should be obvious with such an insecure system.
Not exactly computer-related but very scary indeed.

REVIEW: "Kerberos: The Definitive Guide", Jason Garman

<Rob Slade <>>
Wed, 28 Jan 2004 08:33:21 -0800

BKKRBSDG.RVW   20031018

"Kerberos: The Definitive Guide", Jason Garman, 2003, 0-596-00403-6,
%A   Jason Garman
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2003
%G   0-596-00403-6
%I   O'Reilly & Associates, Inc.
%O   U$34.95/C$54.95 800-998-9938 fax: 707-829-0104
%P   253 p.
%T   "Kerberos: The Definitive Guide"

Kerberos is not flashy, but it is a venerable and mature technology.  Yes,
it has limited scalability, but most of the "successful" PKI (Public Key
Infrastructure) projects are small enough that they could easily have been
accomplished with Kerberos technology: an eminently elegant solution to the
problem of communicating and authenticating over any channel that is, or
must be, assumed to be insecure.

Chapter one provides a history, base concepts, and variants of Kerberos.
Terms and components are given in chapter two.  The Needham-Schroeder work,
and the idea of ticket-granting, is in chapter three.  Implementation, in
chapter four, reviews design, UNIX and Windows servers, and special
considerations for a mixed environment.  The troubleshooting chapter, five,
for once comes early enough in a book to be of use.  Security aspects
external to Kerberos, and specific settings for different implementations,
are covered in chapter six.  Chapter seven looks at some generic support for
applications, as well as some specific programs that already have Kerberos
support built in.  Cross realm trust is one of the advanced topics, but most
of chapter eight concentrates on special requirements for Windows.  Chapter
nine is a kind of review of the book, involving the various topics that have
been discussed in a sample Kerberos installation.  Chapter ten looks at the
future of Kerberos, with possible public key additions, Web applications,
and smartcards.  An appendix contains an administrative command list.

While Kerberos may not be as highly regarded as the more mathematically
complex asymmetric cryptographic systems, it still have many uses, and this
book provides the outline, background, and details to help you take full
advantage of them.

copyright Robert M. Slade, 2003   BKKRBSDG.RVW   20031018    or

Please report problems with the web pages to the maintainer