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 56

Tuesday 18 February 2003


Identity theft evidently based on spoofing AOL
Mike Hogsett
Credit-card hacking
David Wj Stringer-Calvert
11-year-old boy charged with felony for computer tampering
David R. Throop
eBay Sting
D. Joseph Creighton
Edsger Dijkstra quote on Computer Science
Stan Mazor
MacOS 10.2.4 update & httpd.conf replacement
Lawrence Brenninkmeyer
Risks of Doing Homework
Rebecca Mercuri
Re: Hospital claims 8,500 people expired
Fredric L. Rice
Re: Artery errors cost over $1 billion
Jamie McCarthy
Re: Password complexity
Nick Brown
Questions Frequently Asked About Rob Slade's Innumerable Book Reviews
Rob Slade
REVIEW: "Honeypots: Tracking Hackers", Lance Spitzner
Rob Slade
Info on RISKS (comp.risks)

Identity theft evidently based on spoofing AOL

<Mike Hogsett <>>
Tue, 18 Feb 2003 15:49:02 -0800

A Web site,, was recently brought to my
attention.  It has questionable content and most certainly a questionable
intent.  From my investigation, it appears that the intent is to purloin the
information necessary for identity theft from unsuspecting AOL subscribers.

In summary, the domain name serves a web page that uses
a frame set to obscure the source of the real contents.  The real contents
contain a very official looking form for "customers" to enter new billing
information for their AOL account.  In addition to a credit-card number this
form asks for social security number, mother's maiden name, and a second
credit-card number.

If some poor, unsuspecting person actually presses the submit button on this
page, the information is sent in the clear to a CGI program on yet another
web server which presumably sends this information via e-mail (also in the
clear) to a e-mail account.

I believe it is immediately evident that the intention is to steal the
information necessary to perform identity theft.

Why don't I believe that it is not an official AOL page?

  1)  Original frameset page not served via https
  2)  Obfuscation of true source of content
  3)  Content not served via https
  4)  Form contents not sent via https to form target
  5)  Form contents sent to form target on third web server in
      yet another domain
  6) address given as argument to form target
  7)  Real page server via a residential broadband address
  8)  Form asks for home address, date of birth, SSN, mother's maiden name,
      and a second credit-card number
  9)  Form asks for AOL password
 10)  Two of the relevant domains registered by individuals
 11)  Domain/host information spans the US (WA to CA to NJ to FL)
 12)  Form contents e-mail is sent via a completely insecure CGI program
      (anyone can send e-mail anywhere with this script).

[Update: The auto-responder rejected my report, for the
         following ERRONEOUS reason!  (My e-mail has numerous references to
         hotmail.)  Mike

  "Unfortunately, we cannot take action on the mail you sent us because it
  does not reference a Hotmail account. Please send us another message that
  contains the full Hotmail e-mail address and the full e-mail message to: "

    [If it this case is due to stupidity and ignorance rather than an
    outright scam, that would be even more startling -- although the
    opportunities for privacy violations would still be enormous.
    Furthermore, the recipient mailbox is reportedly saturated, which
    suggests perhaps that people are incredibly gullible and have already
    bitten for this scam!  Also commented on by Fred Gilham.  PGN]

Credit-card hacking

<"David Wj Stringer-Calvert" <>>
Tue, 18 Feb 2003 07:33:28 -0800

More than five million Visa and MasterCard accounts throughout the U.S.
were accessed after the computer system at an unidentified third-party
merchants' processor was hacked into.  It is currently believed that no
fraudulent misuse has occurred.  MasterCard began to notify its financial
members during the week of 3 Feb that more than 2 million MasterCard
accounts had been potentially compromised -- as did Visa for about 3.4
million of its accounts.  [Source: Reuters item, 18 Feb 2003; PGN-ed]

11-year-old boy charged with felony for computer tampering

< (David R. Throop)>
13 Feb 2003 23:01:58 -0600

A St. Lucie West Middle sixth-grader used the excuse of forgetting his lunch
to return to his reading classroom and sat down at his teacher's computer to
change five reading assignment grades, St. Lucie County sheriff's deputies
said Tuesday.  ... The 11-year-old student, who faces a 10-day suspension
and a principal's recommendation that he be expelled, was arrested Monday on
a felony charge of offense against intellectual property.  ... The student
was booked into the St. Lucie County jail, then released to his father.
Mancini said he could face several years in a juvenile detention facility,
if convicted.

  [With a little more imagination, he could have qualified for life
  imprisonment under the new anti-hacking law.  PGN]

eBay Sting

<"D. Joseph Creighton" <djc@cc.UManitoba.CA>>
Tue, 18 Feb 2003 14:54:19 -0600

A computer technician in Winnipeg, Canada, had his Fluke inline network
tester stolen (approx. value CDN$11,000) at the end of January.  Later,
he decided to check if the not-so-common device was being put up for sale
on eBay and found two: one in Indianapolis and the other in Winnipeg.
[First source: CBC Radio with an online article:

After expressing interest and through correspondence with the seller, a
serial number was obtained which confirmed that the network tester was the
technician's.  Police were contacted and a meeting was arranged at a local
coffee shop where the seller/suspect was arrested.  *The Winnipeg Free
Press* for 18 Feb 2003 later mentioned that the meeting between seller and
technician occurred with two plainclothes officers waiting at another table.

  [I presume the police were drinking Tester's Choice with their serial. PGN]

It appears the CBC may have gotten their tip from the morning paper -- I
don't get to my own copy until the end of the day -- and there's a bit of
a difference between the radio and newspaper versions.

Although the suspect may be innocent of the theft, the attempt to sell would
seem to constitute a crime.  The RISKS in not doing your on-line research
before doing your on-line auction is -- for the seller -- one that might be
costly and -- for the thief -- downright dumb.

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

Edsger Dijkstra quote on Computer Science

<Stan Mazor <>>
Mon, 10 Feb 2003 09:55:17 -0800

  [From asilomar-news, noted by Robert G. Kennedy III in Hackers newsgroup,
  sent to RISKS by Ken Knowlton.  PGN]

  Edsger W. Dijkstra, *Communications of the ACM*, Mar 2001, Vol. 44, No. 3

  In academia, in industry, and in the commercial world, there is a
  widespread belief that computing science as such has been all but
  completed and that, consequently, computing has matured from a theoretical
  topic for the scientists to a practical issue for the engineers, the
  managers, and the entrepreneurs.  [...]

  I would therefore like to posit that computing's central challenge, "How
  not to make a mess of it," has not been met. On the contrary, most of our
  systems are much more complicated than can be considered healthy, and are
  too messy and chaotic to be used in comfort and confidence. The average
  customer of the computing industry has been served so poorly that he
  expects his system to crash all the time, and we witness a massive
  worldwide distribution of bug-ridden software for which we should be
  deeply ashamed.

  For us scientists it is very tempting to blame the lack of education of
  the average engineer, the shortsightedness of the managers, and the malice
  of the entrepreneurs for this sorry state of affairs, but that won't
  do. You see, while we all know that unmastered complexity is at the root
  of the misery, we do not know what degree of simplicity can be obtained,
  nor to what extent the intrinsic complexity of the whole design has to
  show up in the interfaces.  We simply do not know yet the limits of
  disentanglement. We do not know yet whether intrinsic intricacy can be
  distinguished from accidental intricacy.

  To put it bluntly, we simply do not know yet what we should be talking
  about, ... The moral is that whether computing science is finished will
  primarily depend on our courage and our imagination.

[Stanley Mazor, Director Customer Services, Numerical Technologies Inc.
70 West Plumeria Drive, San Jose, CA 95134-2134 1-408-273-4485]

MacOS 10.2.4 update & httpd.conf replacement

<Lawrence Brenninkmeyer <>>
Fri, 14 Feb 2003 10:56:43 -0600

The Mac OS X operating system is a work in progress.  Users are treated to
small upgrades every one or two months that fix bugs, improve security, and
occasionally provide increased functionality.  Presumably in an effort to
add functionality to the built-in Apache server, the latest update installs
a brand new httpd.conf file.  This is file that tells the Apache server how
to configure itself (which modules to load, where the root directory is,
etc.)  The update kindly (and silently) saves the original httpd.conf as
httpd.conf.applesaved.  The risk is that replacing the original, not telling
anyone, and then leaving the server active on restart can lead to a breach
of security.  One of the things that you can use the httpd.conf file for is
to govern which directories are password protected and which are not [1].
This information is not retained in the new httpd.conf, so directories that
were password protected are opened to the world after the update has been

The risks are obvious, and so are the solutions.  At a minimum, they should
have disabled Apache on startup and presented the user with a dialog box
informing them of the change.

[1] Apache httpd documentation: Basic Security


Risks of Doing Homework

<"Rebecca Mercuri" <>>
Thu, 13 Feb 2003 05:46:37 -0500

At the faculty meeting at Bryn Mawr College on 12 Feb 2003, we were informed
that a student at Haverford (our affiliated College) was arrested over the
weekend when he was trying to do his homework assignment in Philadelphia.
As part of the Cities project, he was taking photographs of SEPTA (our
regional transit authority) facilities when he was arrested, detained for a
few hours, and eventually released.  Haverford administration is working to
try to ensure that this event not be a part of the student's permanent
police record.  Apparently taking photographs at transit facilities is cause
for arrest during "Code Orange" alert, the authorities explained.  Faculty
were advised to be careful about assigning "field trip" projects during such

Rebecca Mercuri, Bryn Mawr Computer Science

Re: Hospital claims 8,500 people expired

<"Fredric L. Rice" <Quack@SkepticTank.ORG>>
Thu, 13 Feb 2003 11:18:28 -0800

In RISKS-22.55, the coverage of the hospital in Grand Rapids, Michigan
didn't mention the possibility of *deliberate* abuse of the system where
simply changing a 01 into a 20 causes the system to inform insurance
carriers, the IRS, and presumably other agencies that one's dead.  Since a
hospital is a credible source for agencies, someone trying to vanish in
America to make another life for themselves -- either for honest reasons
else for criminal reasons -- could hack or bribe their way to access to the
system and, after going to St. Mary's Mercy for a broken finger, have the
hospital send credible notices of their own death.

Love it.

Death and taxes aren't quite so final in the Information Age.

Re: Artery errors cost over $1 billion (RISKS-22.55)

<Jamie McCarthy <>>
Thu, 13 Feb 2003 13:22:02 -0500

> Fleet Center arena ... was missing from the 1994 design drawings...
> ...which (according to the headline) cost over $1 billion

The RISK here is reading the headline instead of the article.  The arena
missing from the design drawings cost slightly under $1 million extra.  The
$1 billion figure is for all mistakes made by the Bechtel company resulting
in cost overruns over the past decade.

Re: Password complexity (Palme, RISKS-22.55)

<BROWN Nick <>>
Thu, 13 Feb 2003 18:28:09 +0100

I have absolutely no training in probability theory, but it seems to me
intuitive that adding a mechanism that effectively tells you if you're
already half-right, is going to reduce the security of any password.

Consider an eight-digit combination lock versus two four-digit locks, where
the first four-digit lock goes "click" before you open it and move on to the
next.  Clearly you only have to go round the 10000 combinations of the
second lock once, whereas in the 8-digit lock, you might have to do it 10000
times.  Or to make it even clearer, consider eight one-digit locks.

The calculation of the relative ease of cracking the combination only
becomes non-trivial when the number of bits in the separate locks sums to
more than the number of bits in the single lock.

However, as long as the main limiting factor in determining the minimum
length of a password for, say, an online banking system, is the marketing
department ("Oh, no, we mustn't frighten the customer with a
hard-to-remember code; let's use four digits like for the ATM card.  But
don't forget to insist on a 128-bit browser, because the user wants to feel
safe."), the debate will remain academic anyway.  :-(

  [Similar comments were received from Simon Waters and David Parnas.
  Of course, one of the CLASSIC password attacks was the old TENEX flaw in
  which passwords were checked one character at a time.  By aligning the
  password presented in a program so that the NEXT character lay across a
  page boundary, you could detect whether or not a page fault had occurred
  on the previous character, and thus iteratively reduce an exhaustive
  search to a linear search.  This was something like 30 years ago when
  it was realized that visibility of intermediate results is riskful, and
  that checking must be done in a single atomic transaction.  PGN]

Questions Frequently Asked About Rob Slade's Innumerable Book Reviews

<Rob Slade <>>
Thu, 13 Feb 2003 16:38:22 -0800

OK, since I am now getting not only questions about the reviews every day, but
multiple copies of the *same* questions, I suppose it is time for:

Questions Frequently Asked About Rob Slade's Innumerable Book Reviews --
Now With Answers!

Questions and answers

1) How do you find time to read all those books?

Darned if I know. I've always read a lot, and quickly. No, I don't do speed
reading: I find that I can't use those techniques. I read while waiting, I
read while traveling: sometimes I just read. I read and review as much as I
can spare time for. Those who have followed the series of reviews will
notice that sometimes I produce more than others: a lot depends on what else
I have to do at the time. Yes, I do read all of the books: every page
(although, I admit, sometimes not every word).

2) Do you have an archive of the reviews?

Yes, two, in fact. The "base" URLs are,
courtesy of the Victoria, BC, Canada TelecommunityNet (aka VTN), and, courtesy of Northern Illinois University
(former home of the Computer Underground Digest and aka NIU). All the
various pages and files are in those directories, so you can construct a
full URL by simply appending the filename. Also, all files are mirrored at
both sites. For example, a reference in one review, like "(cf.BKVR.RVW),"
would mean that the filename (converted to lower case) could be appended to
the base addresses, and you would find that both and point to actual reviews. (If you
use only the base URLs, you will find an index file that points you at some
of the major pages.)

For those looking for the reviews, probably the most useful addresses will
be or; the top level of the topical menus
of book reviews (security is not the only topic); and or; the main index to all
reviews. Due to increasing numbers of questions, I guess I will be
maintaining this FAQ at and

3) Where can I find the reviews?

All kinds of places, apparently. There are, of course, the archives above,
and the various topically related lists and groups to which I post
messages. Others archive various subsets of the reviews to different sites,
reprint the reviews in college or user group newsletters, and repost the
reviews to other mailing lists. If you want to get on a mailing list for all
the reviews, I have created a mailing list at Yahoo Groups. You can
subscribe by sending an email message to techbooks-, or visiting the Web site at, where you can also find an archive
of the more recent reviews.

4) Don't you like *any* books?

OK, I'm a cruel reviewer. But fair!

But, yes, I do like some. In the absence of a "Rob's Picks" page (which I
may get around to some time) the closest alternative is probably the page of
references by the CISSP domains, at or

5) Why don't you rate the books you review?

Generally, the people who ask this question want me to assign a single
numeric value, preferably on a scale of 1-5, to every book.

Books are a little bit more complex than that. They are good or bad for
different reasons for different groups. A book for a novice is useless to an
expert. A book for an expert is useless to a novice. So I try to state who I
would recommend the book to, and why. I think it's a bit more reasonable
than just giving each book a number.

If I'd wanted to do that, I could have skipped writing the reviews
entirely. It'd sure save time. (See question 1 :-)

However, a partial answer, for those who want a quick fix, is to look at the
main review index. (See question 2 :-) I try to give a summary of my
reaction to the book, in not more than one sentence.

6) Where can I find your reviews of all the CISSP guides?

See or

7) What's all that stuff at the beginning?

I was asked by the moderators of one newsgroup to use the standard UNIX
addlib format for publication information. It seemed to be a good set of
data, so I continued. The basic information is:

%A   Author's name (use a separate %A line for each)
%C   City (place of publication)
%D   Date of publication
%E   Editor (of book or series)
%G   Government order number (use this for ISBN)
%I   Issuer (publisher's name and imprint)
%O   Comments/etc. (use for format/price, ordering info)
     (also the links for purchase at online bookstores.  Yes, I do
     get a commission: see question 8.)
%P   Page number(s) (use for page count)
%T   Title of article or book

For more information, see the man page for the UNIX "refer" command.

8) How much money can you make reviewing books?

I find it quite bizarre that almost everyone seems to assume that a) I buy
all these books, or b) I get paid for doing these reviews. I get the books
free from publishers. (See question 9.) I don't get paid for doing the
reviews. Occasionally I use these reviews as the basis for review columns or
"best of" articles for magazines, and get a few bucks. If people
"click-through" the links on the reviews and buy books, I get a
commission. (Eventually my account may build up to enough money that they'll
actually send me a cheque.) I even get a bit of a tax break by getting a
"gift in kind" tax receipt when all these dead trees go to the library. But
this isn't exactly a business.

Of course, if any large corporation was interested in sponsoring the reviews
... :-)

9) How can I get started reviewing books?

In the immortal words of the advertising campaign, just do it. Grab some
books, and review them. Post the reviews. Once you have built a body of
work, you can start asking publishers for copies of books, especially if you
have proven you are serious by sending them copies of the drafts of your
reviews. (Before you post them on the net.)

You don't even have to buy a ton of books to get started. Review the ones
you've already got. If you use them, presumably you know why. If you want to
review new ones, try the library. (If you live in Vancouver, the Vancouver
Public Library has lots of recent technical books :-)

Of course, why would you want to? (See question 8.)

10) Where can I find books on (topic)?

Go to the main review index at or Use the search function on your
browser (Ctrl-F for most Windows stuff, "/" for Lynx, etc). Search for terms
you think would be in the title or the topic of the book. (For privacy you
might want to search on "privacy," "private," or "confidential.") When you
find a likely title, there will be a link to the review itself.

============= for back issues:
[Victoria Freenet] site
             an alternate site has been provided by CuD and NIU at:
CISSP refs:     [Victoria Freenet]mnbksccd.htm
PC Security:    [Victoria Freenet]mnvrrvsc.htm
Security Dict.: [Victoria Freenet]secgloss.htm
Security Educ.: [Victoria Freenet]comseced.htm
Book reviews:   [Victoria Freenet]mnbk.htm
                [Victoria Freenet]review.htm
Security Educ.:
Review mailing list: send mail to

REVIEW: "Honeypots: Tracking Hackers", Lance Spitzner

<Rob Slade <>>
Mon, 10 Feb 2003 08:04:30 -0800

BKHNYPOT.RVW   20030126

"Honeypots: Tracking Hackers", Lance Spitzner, 2003, 0-321-10895-7,
%A   Lance Spitzner
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2003
%G   0-321-10895-7
%I   Addison-Wesley Publishing Co.
%O   U$44.99/C$69.99 800-822-6339 fax 617-944-7273
%P   452 p. + CD-ROM
%T   "Honeypots: Tracking Hackers"

Chapter one is an introduction to the honeypot concepts, and the story of
Spitzner's first attempt to run one.  An overview of attackers and tools is
given in chapter two.  A history of honeypots is provided in chapter three,
and a list of basic types.  Chapter four looks at the benefits (and also the
problems) of these types of programs.  The types of honeypots are grouped
into high, medium, and low interactivity, in chapter five.  The explanations
given, in this first section, are good and simple.  Tables and figures
provided, however, often require interpretation.

Chapters six to eleven are reviews and descriptions of honeypots and related
programs.  There is a tutorial on the setup and use of Back Officer Friendly
in chapter six.  Specter, in chapter seven, gets a detailed review and a
discussion of the program's options.  Chapter eight discusses how honeyd
emulates a network.  Port monitoring, with netcat, and jails, using chroot,
are covered in chapter nine.  Mantrap cages are discussed in chapter ten.
Chapter eleven reviews two generations of honeynets, with lots of details.

Chapter twelve examines choosing and camouflaging honeypots.  Maintaining
and using a honeypot is in chapter thirteen.  Chapter fourteen presents a
couple of "case studies," integrating material from previous chapters.
There is a reasonable discussion of legal issues in chapter fifteen.  Future
directions for honeypots are examined in chapter sixteen.

"Know Your Enemy" (cf BKKNYREN.RVW) presented a fascinating glimpse into
both honeypots and the blackhat community, but only a glimpse.  This book
provides much more detail into the inner workings, setup, and technologies
involved in sensors for detecting and dissecting network intrusions.

copyright, Robert M. Slade, 2003   BKHNYPOT.RVW   20030126    or

Please report problems with the web pages to the maintainer