The RISKS Digest
Volume 14 Issue 36

Wednesday, 24th February 1993

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

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…

Contents

3rd Conf. on Computers, Freedom, & Privacy, CFP 1993
Bruce R. Koball
2nd Conf. on Computers, Freedom, & Privacy — PROCEEDINGS
Lance J. Hoffman
Educational Loan Services — ELSI
Steve Hoffman
Phone problems: Re: "...Phone Jam", and a new problem
Bill Warner
MIT's on-line Student Information Services
Steve Bellovin
Kerberos and password-guessing attacks
Jonathan Kamens
Re: Tapping Phones
Fred Cohen
Re: On-line services (lack of) security
Bill Seurer
Re: request for opinions on Artificial Life
Bill Humphries
Info on RISKS (comp.risks)

Third Conference on Computers, Freedom, and Privacy, CFP 1993

Bruce R Koball <bkoball@well.sf.ca.us>
Wed, 24 Feb 1993 11:05:46 -0800
There's still time to register for CFP'93! A number of spaces in this
limited-attendance event are still available, so act now!

The Third Conference on Computers, Freedom and Privacy, 9-12 March 1993
San Francisco Airport Marriott Hotel, Burlingame, CA

The sessions in the main program include:

* ELECTRONIC DEMOCRACY
* ELECTRONIC VOTING
* CENSORSHIP AND FREE SPEECH ON THE NET
* PORTRAIT OF THE ARTIST ON THE NET
* DIGITAL TELEPHONY AND CRYPTOGRAPHY
* HEALTH RECORDS AND CONFIDENTIALITY
* THE MANY FACES OF PRIVACY
* THE DIGITAL INDIVIDUAL
* GENDER ISSUES IN COMPUTING AND TELECOMMUNICATIONS
* THE HAND THAT WIELDS THE GAVEL
* THE POWER, POLITICS AND PROMISE OF INTERNETWORKING
* INTERNATIONAL DATA FLOW

The conference will also offer a number of in-depth tutorials
on subjects including:

* Information use in the private sector
* Constitutional law and civil liberties
* Investigating telecom fraud
* Practical data inferencing
* Privacy in the public and private workplace
* Legal issues for sysops
* Access to government information
* Navigating the Internet

INFORMATION
For more information on the CFP'93 program and advance
registration call, write or email to:

CFP'93 INFORMATION
2210 SIXTH STREET
BERKELEY, CA 94710
(510) 845-1350
cfp93@well.sf.ca.us

A complete electronic version of the conference brochure with more detailed
descriptions of the sessions, tutorials, and registration information is also
available via anonymous ftp from sail.stanford.edu in the file: pub/les/cfp-93

    [SEE ALSO RISKS-14.21 (with an address correction in 14.26).  PGN]


2nd Conf. on Computers, Freedom, & Privacy-written & elec. proceedings

"Lance J. Hoffman" <hoffman@seas.gwu.edu>
Thu, 4 Feb 93 16:58:10 EST
     The written proceedings and the electronic written proceedings of the
Second Conference on Computers, Freedom, and Privacy, sponsored by the
Association for Computing Machinery and held March 18-20, 1992 in Washington,
D. C. are now available.

     To obtain the written proceedings, contact the ACM Order Department,
P.O. Box 64145, Baltimore MD 21264, 1-800-342-6626 or 1-410-528-4261 (MD, AK,
and outside US).  The ACM order number is 533921.  The price is $15.00 for ACM
members and $26.00 for others.

     To obtain the electronic proceedings, make an ftp connnection to
ftp.gwu.edu and login as "anonymous".  Get file CFP2S00, which has a table of
contents describing the other files CFP2S01, CFP2S02, ..., CFP2S11.  Get these
files if you desire them.

Professor Lance J. Hoffman, Dept of Electrical Engineering and Computer Science
The George Washington University, Washington, D. C. 20052
(202) 994-4955  fax: (202) 994-0227  hoffman@seas.gwu.edu


Educational Loan Services — ELSI

Steve Hoffman 24-Feb-1993 0959 <hoffman@xdelta.enet.dec.com>
Wed, 24 Feb 93 07:27:00 PST
My mother recently received several telephone calls from an organization
called Education Loan Services Inc (ELSI), of Braintree, Massachusetts.
Neither she nor any other family member had ever heard of ELSI — an
organization that reputedly acts as a student loan clearing house, and as I
have inferred from my conversations with them, as a collections agency.

The callers asked for her (Marie) or for my wife (Kelly) concerning a student
loan.  (Both my wife and I have had student loans.  Mom predates the modern
concept of a student loan :-) Mom, being computer-literate and quite familiar
with the more typical computer snarls, naturally assumed it was a computer
error and that it concerned either Kelly or me — she naturally assumed the
ELSI database had not been updated to indicate that both of our student loans
had been paid.

After an extended conversation with a representative of ELSI, I found they
were "cold calling" anyone with a name that matched those on their loan
paperwork, and further, that the match with Kelly's name was (apparently) a
fluke.  Further, the only way they claimed they could confirm that they had a
mistake was for me to provide them with Mom's social security number.

ELSI refused to accept any other information from me — length of time at
address, differences in surnames, attendance at other schools, etc --
concerning the parties (not) involved, nor could they provide any information
on the cosigners of the student loan they claimed they were calling on.

When my mother called ELSI back, a (different) ELSI representative indicated
that it appeared to be a simple mix-up on the area code, and that her portion
of ELSI did not have direct access to the ELSI folks placing the outbound
calls.  (Which we found rather surprising.)  Interestingly, a different ELSI
representative had told me that ELSI was calling people based on directory
services information — and not based on a mixed-up telephone number on the
loan paperwork.

This situation strikes me as having multiple risks.  I could have provided
ELSI with a bogus social security number for Mom.  (I declined to provide any
number.)  If ELSI could validate the social security number — and I am quite
certain they could, via any one of several credit bureaus — they would have
already known that mom wasn't a match.  (And then why did they call?)  Such an
organization could also easily be illicit — "scavenging" either for social
security numbers or worse, scavenging payments from the parents of former
students — parents who might unknowingly send an ELSI-like organization a
payment or two to keep their child from `defaulting'.

    Steve Hoffman      hoffman@xdelta.enet.dec.com


Phone problems: "...Phone Jam" (RISKS-14.31) and a new problem

<warner@ohio.gov>
23 Feb 1993 20:15:07 -0400 (EDT)
One of the major causes of the long time to get the data from the failed
computer is that phone switches have a lot more 'state' that they did in the
past.  For example, the State of Ohio Centrex (where I work in the telecom
office) is served by the switch which failed.  We have somewhere over 20,000
lines (I don't keep up with the details.)  In the past we had to configure
options like Call Forward No Answer and Call Forward Busy with written service
orders.  But now each line has an option called Call Forward No Answer
Universal (At least the name is close!) which allows someone at the phone to
specify the number to Call Forward Busy to.  This can be changed at any time.
Therefore in the case of a switch failure you can not just return to the
"standard" configuration, but must load a lot of 'state' information from the
failed computer.

This type of state is becoming more common in "fancier" features.  It makes it
much easier to manage a large number of phones!  Features like call
forwarding, which also require the switch to remember a number, are becoming
more and more common.

The State of Ohio phones were dead from about 14 minutes or so.   This likely
affected the Franklin County Ohio Highway Patrol Post's (and General
Head Quarters) public numbers also.


Also, in yesterday's Columbus Dispatch it looks like Ohio Bell lost another
one:

The Columbus Dispatch, Wed Feb 17, 1993 Page 3 C (Metro Section)
    (Small article at the bottom in Columns 1 & 2)

"Blown Fuse disrupts phone service"

A blown fuse in the Ohio Bell switch serving 54,768 telephone lines in
Worthington disrupted service throughout the day yesterday.  Repairs were
expected to be completed last night.  Ohio Bell Spokesman Keith Jameson said
911 and other emergency numbers remained in operation, although getting a dial
tome within the affected area was slow.  Calling into the area was difficult
most of the day, since Ohio Bell purposely blocked 75 percent of incoming
calls while repairs were under way.  Jameson said that strategy enabled people
within the area to make calls.  By 5 PM, the company had reduced blocked
incoming calls to 50 percent.  The switch shut down at about 10:30 AM, when at
least one fuse blew, but Jameson said there may be other problems with the
switch.  The problem was not weather related, he said.

William "Bill" Warner, III (N8HJP), State of Ohio - Telecommunications
2151 Carmack Rd, Columbus, OH 43221 (614)466-6683 warner@ohio.gov (Internet)


MIT's on-line Student Information Services (Kamens, RISKS-14.35)

<smb@research.att.com>
Wed, 24 Feb 93 12:21:43 EST
>In order to use SIS to access personal data, a user must first register an
>"extra" password with the Kerberos database.  The program that registers this
>password does so by transmitting it to the Kerberos server in encrypted form
>(using a key derived from the user's main Kerberos principal, for which he
>already has a password) so that it isn't exposed to the network.

But has the Kerberos protocol been beefed up yet to guard against
password-guessing attacks?

As Michael Merritt and I noted in our critique of Kerberos (Winter Usenix,
1991, Dallas), Kerberos is vulnerable to password-guessing.  An intruder, from
anywhere on the Internet and without any authentication, can request
ticket-granting tickets for any user.  These are encrypted with a key derived
from the user's password.  But guessing at passwords is an old game — and one
that succeeds, with ~25% probability, against typical UNIX system passwords.
Kerberos is somewhat more secure, since it permits passwords to be longer than
8 characters, but I'm unaware of any study that's been done to find out if
people actually take advantage of this.

Granted, such attacks may not succeed against any particular student.
But against a collection of students, the odds are pretty good that
some will be vulnerable.

I've seen proposals to strengthen Kerberos against such attacks, but I don't
know if these have been deployed yet.  And there are protocols that prevent
any password-guessing attacks, even by eavesdroppers (i.e., Lomas et. al, 1989
SOSP; Bellovin and Merritt, 1992 Oakland Symposium).

My point here is not to criticize the designers of SIS.  All things
considered, they seem to have done a very good job; the only other safeguard I
can think of would be to notify the student of any new uses of the SIS
account.  Rather, I'm trying to point out that secure systems can't be built
on weak foundations.  Intruders don't go through security; they go around it.

        --Steve Bellovin


Kerberos and password-guessing attacks

"Jonathan I. Kamens" <jik@aktis.com>
Wed, 24 Feb 93 18:14:16 -0500
   From: smb@research.att.com
   Date: Wed, 24 Feb 93 12:21:43 EST

   But has the Kerberos protocol been beefed up yet to guard against
   password-guessing attacks?

Yes.

The most recent release of MIT Kerberos Version 4 includes kadmin
protocol enhancements to allow for the rejection of weak passwords,
and code on the server to check and reject weak passwords.

I don't know if any V4 vendors have incorporated changes like this
into their products; I suspect it will happen eventually if there is
enough demand for it.

Furthermore, MIT Kerberos Version 5 supports optional preauthentication.  MD5
on the user's password, Smart Card technology, or some other technique (the
code is pretty abstract, so new preauthentication types can be added
relatively easily) is used to create a "magic cookie" which is passed to the
server along with the TGT request.  If the cookie is wrong, the server won't
give the user a TGT to decrypt.  Preauthentication can be required or optional
on a principal-by-principal basis.

MIT V5 doesn't yet have weak-password rejection in it, but the hooks for it
are there, and it will be added before the first official (i.e., not beta
test) V5 release.

I don't think DCE Kerberos has preauthentication in it right now, and I don't
think they plan to add it before the first official DCE release (If you want
them to, and you're a member of the OSF, then let them know!).  I don't know
whether or not DCE Kerberos has weak-password rejection in it.

It is true that both V4 and V5 are still vulnerable to network eavesdropping
weak-password attacks, since an eavesdropper can watch for a TGT on the
network and try to decrypt it once it arrives, even if he doesn't know the
preauthentication magic cookie which convinced the server to send the TGT.
However, weak-password rejection makes the risk of an attack of this sort
minimal, and it is not vulnerable on an entire-Internet scale like the attack
which Steve mentioned.

(Thanks to Ted T'so, tytso@mit.edu, for confirmation of much of the
information above about V5.)

Jonathan Kamens                                       jik@Aktis.COM


Re: Tapping Phones (Schumann, RISKS-14.35)

Fred Cohen <fc@turing.duq.edu>
Wed, 24 Feb 93 07:51:07 -0500
I must disagree [with the statement] that I am creating an unrealistic
security scare.  In fact, even if you are running Kermit from a PC, there are
ways for remote sites to inject commands/code into your machine.  The same is
true for many PC-based telnet, FTP, and Xmodem protocols.  Here is a real
example:

An FTP program was commonly used at one university to transfer information
between user PCs and a file server.  One day, someone noticed files appearing
on their computer that shouldn't have been there.  On subsequent investigation
it was found that the FTP protocol allowed remote users to send files into
the PC whenever the PC was setup to do outgoing transfers.  It turns out that
this is one of the most popular - public domain - FTP packages around.  At
this one site, a password was added to the process to prevent exchange when
the other party did not know the password - but - they did a poor job of it,
and someone discovered a trivial way to get past it within a few days.

Another?:

The well known attack where you transmit characters to a remote terminal that
tell the terminal to store a sequence of characters and play it back can be
exploited to attack remote computers running terminal emulators that are
accurate.  If you run Kermit, you may find that the VT emulations are good
enough to do the job.  That's right - even if you are simply logged in typing
commands, you can be had if the attacker is good enough at it and your package
is a true emulation.  In fact, when you login, you usually even tell the
remote site what kind of terminal you are emulating, thus easing it's attack
burden.

Another?

X-windows without the magic cookie allows remote users to watch what is being
displayed on your screen over the network.  Most X setups are insecure in this
way - at least most of the ones I have seen.

Another?

Well - I'll hold off for now awaiting your response.  My point still seems
to hold - encrypting links is not adequate to prevent access to your data -
encryption without good computer security is generally not adequate - the
government or anyone else willing and able to go to the trouble can get you
by exploiting the places you login to - it is not patently safe to login to
on-line information services, even if you don't run their software. - FC


Re: On-line services (lack of) security (Schumann, RISKS-14.35)

Bill Seurer <seurer+@rchland.ibm.com>
Wed, 24 Feb 1993 13:45:09 -0600 (CST)
"Mark W. Schumann" <mark@whizbang.wariat.org> writes in RISKS 14.35

>Prodigy, the latter service you mention, requires the use of its own front-end
>program on your PC.  You cannot use Prodigy without it.  Since this front-end
>program executes on your PC, it does have the potential for the abuse you
>mention.  I personally do not use Prodigy in part because of this security
>loophole.

Oh boy, let's kick Prodigy around some more.  Long ago when I was a
Prodigy subscriber and the rumors of Prodigy's uploading of stuff it
shouldn't started I did some experiments the results of which were
posted here.  I proved (as best I could) that the rumors were probably
unfounded and based on Prodigy's method of allocating disk space without
clearing it of previous data first.  Some other people who contacted me
had done similar experiments with similar results.

>On the other hand, other communication services, such as Compuserve, do not
>have this questionable "feature" at all.

America On-Line, TSN, and probably others also have special
communication programs that you must use.  Other services which do not
REQUIRE a specific comm program nonetheless OFFER one that usually
improves use of the service.  Genie (for sure, Aladdin) and Compuserve
(vague memory from years ago) both do.

>You dial Compuserve from your PC with a communications program of your choice.
>At all times the contents of your memory and hard drive are under the complete
>control of your CPU and communications program.

Yeah, but how do you know that the authors of PC-TALK, Qmodem, or
whatever don't have a special hook in them that when you call up
Compuserve it doesn't (semi-seriousness on) upload all your pitiful
Tetris scores so the FBI can blackmail you?  Or heck, maybe Microsoft
has modified Windows or DOS to append juicy data to the end of files
opened for uploading somehow.  Maybe the FBI knows that the authors of
Qmodem use Turbo C++ (or whatever) and have had Borland modify the
compiler to insert this surreptitious uploading code into the comm
program automatically when it is compiled.  Maybe AMI has modified this
BIOS to do something like this.  Who can you trust?

(paragraph about QUICKB deleted)

>Bottom line: No online service can cause your PC to execute code that is not
>in the PC's memory space, Prodigy notwithstanding.

Not true as I have already shown.

In any case, any service that tried something like this would be
committing corporate suicide.  People would notice that their modems
were uploading all this data if by no other means than the Send Data
light on their modem and the hard disk access light and doubtlessly one
of them would figure out what was happening.

Even at high speeds with top notch data compression it still takes a
long time to transfer any significant amount of data.  Maybe "they"
could somehow work it into the background so whenever your modem sent
data you wanted it to a little bit extra would get mixed in but that
seems pretty pointless.

- Bill Seurer    Language and Compiler Development       IBM Rochester, MN
  Internet: BillSeurer@vnet.ibm.com    America On-Line: BillSeurer@aol.com


Re: request for opinions on Artificial Life (Cohen, RISKS-14.34)

"Bill Humphries, Data Husbandry Flunky" <humphrie@ssc.wisc.edu>
Wed, 24 Feb 93 13:41:18 -0600
I understand that most AL research is done by writing AL programs which run on
a virtual computer. The practice is analogous to hacking E Coli which can only
live on a particular medium which is not availiable outside the lab's petri
dish.

I have no problem with people publishing code, even code which could be put
to 'sinister' ends (such as PGP). The author is not responsible for the actions
of the reader or end-user.

If you want to provide some sort of security, perhaps you can make a
proprietary virtual machine which you distribute with the code in your book.

The code would then only run on the virtual machine. This could provide some
way of at least tracking the spread of malevolent AL programs.

Obviously this is not a perfect solution, but hey, what that guy from NASA
says, this isn't a risk free world.

Bill Humphries <humphrie@ssc.wisc.edu> : U. Wisconsin Economics : 608-262-4543

Please report problems with the web pages to the maintainer

x
Top