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 16 Issue 77

Monday 30 January 1995

Contents

o UK Cabinet Secret on National ID Card Found in Surplus Store
Li Gong
o Perils of Call Forwarding
Stephen Thomas
Quentin Fennessy
o Deutsche Telekom offices searched
Mich Kabay
o My life as "uucp@aol.com"
Uucp@aol.com
o Risks of reusing accounts
Charlie Shub
o >From the cat file
Andrew Koenig
o Another stamp machine story
John Kriens
o The risks of Risks
Fritz Knabe
Haritini Kanthou
o ACSAC '95 Call for Papers and Participation
Marshall D Abrams
o Info on RISKS (comp.risks)

UK Cabinet Secret on National ID Card Found in Surplus Store

Li Gong <gong@csl.sri.com>
Wed, 25 Jan 95 10:02:56 -0800
The Manchester Guardian Weekly (week ending 21 Jan 1995) reported that plans
for the UK national ID card system was found in a government surplus store.
The second-hand file cabinet was sold for about 35 pounds.  It contained
memos on investigation into the feasibility of smart-card technology, a
detailed card design, as well as cabinet level letters exchanged on this
topic.  Whitehall has confirmed that the files are authentic.

Li GONG     Email: gong@csl.sri.com   Tel: 415-859-3232  Fax: 415-859-2844
SRI International, Computer Science Lab, Menlo Park, California 94025, USA


Perils of Call Forwarding [Plumbing the Depths]

Stephen Thomas <stephen.thomas@tridom.com>
Mon, 30 Jan 1995 09:41:22 -0500
I'm sure many eagle-eyed risks readers spotted this one, but just in case,
here's an item from an AP story in Sunday's Atlanta Constitution.
Stephen A. Thomas, AT&T Tridom, email: stephen.thomas@tridom.com

>From The Atlanta Constitution, Sunday, January 29, 1995, page D7

Did he steal jobs, thanks to call forwarding?
Police say plumber grabbed rivals' calls   [Abstracted starkly by PGN]

Michael Lasch, a plumber in Levittown, NY, is accused of calling Bell
Atlantic to order Ultra Call-Forwarding for at least five of his company's
competitors, which enabled him remotely to redirect their calls to his
phone.  He was charged with theft by deception, criminal attempt, unlawful
use of a computer, criminal trespass and impersonating an employee.  The
scam was detected when a customer complimented another firm on work
performed over Christmas weekend -- when in fact no one had been working!
[The WRENCH that stole Christmas?]

   [Also noted by "Whittle, Jerome SMSgt" <JWhittle@amclg.safb.af.mil> and
   Quentin Fennessy <Quentin.Fennessy@sematech.org>, from whom I include
   the following excerpt.  PGN]


Phone number hijacking with Bell Atlantic ultra-forwarding

Quentin Fennessy <Quentin.Fennessy@sematech.org>
Sun, 29 Jan 1995 12:30:47 -0600
  [...]  There is nothing new about this crime - except the use of a new
medium to hijack a channel of communications.  The risks are obvious - as
more such services are available without verification the more this crime
can occur.  I suppose that if Lasch were more sophisticated he could have
kept up his scheme for much longer.  For example, if the ultra-forwarding
were flexible enough he could enable it for the coldest days, in order to
fill up his queue with work orders for frozen pipes, and then disabling the
forwarding while he completed the jobs.

Quentin Fennessy


Deutsche Telekom offices searched

"Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
27 Jan 95 10:50:59 EST
>From the Reuters newswire (95.01.25 @ 11:36 EST) via CompuServe's Executive
News Service:

    Deutsche Telekom Offices Searched in Fraud Probe, by William Boston

    BONN, Jan 25 (Reuter) - Police searched offices of Deutsche
    Telekom AG on Tuesday to determine whether staff at the
    German state telephone monopoly had withheld proof of
    computer hackers tapping into private phone lines to call
    foreign sex hotlines.

    Juergen Froehlich, chief prosecutor in Cologne, said in a
    statement that police went through Telekom offices in Bonn,
    Cologne and Duesseldorf as part of an investigation into a
    gang of hackers.

The author continues with the following key points:

* Legal authorities are investigating the possibility that D.T. employees
concealed data on stolen phone services.

* Over 2M D.T. clients have complained about fraudulent phone calls charged
  to their accounts over the last 30 months.

* D.T. officials deny that its customers paid for any fraudulent calls,
  explaining that the criminals placed their calls from accounts obtained
  using false names.

M.E.Kabay,Ph.D., Director of Education, NCSA (Carlisle, PA)
Mgmt Consultant, LGS Group Inc. (Montreal, QC)


My life as "uucp@aol.com"

<Uucp@aol.com>
Sat, 28 Jan 1995 18:45:29 -0500
America Online allows its user accounts to specify up to five "screen
names", which uniquely identify the user.  AOL screen names consist of a
capital letter followed by two to nine alphanumerics or spaces.  The screen
name is not case-sensitive, so "MR SMITH" and "Mr Smith" refer to the same
account, and the AOL software forces uniqueness on new names by appending
digits to the end of the name.

AOL accounts can also send and receive Internet e-mail.  AOL converts its
screen names to Internet-style addresses by dropping all spaces and
appending "@aol.com", so our "Mr Smith" becomes "mrsmith@aol.com" to the
outside world.

Which is where I come in.  I was trying to come up with a unique screen name
that did not end in randomly assigned digits -- AOL's membership stands at
1.5 million users, each of whom can reserve up to five names, so most common
English words and names are already taken.

Idly searching for a name, I requested "root".  (I always put this down as
my first choice when requesting a new account.  It never hurts to ask.)

The AOL software politely informed me that this name was taken, and said the
same when I requested "postmaster", "webmaster", etc.  In some cases it
suggested an alternative like "webmast236", and in others it simply said
"That name is taken."

Then I requested "uucp".

And the software asked me to enter my new password.

    *

Since then I've been getting a lot of strange e-mail, to put it mildly.
Much of it is private correspondence from external addresses to accounts
on AOL, or vice versa, that has been Cc:'d to uucp.  (I don't know why.
Is this happening due to user ignorance or carelessness, or is it the
behavior of the mail software?)  In no case so far has the sender
suspected that "uucp@aol.com" is a live human being.

The RISK here is the assumption that "uucp" (or, for that matter, "root")
is a trusted e-mail address on the remote machine.  The only required
e-mail address in RFC 822 is "postmaster" -- there is no requirement that
the remote machine use the UUCP transport mechanism, the UNIX operating
system, or that any e-mail address other than "postmaster" route e-mail
to the system administrator.  ("Postmaster@aol.com" does route e-mail to
a person responsible for AOL's mail system, in compliance with RFC 822.)

AOL reserves certain screen names to prevent this kind of confusion, but
"uucp" was not one of the reserved names.  (Neither was "nuucp", if you
were curious -- I've reserved that one too.  I think I can retire both
addresses permanently by deleting the screen names from my account, but
I plan to make certain before doing so.)  "Root@aol.com" and "webmaster"
are already in use, but I can't say *who* is using them.

Of course these RISKs apply to any site, not just to AOL -- any site
could have a user account named "uucp" and still be RFC 822 compliant.
But as the net grows, and incorporates more and more diverse machines,
the RISK becomes more dangerous.  Don't assume that mail addressed to
"uucp" or "root" on a remote machine is going to a trusted recipient,
because for at least one large site this assumption isn't true.

Scott Forbes    MSForbes@aol.com


risks of reusing accounts

Charlie Shub <cdash@ludell.uccs.edu>
Wed, 25 Jan 1995 23:47:46 +0700
Two years ago, i was on sabbatical at a large university, and picked
up some support by teaching a course.  Their division of computing
services managed many computing accounts, and had a pretty reasonable
scheme for class accounts.  They used a 3 letter followed by 3 digit
account names.  The first two letters denoted the department, and the
third letter was a for the first course, b for the second course, etc.
000 was always the instructor's account and 001 was student 1, 002
student 2, etc.  A reasonably sane idea.  I would guess that at the
end of each semester they cleaned student accounts by deleting all
files and reinserting initialization files.  They would then generate
new passwords for all accounts each semester.  What is the risk?
accounts may have state data that does not appear in the account or
that is not normally cleansed.

The course i was teaching was on a machine i did not use for my
personal work, so i had set up automatic mail forwarding to my machine
here that I normally read mail on (by telnet from there when i was
there).  The between semester cleansing algorithm did not reset that
forwarding address.  Finally, the 5th course in the department again
used that same machine, so account cse000 became the instructor's
account.  That instructor has apparently given the students a "use
e-mail" assignment, and did not test the system with a self mailing.

Since the forwarding is still in effect, I have been receiving
electronic mail intended for this instructor for the past few days.
I thought of sending him/her email to let him/her know about this,
but realized that such mail would immediately be forwarded to me.
I thought of replying to the students, but if they are just learning
about computers, that would also be fruitless.  I thought of logging
into the account to unset the forward, but the new instructor has
obviously changed the password.  I suppose I could have chosen to just
wait until some interested party finds this in risks, or watch from
the sideline until confusion reigns.  I believe I have identified the
instructor, and have sent her email.  A blind copy of this note to
risks is being sent to a friend at that institution who will, no
doubt, follow up with the instructor and keep me (and perhaps risks
readers) posted on how this shakes out.

charlie shub  cdash@cs.colorado.edu  -or-  cdash@colospgs (BITNET)
(719) 593 3492               (fax) 593-3369


From the cat file

<ark@research.att.com>
Thu, 26 Jan 95 16:56:42 EST
This morning I was sitting at my home terminal, reading mail.  I got up for
a few minutes.  When I returned to the terminal, the screen showed a partial
reply to the last message I had been reading.  It looked something like
this:
    From: ark@research.att.com
    To: sender@machine.com
    Subject:  <whatever>

    edbone
    2222222222222222222222222222222222222222222222222222222222222222222222

It didn't take me long to figure out what had happened.  This particular
terminal has function keys that can be set to store strings.  Once upon a
time I often used a machine named `redbone,' the name of which was therefore
stored in that function key.  Sitting on the table, next to the keyboard,
was one of my two big, fluffy cats.  She had evidently pressed that function
key and the mailer interpreted the `r' of `redbone' as a request to reply to
the message.  After that, she must have spent some time sitting on the `2'
key.

Oh well, at least she didn't try to eat the mouse.

--Andrew Koenig  ark@research.att.com


Another stamp machine story

kriens,john <jkriens@cc.bellcore.com>
30 Jan 1995 18:00:26 -0500
My stamp machine story is similar to that of Jonathan Kamens in RISKS-16.76
in that the machine was programmed to keep the person using the machine from
losing money.  It is different in that it let me get into a situation where
I could neither buy the stamps I wanted, nor could it give me my money back.

There is a stamp machine in the basement of one of the buildings in our
corporate campus, we also have a U.S. Post Office in our backyard, but if
you're lazy or in a hurry, it's simpler to use the machine.

Anyway, I wanted to buy a book of stamps (back when they were still a bargain
at $5.80 for the book of 20).  I decided to go to the stamp machine.  Now, I
had $6.00 with me--a five and a one.  There was a sign on the machine saying
that the machine would give back no more than $.50 in change.  I took this
sign to mean that I could put in more money if I wanted, but the most change
I could get for overpayment would be $.50.

Anyway, for some reason, I decided that I wanted to get a quarter back, rather
than two dimes.  I would put in $6.05, get $5.80 worth of stamps, and get a
quarter back.  Most candy vending machines will let you do this, but you have
to put your change in first, before the bills--otherwise they know that you're
overpaying and won't let you put the coins in.  I started off with a nickel.
I then put the $1 bill in.  So far, so good.  I then attempted to put the five
in.  The machine just wouldn't accept it.  I can't remember what message the
machine gave me, but it was not enlightening.  After trying 5-10 times to get
it to take the bill, I reached the conclusion that it just wasn't taking five
dollar bills today (since my bill was in pristine condition).  It also wouldn't
let me get back the money I'd already put into the machine.  Since I was stuck
with either losing my money or getting change and hoping I would finally get
my stamps, I left the machine and dashed upstairs to our credit union to get
change for the five.

Luckily, there was no line, so I got my five $1 bills and ran back downstairs.
The money was still registered in the machine, so I proceeded to feed my $1
bills in.  Everything went fine until I got to the fifth bill--which the machine
refused to take.  Once again, the bill was in perfect shape.  After trying a
bunch more times, I realized that I would need exact change, so I walked down
to the change machine in one of the break rooms to get the bill broken into
coins..

Unfortunately, it took too long to get the coins and I arrived back at the
machine just in time to see it finish telling me I had taken too long and reset
itself, removing all traces of my money from the display.

As you have probably deduced by now, the machine had been programmed to not
allow a person to put more than the next highest dollar amount into the machine
from the purchase price of the stamps.  Since all of the denominations of
stamps were between $(X).50 and $(X+1).00 [books of $.29 stamps were $2.90 and
$5.80 and post card stamps were $1.90 or $3.80], the machine assumed that anyone
putting in more than the next dollar would risk losing money--something they
*clearly* would not want to do, since they would lose money.  (Never mind that
they would also lose the money they'd put in up to this point since once the
bills go into the machine they don't come back out.)  The sign about getting a
maximum of $.50 back was misleading since the machine gave no opportunity to
lose that much.

Luckily the Post Office refunded my money without any hassle, but I still wish
whoever programmed the machine hadn't thought they were being so damn clever.

-John Kriens  jkriens@cc.bellcore.com


The risks of Risks

Fritz Knabe <Fritz.Knabe@ecrc.de>
Mon, 23 Jan 95 17:13:13 +0100
As a frequent reader of the RISKS forum, I was very interested when
"Computer-Related Risks" (our esteemed moderator's new book) was reviewed
here. Using the information from the review, I faxed an order to ACM.

Two months later, with no book, I discovered that ACM had debited my credit
card for $34.50, rather than the $22.25 + shipping that I was expecting. It
seemed that not only did I not have the book, the book I didn't have wasn't
even the one I wanted.

I called ACM and discovered that whoever processed my order completely
ignored the title and author information in my fax and went right for the
6-digit order number, which it turns out was incorrect.  (Interestingly
enough, the order number identified a book on software quality.) I hadn't
received the wrong book because it was out of stock (I had received no
notification of this, either).

The lessons? Overworked order entry people will enter an order number
and simply ignore the accompanying description, even though the
description is much more likely to be correct. And next time I'll be
sure to check the order number directly with ACM, or leave it off.

Fritz Knabe  knabe@ecrc.de


The risks of Risks (Fritz Knabe)

Haritini Kanthou <KANTHOU@ACMVM.bitnet>
Wed, 25 Jan 95 12:18:23 EDT
Thank you for bringing to our attention the fact that in one of the ads in
CACM, the order number for Peter Neumann's Computer-Related Risks was
incorrectly cited as 706943.  The correct number is 704943, at $22.25 plus
shipping for ACM members or $24.75 plus shipping to nonmembers.

  [The incorrect number was first found in the original press release
  from ACM, and it got propagated to various other places.  PGN]

Haritini Kanthou, Member Services Mgr.  acmhelp@acm.org


ACSAC '95 Call for Papers and Participation

Marshall D Abrams <abrams@mitre.org>
Fri, 27 Jan 95 23:25:07 EST
             CALL  FOR  PAPERS  AND  PARTICIPATION

11th Annual Computer Security Applications Conference
December 11-15, 1995
New Orleans, Louisiana

The Conference

  The phenomenal growth of the Internet is threatening our very notion of
privacy and property.  Information networks and computers are routinely
processing private, proprietary, sensitive, classified, and critical
information.  The Internet has created an addiction to information and
instantaneous information exchange in the military, government, and private
sectors.  Computers are making decisions ranging from the mundane to life
threatening.  To provide protection to this information, the information
technology community must:

  o  Develop methodologies and tools for designing systems
      capable of protecting the sensitivity and integrity of
      information, and assuring that expected services are
      available when needed.
  o  Design safety-critical systems such that their software
      and hardware are not hazardous.
  o  Develop methodologies and tools capable of assuring that
      computer systems accorded trust are worthy of that trust.
  o  Build systems of systems out of components that have
      been deemed trustworthy.
  o  Build applications on evaluated trusted systems without
      compromising the inherent trust.
  o  Include computer security in enterprise modeling and
     reengineering.
  o  Extend computer security technologies to specifically
      address the needs of the civil and private sectors.
  o  Develop international standards for computer security
      technology.

  For the past 10 years the Annual Computer Security Applications Conference
has been helping the IT community meet these challenges by providing a forum
for information exchange that is unsurpassed.  The Conference will explore a
broad range of technology applications with security and safety concerns.
Technical papers, panels, vendor presentations, and tutorials that address
the application of computer security and safety technologies in the civil,
defense, and commercial environments are solicited.  Selected papers will be
those that present examples of in-place or attempted solutions to these
problems in real applications; lessons learned; and original research,
analyses, and approaches for defining the computer security issues and
problems.  Of particular interest are papers that present descriptions of
secure systems in use or under development, presenting general strategy,
methodologies for analyzing the scope and nature of integrated computer
security issues, and potential solutions.  Papers will be judged for best
paper awards.  A prize will be given for the Outstanding Conference Paper
and the Best Student Paper.  For the Best Student Paper, expenses to attend
the conference will also be awarded .

  Panels of interest include those that present alternative or controversial
viewpoints or those that encourage lively discussion of relevant issues.
Panels that are simply a collection of unrefereed papers will not be
selected.

  Vendor presentations of interest should emphasize innovative product
implementations, especially implementations involving the integration of
multiple products.  Vendor presentations that simply describe product
features will not be selected.

Areas of Interest:

Security in Enterprise Modeling and Reengineering
Trusted System Architectures and Technology
Encryption Applications (e.g., Digital Signatures)
Certification, Evaluation, and Accreditation
Application of Formal Assurance Methods
Trusted DBMSs, Operating Systems, and NetworksSecurity Policy
and Management Issues
Electronic Document Interchange
Open Systems and Composed Systems
Software Safety Analysis and Design
Risk/Hazard Assessments
AIS Security Tools

Instructions for Submissions:

  We provide blind refereeing of papers and ask that you put names and
affiliations of authors on a separate cover page only.  Substantially
identical papers that have been previously published or are under
consideration for publication elsewhere should not be submitted.  Panel
proposals should be a minimum of one page that describes the panel theme and
appropriateness of the panel for this conference, and should identify panel
participants and their respective viewpoints.  Send 5 copies of your
completed Papers and Panel proposals to Dr. Gary Smith (papers from Europe
should be sent to Klaus Keus) by May 31, 1995.  For panel/forum preparation
instructions, please contact Jody Heaney at (703) 883-5837 or via e-mail at
heaney@smiley.mitre.org.  Send five copies of your vendor presentation
proposal to Steve Rome.  Vendor presentation proposals should include an
abstract that describes the product and example applications.  Send one copy
of your tutorial proposal to Daniel Faigin.  It should consist of one- to
two-paragraph abstract of the tutorial, an initial outline of the material
to be presented, and an indication of the desired tutorial length (full day
or half day).  Electronic submission of tutorial proposals is preferred.

  Authors will be required to certify prior to June 30, 1995, that all
necessary clearances for public release have been obtained; that the author
or qualified representative will be presented at the conference to deliver
the paper, and that the paper has not been accepted or previously published
elsewhere.  Authors will be notified of acceptance by August 1, 1995.
Camera-ready copies are due not later than September 30, 1995.

Instructions to Students:

  Student papers must be authored 100% by students; no faculty authors are
permitted.  Send 5 copies of student papers to Dr.  Gary Smith; please
identify your paper as "Authored by Student."  Contact Ravi Sandu, Student
Paper Award Chair, to ensure that your paper is considered for the Best
Student Paper Award.  This award includes expenses to allow the student to
travel to the conference and present the paper.

Contact Information

    Send your papers to:
Dr. Gary Smith
Technical Program Chair
ARCA Systems, Inc.
8229 Boone Blvd., Suite 610
Vienna, VA 22182
(703) 734-5611
smith@arca.va.com
       or
Klaus J. Keus
BSI
Bundesamt fuer Sicherheit in der Informationstechnik
Kessenicher Str. 216
53129 Bonn  Germany
Phone: Germany-(0)228-9582-141
Fax: Germany-(0)228-9582-455
e-mail: keus@bsi.de

    Send tutorial proposals to:
Daniel Faigin
Tutorial Program Chair
The Aerospace Corporation
P.O. Box 92957, MS M1/055
Los Angeles, CA  90009-2957
(310) 336-8228
faigin@aero.org

    For information about Student Paper contact:
Ravi Sandhu
Student Paper Award Chair
George Mason University
ISSE Department, Mail Stop 4A4
Fairfax, VA 22030
(703) 993-1659
sandhu@isse.gmu.edu

    Send vendor proposals to:
Steve Rome
Vendor Track Chair
NSA, V23
9800 Savage Rd.
Ft. Meade, MD  20755
(410) 684-7374
romes@romulus.ncsc.mil

Videos Still Available!

Video tapes of the 1989, 1990, 1992, 1993, and 1994
Distinguished Lecturers are still available.  The titles and
lecturers are:

1994  Donn Parker
  "Computer Loss Experience and Predictions"
1993  H. O. Lubbes,
  "COMPUSEC, A Personal View"
1992  James P. Anderson,
             "Computer Security Myths and Mythtakes"
1990  Dorothy Denning,
            "The Data Encryption Standard:  Fifteen Years of
Public Scrutiny"
1989  Stephen T. Walker,
            "INFOSEC:  How Far We Have Come!  How Far Can We
Go?"

The price for each tape is $17.00.  An additional $5.00 will
be charged for foreign orders for postage.  Checks should be
made out to Applied Computer Security Associates (ACSA).  Send
check to Dr. Marshall Abrams, 2906 Covington Road, Silver
Spring, MD 20910.  Please indicate which tape you are
ordering.

Conference Proceedings

Some copies of the 1992 and 1994 proceedings can still be
purchased through Ron Ross for $25 each.  Contact him at The
Institute for Defense Analyses, 1801 N. Beauregard Street,
Alexandria, VA 22311, (703) 845-6617, e-mail: rross@ida.org.
For 1991 & 1993 Proceedings, contact the Computer Society
Press by dialing 1-800-CS-BOOKS or (714) 821-8380.  The non-
member price is $80, the IEEE member price $40.

Mailing List

To be added to the Annual Computer Security Applications
Conference mailing list to receive future conference
announcements, please send Name, Company, Address,
City/State/Zip, Country, and e-mail address to Vince Reed,
Publicity Co-chair , The MITRE Corporation, 1500 Perimeter
Pkwy., Suite 310 , Huntsville, AL 35806, phone: (205) 830-
2606, fax: (205)830-2608, e-mail: vreed@mitre.org

Sponsored by Applied Computer Security Associates in
cooperation with IEEE Computer Society Technical Committee on
Security and Privacy, and  ACM Special Interest Group on
Security, Audit and Control.

Marshall D Abrams
  telephone 703.883.6938    Information Systems Security Division
  secretary 703.883.5900    The MITRE Corporation, M/S Z202
  facsimile 703.883-1397    7525 Colshire Drive, Mc Lean, VA  22101-3481

Please report problems with the web pages to the maintainer

Top