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…
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
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]
[...] 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
>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)
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
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
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
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
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
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
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