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 6 Issue 9

Thursday, 14 January 1988

Contents

o "The Consultant" by John McNeil
Jim Horning
o Re: Missent Missives
Ge' Weijers
Steve Caine
Brent Chapman
o Re: PCs die of New Year Cerebration
Sam Cramer
o SSN / Phone Number / etc.
Andrew Burt
Bruce O'Neel
o Library book borrowing privacy
Geoff Goodfellow
Will Martin
Steve Cisler
o SSNs
Ian G Batten
o Info on RISKS (comp.risks)

"The Consultant" by John McNeil (c) 1978 -- Book Review

Jim Horning <horning@src.dec.com>
13 Jan 1988 1714-PST (Wednesday)
"The Consultant" by John McNeil (c) 1978 
First published in Great Britain in 1978 by Weidenfeld & Nicolson Limited
1983 edition published by Century Publishing Co. Ltd.
        76 Old Compton Street, London W1V 5PA
ISBN 0 7126 0174 0

This is a novel relevant to the concerns of RISKS that I don't think
has been discussed here before.  (On its own, it's quite a competent
crime thriller, the best computer crime fiction I've read--a real
late-night page-turner.)

The central theme of "The Consultant" is computer fraud.  The protagonist
is a computer consultant who specializes in discovering embezzlement
and fraud.  His clients know that he is good at finding it.  What
they don't know is that after he exposes a culprit he quietly takes
over the security loophole for his own use.

Since most of the characters in the book are not computer sophisticates,
most of the explanations are given in simple terms, but McNeil does
not talk down to the reader, and does not spout technical nonsense.
He manages, in quite a readable way, to present many of the basic
precautions against computer fraud, and explain both why they are
necessary and why they are not sufficient.

Anyone familiar with the state of the art ten years ago should spot
some reasons why the precise fiddle described in the book would not
have succeeded.  (Perhaps some details were changed to protect the
guilty?)  But any hotshot programmer reading the book will probably
come up with a scheme that he believes WOULD have worked; I fear that
some of them will be correct about this.

RISKS readers will realize that the situation has gotten worse in
the last decade.  There is vastly more (and more valuable) information
in computer systems.  The systems themselves have gotten more complex,
making "weevils," as well as bugs, harder to locate and remove.  Computer
networks have information and code sloshing around in ways that are
much harder to audit.  It is steadily easier to turn bits into cash.
And the technology of security for information systems doesn't seem
to be keeping up.

This is a good book to give your manager or vice-president when you
want to dampen unwarranted optimism about the safety of data in an
existing or planned information system.  He will almost certainly
come away convinced that it is unwise to trust the system without
repeated security audits--and that it is foolhardy to trust your
auditors!

On the other hand, if you want to INDUCE unwarranted optimism, you
may be pleased to know that this book doesn't seem to have a very
wide circulation in the US.  Brian Randell had told me about it some
time ago, but I was unable to find it in any local bookstores.  I
am grateful to him for mailing me a copy from England.

The cover says that this is "The novel on which the 4-part BBC TV Series was
based," and states that Hywel Bennet played Christopher Webb in "the BBCtv
production of THE CONSULTANT, produced by Ron Craddock, directed by Cyril
Coke and adapted by Alan Plater."  Does anyone know if this series played on
public TV in the US?  I don't recall hearing about it.
                                                              Jim H.


Fraud failed due to computer failure.

Wed, 13 Jan 88 03:00:55 +0100
Three men, one of them an employee of the bank, tried to steal 15.1 million
dollar from an Amsterdam bank. The employee booked at the 24th of December
$8M4 & $6M7 to a swiss Bank account in Zuerich opened by the other two
persons. Normally such a transaction requires two passwords from two
persons.  Somehow the employee managed to get the password of somebody else.
Due to a technical failure the second transaction didn't work and warnings
popped up on other peoples' screens that a transaction failed.  These people
alarmed their bosses, since the transaction was nowhere scheduled.  Also the
police and the Swiss bank were warned, which disabled the accounts.  The
three men tried the same day to collect $5M. When they heard the account
was disabled, they fled. Their identity was known by that time.  They turned
themself in the 4th of January.

(Condensed and translated from `de Volkskrant' 12 Jan '88, of course
without permission.)


Re: Missent Missives

Ge' Weijers <mcvax!hobbit!ge@uunet.UU.NET>
14 Jan 88 11:08:47 GMT
>    [It used to be a relatively easy matter to break off a few tynes on
>    your answer-back drum, or indeed install a different one, thus being
>    able to masquerade as someone else.  Perhaps it is harder now?  
>    Somehow I doubt it.  PGN]

It's getting easier all the time. In the days of mechanical teletypes tampering
with the answerback drum could be detected, but now most teletypes have the
answerback message stored in ROM. A hacker/criminal can easily change this
message, and pose as somebody else.  (The answerback drum is also used for the
HERE-IS message, a voluntary identification.)  The current trend of using PC's
as intelligent telex terminals makes this tampering even easier. The answerback
function really should be implemented by the switching system, not by the user
terminal.

Ge' Weijers, Informatics dept., Nijmegen University, the Netherlands
UUCP: {uunet!,}mcvax!kunivv1!hobbit!ge


Telex Answerback Spoofing

Steve Caine <shc@cfg.com>
Thu, 14 Jan 88 08:36:27 -0800
Spoofing a telex answerback is even easier than in the days of the KSR 33 and
its answerback drum.

Our telex "machine" is just a port and a couple of programs on our VAX.
To send a telex, we call our IRC (International Record Carrier) who
transmits a WRU (^E).  If we respond with our answerback, that's it.  We
can enter the number we want, the connection is made, and we have a 2-way,
real-time conversation.  In practice, of course, we just send our message
but we prefix & suffix it with a WRU so we can be "sure" we have reached
the correct number.

When someone calls our telex number, the IRC switcher dials the telephone
number they have on file for us, our machine answers and responds to the IRC's
WRU with our answerback.  If it matches what the IRC expects, their switcher
make the connection between us & the caller.  Our program just collects up the
message & then mails it to a couple of standard mailboxes on our system.

Note that it is trivial to spoof the answerback.  In our program, it is just a
file (/usr/spool/telex/ANSWERBACK).  Also, the answerback is in no sense a
password.  It's at the bottom of every sheet of our letterhead, for example,
and it appears in all the published telex directories.

In most of the world, a printed telex message with an exchange of answerbacks
at the start and the end is a legal proof that the message was sent AND
received.

Steve          (shc@cfg.com     //     ...!{uunet,ihnp4}!cfg!shc)


More Touch-Tone and lack-of-answerback problems

Brent Chapman <chapman%mica.Berkeley.EDU@violet.berkeley.edu>
Thu, 14 Jan 88 13:25:15 PST
The recent, unrelated articles in Risks about (mis)use of Touch-Tone
technology and lack of recognizeable answerback (the Jesse Jackson Telex
to the Washington Post) brought to mind a similar problem that I face
several times each week. 

I run the computer facilities of Capital Market Technology, a finance company
in Berkeley.  We deal in foreign exchange risk management, so our operation has
some around-the-clock aspects to it (although most of our work is done during
normal West Coast business hours).  Part of my job is being on-call at all
times to deal quickly with system problems; I carry a pager with a 10-digit LCD
on the top.  To reach me, someone dials the phone number assigned to my pager,
then punches in the numeric message (usually a phone number or a code) that
they want to appear on my pager LCD.

The problem is, the pager controller answers with a simple series of beeps,
prompting the caller to enter the message.  The caller gets no indication of
_whose_ pager they've reached.  In the six months I've had the pager, my
company has used it exactly once, yet it goes off several times each week
(often in the middle of the night)!), apparently because of people dialing the
wrong number, Sometimes, I'll get several calls per day for a few days in a
row; I'm convinced that people are programming the wrong number (mine!) into
their phone memories, and keep dialing that and wonder why the person they
_think_ they are paging isn't answering calling back.

If everyone just punched in their phone number as the "message", it might not
be so bad.  Life isn't so simple, however.  First, even those that _do_ enter
their phone number as the message usually don't bother to enter their area
code; the service area of our paging company covers all or part of 4 different
Bay Area area codes (415, 408, 916, and 704), plus the Phoenix/Tucson and Los
Angeles/San Diego areas.  Second, people (including my company) often use
private codes.  Third, the paging company also provides non-message (beep-only)
pagers; if someone calls my pager number, but doesn't enter a message, my pager
still goes off (displaying a special "no message" code).

I've gotten to the point that if it goes and the message isn't in our company
code, or if it isn't a phone number that I recognize, I ignore it.  Sometimes,
if it goes off a series of times in the middle of the night, I'm forced to turn
it off just so that I can get some sleep, and risk missing a "real" call from
my company (although they can still call my home number).

It seems to me that a lot of my problems with the system would disappear if the
controller answered with a recorded or syntheszed message ("Please enter your
message for Brent Chapman of Capital Market Technology at the tone.") rather
than the series of beeps it uses now.

Brent Chapman                   Capital Market Technology, Inc.
Senior Programmer/Analyst           1995 University Ave., Suite 390
{lll-tis,ucbvax!cogsci}!capmkt!brent        Berkeley, CA  94704
capmkt!brent@{lll-tis.arpa,cogsci.berkeley.edu} Phone: 415/540-6400


Re: PCs die of New Year Cerebration [Risks 6.5]

Sam Cramer <cramer@sun.com>
14 Jan 88 20:39:19 GMT
Re: Suns lose track of time after New Years

The Sun problem involved the clock chip being improperly accessed,
and time drifting as a result.  As I understand it, this is really
a double bug, because improper input makes the clock chip go 
bonkers.  Thus, a bug in software tickles a bug in hardware.

Re: viruses and buried jokes

During college I worked at Sun Electric, which makes automated testers
for cars.  A friend wrote the firmware for an emissions tester that would
printed time-stamped reports.  For some reason, on power-up the date was 
initialized to his birthday.

I understand that video game programmmers often insert "signatures" into
their games.

Sam Cramer  {cbosgd,decwrl,hplabs,seismo,ucbvax}!sun!cramer  cramer@sun.com

                                                            [Sun of agon.  PGN]


SSN / Phone Number / etc. (Re: RISKS-6.1)

Andrew Burt <isis!aburt@husc6.harvard.edu>
6 Jan 88 06:04:06 GMT
Re: Jordan Hayes <jordan@ads.arpa> on credit purchases:

And if someone just decides to call you up and ask, "Hi, this is Tom,
I'm the manager at 

Re: SSN and state universities.

Bruce O'Neel <XRBEO%VPFVM.BITNET@CUNYVM.CUNY.EDU>
Wed, 06 Jan 88 18:54:08 EST
An unnamed state university in MD takes your SSN and adds a digit to it (a 1),
therefore they say it isn't you SSN.  ("SSN's are 9 digits, you student id is
10 digits).  Another unnamed state university in VA is very careful to do the
same thing but call it you student id.  Only if pressed (What is my student id?
 "It's on your student id card"  "But I don't have one of those" ...) do they
say SSN.


re: required disclosures -- library book borrowing privacy

the terminal of Geoff Goodfellow <Geoff@csl.sri.com>
14 Jan 1988 10:40-PST
Steve Cisler mentions that most libraries and librarians are very conscious
of the privacy issue when it comes to records about library users.  He
explained how their system made and broke links and kept no audit trails of
past links when they were broken upon book return.

But, what about backup's?  Does the library system do monthly, weekly,
daily, hourly (like MIT-Multics used to) or real-time file mirroring of book
borrowing information?  how long are the backup tapes/disks kept before
being recycled?  Stored off site, etc.?

As was discovered (on a hunch) in the National Security Council office
automation system (PROFS), backup's played a key role in the Iran-Contra
investigation of Oliver North & John Poindexter.


Re: SSN Required Disclosures -- library social security privacy

Will Martin -- AMXAL-RI <wmartin@ALMSA-1.ARPA>
Wed, 13 Jan 88 9:23:53 CST
Interesting comment there; glad you posted it. However, does this mean that
the library then has no way of tracing back the chain of patrons who checked
out a book to find out who might have damaged it, so they can be charged for
this? For example, just a couple weeks ago, I checked out and read a book
from the St. Louis Public Library (which uses a bar-code-scan system now;
they used to take pictures of the library card and the data pasted inside the
book's front cover). I discovered that a page had been torn in half near the
end of the book. Is there no way for the library to query the patron(s) who
had checked out this book before me, to see if any of them would own up to
damaging it?
                                                           Will Martin
wmartin@ALMSA-1.ARPA   (on USENET try "...!uunet!almsa-1.arpa!wmartin")


Re: SSN Required Disclosures -- library social security privacy

Steve Cisler <well!sac@cogsci.berkeley.edu>
Thu, 14 Jan 88 12:53:52 PST
No, there is no way to query patrons who may have borrowed a book before you
did.  We take the stance that it is better to lose some control and protect
privacy.  In some cases we catch the damage before shelving the book and
note that in the front cover "Damage noted 1/14/88" etc.  Steve


SSNs (RISKS-6.8)

Ian G Batten <BattenIG@CS.BHAM.AC.UK>
Thu, 14 Jan 88 12:49:14 GMT
The discussion of the pros and cons of having to reveal your SSN in the USA
is rather interesting.  The UK has virtually no national register of people
(officially).  You legally have to register births, deaths and marriages and
in principle you have to be on the electoral roll (although the take-up rate
of this is reputed to be less than 70 percent in some inner-city areas).
There is no national identification number or card (not even drivers
licenses.  When I was in California someone told me there were non-driving
driving permits for the blind to act as ID).

This all seems similar to the USA.  Yet I rarely have to produce my social
security number (for supplementary benefit, to request a tax code and for my
employer to pay my NI contributions).  Libraries want a proof of ID, but
anything will do.  Each body uses a distinct magic number for people --- I
have a Social Security Number, an NHS number, a Tax Reference, a Driver Number.

I wonder why the USA has got its systems hung up on one ID number.  Here
SSNs are used solely for Social Security, Driver Numbers for driving etc.  I
have never yet seen a form related to anything other than a number's own
domain requesting one.  Do Americans need to quote an SSN for a passport?  A
credit card?  A mortgage?  Why is a country with so many liberal tendencies
allowing itself to make the job of repressive law-making easier?
                                                                     ian

Please report problems with the web pages to the maintainer

Top