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 22 Issue 51

Sunday 26 January 2003


Keep it secret, stupid!
Matt Blaze
DoD offering admin privileges on .mil Web sites
Thomas C Greene via Fuzzy Gorilla
A. Guadamuz: Trouble with Prime Numbers: DeCSS, DVD, ...
Monty Solomon
Drunk driver hack
David Wj Stringer-Calvert
TurboTax 'activation' annoys users
Monty Solomon
Spam continues to increase
Monty Solomon
Canadian Centre for Identity Theft?
Richard Akerman
NASTAR web site provides personal skier information to anyone
Robert H'obbes' Zakon
Re: Hard-coded calendar dates
John Sullivan
REVIEW: "Internet Cryptography", Richard E. Smith
Rob Slade
REVIEW: "Cryptography Decrypted", H. X. Mel/Doris Baker
Rob Slade
Info on RISKS (comp.risks)

Keep it secret, stupid!

<Matt Blaze <>>
Sun, 26 Jan 2003 17:46:49 -0500

Last year, I started wondering whether cryptologic approaches might be
useful for the analysis of things that don't use computers.  Mechanical
locks seemed like a natural place to start, since they provided many of the
metaphors we used to think about computer security in the first place.

So I read everything I could get my hands on about locks, which included
most of the available open literature and at least some of the "closed"
literature of that field.  Once I understood the basics, I quickly
discovered, or more accurately re-discovered, a simple and practical rights
amplification (or privilege escalation) attack to which most master-keyed
locks are vulnerable.  The attack uses access to a single lock and key to
get the master key to the entire system, and is very easy to perform.  For
details, see

I wrote up the attack, in a paper aimed more at convincing computer
scientists that locks are worth our attention than anything else (I called
it "Rights amplification in master-keyed mechanical locks").  As I pointed
out in the paper, surely I could not have been the first to discover this --
locksmiths, criminals, and college students must have figured this out long
ago.  Indeed, several colleagues mentioned that my paper reminded them of
their college days.  There is considerable evidence that similar methods for
master key decoding have been discovered and rediscovered over the years,
used illicitly and passed along as folklore (several people have unearthed
Internet postings dating back as much as 15 years describing how to make
master keys).  Curious college students -- and professional burglars -- have
long been able to get their hands on master keys to the places that interest

But the method does not seem to appear in the literature of locks and
security, and certainly users of master keyed locks did not seem to know
about this risk.  I submitted the paper to a journal and circulated it to
colleagues in the security community.  Eventually, the paper reached the
attention of a reporter at the New York Times, who wrote it up in a story on
the front page of the business section last week.

The response surprised me.  For a few days, my e-mail inbox was full of
angry letters from locksmiths, the majority of which made both the point
that I'm a moron, because everyone knew about this already, as well as the
point that I'm irresponsible, because this method is much too dangerous to
publish.  A few managed to also work in a third point, which is that the
method couldn't possibly work because obviously I'm just some egghead who
doesn't know anything about locks.

Those letters, with their self-canceling inconsistency, are easy enough to
brush aside, but there seems to be a more serious problem here, one that has
led to a significant real-world vulnerability for lock users but that is
sadly all too familiar to contemporary observers of computer security.

The existence of this method, and the reaction of the locksmithing
profession to it, strikes me as a classic instance of the complete failure
of the "keep vulnerabilities secret" security model.  I'm told that the
industry has known about this vulnerability and chosen to do nothing -- not
even warn their customers -- for over a century.  Instead it was kept secret
and passed along as folklore, sometimes used as a shortcut for recovering
lost master keys for paying customers.  If at some point in the last hundred
years this method had been documented properly, surely the threat could have
been addressed and lock customers allowed to make informed decisions about
their own security.

The tragic part is that there are alternatives.  There are several lock
designs that turn out to resist this threat, including master rings and
bicentric locks.  While these designs aren't perfect, they resist completely
the adaptive oracle attack described in my paper.  It's a pity that stronger
alternative designs have been allowed to die a quiet death in the
marketplace while customers, ignorant of the risks, have spent over a
hundred years investing in inferior systems.

Although a few people have confused my reporting of the vulnerability with
causing the vulnerability itself, I can take comfort in a story that Richard
Feynman famously told about his days on the Manhattan project.  Some simple
vulnerabilities (and user interface problems) made it easy to open most of
the safes in use at Los Alamos.  He eventually demonstrated the problem to
the Army officials in charge.  Horrified, they promised to do something
about it.  The response?  A memo ordering the staff to keep Feynman away
from their safes.

DoD offering admin privileges on .mil Web sites

<"Fuzzy Gorilla" <>>
Sun, 26 Jan 2003 14:29:34 -0500

DoD offering admin privileges on .mil Web sites
*The Register*, Thomas C Greene, 24 Jan 2003

Care to register a .mil Web site of your own for free? The DoD has gone out
of its way to make it a snap. An unbelievably badly-protected admin
interface welcomes you to register whatever domain you please
( anyone?), or edit anything they've already got. The
interface is so ludicrously unprotected that it's been cached by Google and
fails to mention that you must be authorized to muck about with it.
Incredibly, default passwords are cheerfully provided on the page.

Following an anonymous tip from an observant Reg reader, we've encountered
the page in question in the Google cache, and after a bit of our own poking
about have also discovered an equally unprotected (and Google-cached) admin
interface encouraging us to add a new user, like ourselves, say, which
requires no authentication.

All you have to do is find that page and you can set yourself up with a user
account, manage your new .mil Web site, fiddle about with other people's
.mil Web sites, and generally make an incredible nuisance of yourself. We
are, of course, straining against every natural, journalistic impulse in our
beings by neglecting to mention any useful search strings with which to find

Another unprotected and cached page, this one discovered by our tipster,
lists traffic to a major DoD Web site by URL/IP address. This worries us
because it may list .mil sites and networked DoD machines that are not
public, not hotlinked anywhere, and which might contain (or be networked
with other machines that contain) sensitive data. Merely knowing that all
those URLs and IP addys are valid and owned by DoD would give a significant
advantage to attackers by narrowing their target area dramatically.

We have e-mailed the person who manages these sites - twice in fact - but so
far have not been graced with a reply. We were hoping that they might be
inclined to fix this mess quickly so that we could safely include the
details in our report. Unfortunately we have to withhold them until we're
confident that these security snafus are under control.

Ironically, US Defense Secretary Donald Rumsfeld recently ordered DoD to
purge military Web sites of information that might benefit evildoers. That's
all well and good, but it might behoove the DoD to stop offering them admin
privileges first.

A. Guadamuz: Trouble with Prime Numbers: DeCSS, DVD, ...

<Monty Solomon <>>
Fri, 24 Jan 2003 13:39:23 -0500

A. Guadamuz
Trouble with Prime Numbers: DeCSS, DVD and the Protection of
  Proprietary Encryption Tools
*The Journal of Information, Law and Technology* (JILT), 2002 (3)

Andrés Guadamuz González
Law Lecturer
University of Edinburgh


The DVD video format has become one of the most important developments in
the home entertainment market since the popularisation of the magnetic video
recording. The film industry delivered this format with a built in security
system which was supposed to avoid illegal copying of the discs, much as
what is taking place with the music CD and the almost indiscriminate copying
of music into MP3 format over the Internet. This was achieved by means of
encryption technology.

This essay deals with the cracking of DVD encryption and its further
diffusion as a computer programme named DeCSS, which has been made available
over the Internet in various formats, including t-shirts and a numerical
representation of the code. There are three court cases based on the online
posting of this programme, two in the United States and one in Norway. The
article starts by describing the technology involved, as it is felt by the
author that some of these technical issues are of importance to the legal
implications of the case and should be understood properly. The article then
deals with the developments in all of the three cases up to this date. The
essay then finishes with a look at the legal issues involved, including
hyper-linking, trade secrets, freedom of speech and the translation of DeCSS
into numerical format.

This is a Refereed article published on 6 December 2002.

Drunk driver hack

<"David Wj Stringer-Calvert" <>>
Wed, 22 Jan 2003 22:22:35 -0800

A 19-year-old in Besancon, France, was arrested for drunk driving.  Arriving
for his court hearing, he discovered an unattended computer, and proceeded
to erase his record -- replacing it with a winking smiley face.  The judge
was not amused, and gave him a three-month suspended prison sentence, a $425
fine, and a three-month suspension of his driving license.  [Source: Reuters
item, From, 21 Jan 2003; PGN-ed]

TurboTax 'activation' annoys users

<Monty Solomon <>>
Sun, 26 Jan 2003 00:25:26 -0500

A new "product activation" system in many 2003 editions of Intuit Inc.'s
TurboTax software prevents people from letting anyone else use the CD-ROM
on another computer in anything other than trial mode.
[Source: Mike Musgrove, *The Washington Post*, 26 Jan 2003]

Spam continues to increase

<Monty Solomon <>>
Thu, 16 Jan 2003 22:38:57 -0500

The number of spam messages sent increased nearly 300 percent from 2001 to
2002 -- from 14,078,511 to 55,683,103, according to e-mail filtering company
Brightmail.  If you think you're getting more spam than ever, you're
right. Spam has dramatically increased in the past year.  And next year will
be even worse.  One new report says that by July, the volume of spam sent to
business e-mail addresses will exceed the amount of regular e-mail.
[Source: **, Janet Kornblum, 13 Jan 2003; PGN-ed]

Canadian Centre for Identity Theft?

<Richard Akerman <>>
Wed, 15 Jan 2003 06:50:45 -0500

The National Archives of Canada already provide some Genealogy Research
links and services

They are polling, as part of the Canadian Genealogy Centre initiative

Earlier poll results have been released

"Exactly half of those surveyed said they were either very interested (21
per cent) or somewhat interested (29 per cent) in being able to search for
all Canadian genealogical information on a single Internet site."

Considering that most online and telephone credit card security consists of
"shared secrets" such as: your name, address, phone number plus date of
birth and mother's maiden name, this new Centre would seem to be an identity
thief's paradise.

Just to make things even easier, the current Archives Genealogy FAQ points
people at telephone directories, which can fill in the name-phone-address

I don't see that any consideration of this risk has been taken into account.

NASTAR web site provides personal skier information to anyone

<"Robert H'obbes' Zakon" <>>
Thu, 16 Jan 2003 13:56:44 -0500

NASTAR, the largest organization tracking amateur and professional ski races,
is kind enough to post race results on its web site.  You can even search for a
ski racer by name.

By clicking on the ski racer's name, you get a page stating "I am <ski racer
name> and I would like to login! [Click Here]".  If the skier has not done so
before (and most probably don't even know about it), you are prompted to
*create* a password, and can then access a page containing the racer's full
home address and birth date!

Seeing as NASTAR tracks not only professional racers, but amateur and community
racers as well, they have quite an extensive database of individuals.

After noticing the above behavior during last year's ski season, I e-mailed
NASTAR and notified the local ski resort I race at.  Of course I never heard
back from NASTAR, and could only hope their system would have been fixed for

And I thought I just had to look out for trees...  No such luck though.

Re: Hard-coded calendar dates

<John Sullivan <>>
Mon, 6 Jan 2003 14:46:45 +0000

It's OK now though - they've fixed the JavaScript to read:

    document.write(dayNames[day] + ", " + monthNames[month] + " " + date + ", 2003");

I'm stunned. There are just so many things wrong with this. First of all I
can't see any benefit to using a client generated date string anyway - why
not just get the server to fill it in - one assumes amongst other things
the server's clock is going to be more reliable than any random client's,
plus I think it really should be tied to the time of the last update
rather than whatever time it happens to be read at.

Second, the code immediately preceding initialises a variable called year
- why, if they're just going to hard code the year as a string anyway? I
suspect they had trouble deciding whether to add 1900 to the number
returned from getYear or not. JS treatment of this varies between browser
versions, and support for the improved getFullYear method may be patchy,
but again a server filled date would solve this. (Actually, getFullYear is
now sufficiently old for cross-browser support to be probably good enough.)

Thirdly, if you're doing it on the client, why not just use the Date
object's own string formatting capability? The paper is English language
only and none of the rest of the site is going to respond to the client's
locale settings so I can see a stylistic point to fixing the date to the
paper's own preferred format, but at least the Date object would get the
year right without additional hackery.

REVIEW: "Internet Cryptography", Richard E. Smith

<Rob Slade <>>
Tue, 21 Jan 2003 08:14:34 -0800

BKINTCRP.RVW   20021215

"Internet Cryptography", Richard E. Smith, 1997, 0-201-92480-3,
%A   Richard E. Smith
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   1997
%G   0-201-92480-3
%I   Addison-Wesley Publishing Co.
%O   U$29.95/C$44.95 416-447-5101 fax: 416-443-0948
%P   356 p.
%T   "Internet Cryptography"

According to the preface, this book is aimed at non-specialists who
need to know just enough about cryptography to make informed technical
decisions.  As an example, Smith suggests systems administrators and
managers who, while not formally charged with security, still have to
use cryptographic techniques to secure their networks or

Chapter one is an introduction, contrasting what we want; secure
communications; with the environment we have to work in; a wide open
Internet.  The text also looks at the balance that must be maintained
between convenience and requirements.  Encryption basics, in chapter
two, presents the concepts of symmetric cryptography, use, and choice.
There is a clear explanation of the ideas without overwhelming
technical details.  (It is interesting to note how quickly the
cryptographic technology changes: SKIPJACK and ITAR were still
important when the book was written, and are now basically
irrelevant.)  Some random thoughts on network implementation of
encryption are given in chapter three.  Managing secret keys, in
chapter four, provides good conceptual coverage of generation and
management, although the discussion of the problems of key escrow is
weak.  Because of the requirements for technical details when
discussing protocols, chapter five, on IPSec, is different from other
material in the book.  It also includes a brief mention of other
protocols.  Chapter six discusses the use of IPSec in virtual private
networks, while seven examines IPSec in terms of remote access.
Chapter eight looks at IPSec in relation to firewalls, but it is
difficult to see how this would be used in an actual application.

Chapter nine reviews public key encryption and SSL (Secure Sockets
Layer).  The basic concepts of asymmetric cryptography are presented
well, but may be unconvincing due to the lack of mathematical support
and details.  While there is an introduction to the related idea of
digital signatures, SSL is really only barely mentioned.  World Wide
Web transaction security, in chapter ten, provides practical examples
of the technologies discussed.  The same is true of email, in chapter
eleven, but digital signatures get a bit more explanation.  Chapter
twelve builds on the signature concept to introduce PKI (Public Key
Infrastructure) notions.

The fundamentals are written clearly and well, and are quite suitable
for managers and users.  Despite the lack of detail, the text may even
be suitable for some security professionals who need a rough
background without needing to work with the technology itself.  The
work is easy to read, although the idiosyncratic structure may be
confusing, and the value of some chapters questionable.

copyright Robert M. Slade, 2002   BKINTCRP.RVW   20021215

======================  (quote inserted randomly by Pegasus Mailer)
A fanatic is one who can't change his mind and won't change the
subject.                                         - Winston Churchill    or

REVIEW: "Cryptography Decrypted", H. X. Mel/Doris Baker

<Rob Slade <>>
Wed, 22 Jan 2003 08:24:16 -0800

BKCRPDEC.RVW   20021215

"Cryptography Decrypted", H. X. Mel/Doris Baker, 2001, 0-201-61647-5,
%A   H. X. Mel
%A   Doris Baker
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2001
%G   0-201-61647-5
%I   Addison-Wesley Publishing Co.
%O   U$29.95/C$44.95 800-822-6339 fax 617-944-7273
%P   352 p.
%T   "Cryptography Decrypted"

The book seems to be rather ambitious, since the preface says that it
is addressed to any (and therefore all) audience(s), without any
limitation on the stated purpose.  In general, it is an attempt to
portray the basic concepts of cryptography, without getting too far
into technical details.  Many other books have tried to do the same
thing, and signally failed.  Mel and Baker by and large succeed.

Part one addressed secret key (symmetric) cryptography.  Chapter one
tries to draw an analogy between locks and encryption, although the
relation is strained at best.  Substitution, frequency analysis, and
polyalphabetic ciphers are covered in chapter two.  Chapter three
introduces transposition.  The Polybius square is used, in chapter
four, as an example of the combination of substitution and
transposition.  For those in the know, this leads nicely into the
discussion of DES (Data Encryption Standard), in chapter five,
although the neat segue would be lost on most readers, since the
details of DES are not given.  The history of cryptography appears
rather abruptly in chapter six.  Chapter seven covers the attempts to
use cryptographic methods for confidentiality, integrity,
authentication, and non-repudiation, and shows that the last point is
not possible with purely symmetric cryptography.  A simplistic
examination of key exchange is given in chapter eight.

Part two deals with public key (asymmetric) encryption.  Chapter nine
is a confusing introduction using the Merkle puzzle space (with some
mention of Diffie-Hellman) as the example.  A simplistic review of
public key encryption is in chapter ten.  Math tricks, in chapter
eleven, seems pointless as it begins, but the development to the
examples of modular inverses do provide both a basic form of
asymmetric cryptography, and a demonstration of the mathematical
concepts underlying more advanced cryptographic algorithms.  Chapter
twelve introduces authentication and digital signatures, with hashes
and message digests in chapter thirteen, and a discussion of digest
assurances (reviewing collisions and encrypted message authentication
codes) in fourteen.  A comparison of cryptographic strength and speed
(between symmetric and asymmetric systems) is in chapter fifteen.

Part three covers the distribution of public keys, and introduces some
of the concepts of PKI (Public Key Infrastructure).  Chapter sixteen
deals with certificates.  The title of chapter seventeen relates to
the X.509 certificate structure, but the topics covered mostly concern
hierarchical certificate authorities.  PGP (Pretty Good Privacy) and
the "Web of Trust" model are explained in chapter eighteen.

Part four looks at real world systems and actual applications.
Chapter nineteen explains email security, but in a generic fashion.
SSL (Secure Sockets Layer) is clearly described in chapter twenty,
but, given the lack of detail in the rest of the book, the technical
material is rather odd.  IPSec, in chapter twenty one, is presented in
a confused manner.  Various problems of, and attacks against,
cryptography are outlined in chapter twenty two.  The final chapter is
a simplistic review of the storage of cryptographic keys on smart

This book does present most of the core concepts in cryptography.  The
text is readable, and, within the limited scope of the material,
generally accurate.  For non-specialists, it is a reasonable
introduction to the topic.  This might even include security
professionals who are not directly involved with cryptographic
systems.  However, the lack of detail in the explanations of the
theory is a weakness, since the text would be more convincing with
more background.

copyright Robert M. Slade, 2002   BKCRPDEC.RVW   20021215    or

Please report problems with the web pages to the maintainer