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 18 Issue 2

Tuesday 9 April 1996

Contents

o The weakest link: Social (In)security Administration
Sean Reifschneider
o ``Jail Gives Hackers a Lesson in Reality''
PGN
o Australian Insurance Company and Database
Andrew Waugh
o De facto Daylight Savings
Matt Welsh
o Re: Teen Accused of Hacking
William Ehrich
o Microsoft Exchange helpfully misdirects e-mail
John Hoffmann
o Re: Notes on e-mail: Use diaeresis
Tim Pierce
Otto Stolz
o CompuServe's "secure login protocol": two steps forward, one back
Heinz-Bernd Eggenstein
o IBMMAIL e-mail address woes
Erik Naggum
o Re: X-Confirm-Reading-To: Pegasus woes on mailing lists...
Peter Yamamoto
o The risks of .forward
Christophe Beauregard
o Re: Wrong approach to Java security
Andrew Berman
o Re: Risks of rewritable BIOSes
Jeremy J Epstein
Nicholas C. Weaver
o Re: Computers, Freedom and Privacy '96
Shabbir J. Safdar
o Info on RISKS (comp.risks)

The weakest link: Social (In)security Administration

Sean Reifschneider <jafo@tummy.com>
Sun, 7 Apr 1996 22:12:30 -0500 (CDT)
The URL "http://www.nando.net/newsroom/ntn/info/040696/info5_14984.html"
reports "one of the biggest breaches of security of personal data held
by the federal government".  Apparently several employees of the Social
Security Administration sold information including  SSNs and mother's
maiden names of more than 11,000 people to a credit-card fraud ring.

The fraud ring was able to use this information to activate cards which
were stolen from the mail.  Citibank had implemented a scheme which
required customers to "activate" their credit cards when they receive
them by calling a phone number and providing personal information like
their mothers maiden name.

It seems that while systems are being designed to protect our property, it's
just causing the crime to move closer to the person.  If someone steals your
credit card from the mail or your car from the parking lot, you're probably
at a safe distance.  Instead, they are forced to carjack your car at a
stoplight because of your alarm system, or find out personal information
about you.

Similarly, I heard about home breakins on alarmed houses in which the
burglar would regularly trigger the alarm and be careful to leave no
traces.  Once the police stopped coming (because the alarm was faulty),
they were free to break in and swipe whatever they like.

No matter how secure the system, the weakest link can be the clerk who's
paid $12K/year to work on the system.  It doesn't take much money to
convince this person to hand out our personal information.

This sort of thing kind of makes the hassle I went through in keeping my
SSN from my insurance company.  If you've never tried it, for me it was
a huge hassle...  Apparently, all of my claims needed to be handled by
hand by one of the supervisors.  Of course, if everyone did it, their
$4/hour clerks could take care of it.

Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan>  HP-UX/Linux/FreeBSD X11 scanning software.

    [Also noted by Monty Solomon <monty@roscom.COM> quoting from Edupage,
    and WOODWARD@BINAH.CC.BRANDEIS.EDU (Beverly Woodward), who cited the
    article in "U.S. Workers Stole Data on 11,000, Agency Says" in
    *The New York Times*, 06 Apr 1996, p. 6, from which most other
    reports seem to have been drawn.  PGN]


``Jail Gives Hackers a Lesson in Reality''

"Peter G. Neumann" <neumann@csl.sri.com>
Mon, 8 Apr 96 18:45:15 PDT
Terry Ewing (now 21, with 21 months in federal custody ahead of him)
downloaded 1,700 credit-card numbers off of a Tower Records computer system,
just before leaving for DefCon, the West Coast "hackers' convention".  His
friend Michael Kim (now 20) is facing an 18-month sentence.  Apparently,
Tower folks knew their systems had been under attack previously, and were
monitoring misuse.  Police encouraged Tower to wait for the next attack --
in which the intruders used the Tower computer to sort the captured
credit-card numbers by expiration date and create a file of those with a
date at least a year away -- while being observed.  Agents tracked the
intrusion to their apartment, which was searched, revealing the purloined
information.  The two young men were convicted of a felony, although they
had not profited from the credit-card numbers.  [Source: *San Francisco
Chronicle*, 8 Apr 1996, p.A2.]

  The article concludes with a quote from Mike Godwin of EFF about those
  who ``have this myth that they are cool guys, and [that] the cool guys
  always win over the suits.  But the fact is that they are half-socialized,
  post-adolescents with serious ethical and moral-boundary problems.''

    [Stores should not store credit-card numbers, but I guess we can no
    longer number the stores that do not behave sensibly.  I just asked a
    mail-order outfit if they would keep a card number around for a
    long-deferred delivery; the answer was, ``yes, but we keep in a place
    where no one can access it.''  I am sure that gives you RISKS readers a
    lot of comfort.  PGN]


Australian Insurance Company and Database

Andrew Waugh <A.Waugh@mel.dit.csiro.au>
Sat, 06 Apr 1996 15:07:33 +1000
The 6-7 Apr 1996 edition of 'The Weekend Australian' carries a report (p 5)
on a court case involving the large Australian insurance company AMP and an
attempt to build a large database of all Australian households.

It was alleged that the "massive database... was supposed to identify every
household in Australia, give each household a unique identifier number,
detail the dwelling type of each household - whether it was two-story,
weatherboard [timber] or brick - and also detail the fire, storm and flood
risk rating of each home." The contractor developing the database, Indata,
expected this database to give AMP a significant commercial advantage.

This database was alleged in court to to have been based on a magnetic tape
of the Australian electoral roll. Under the Australian Electoral Act,
magnetic tapes of the electoral roll cannot be obtained for commercial
purposes. The former manager of Indata said that he had assumed AMP had
investigated the legalities of purchasing the tape and that Indata and AMP
were acting within the law. The tape had already been purchased before the
manager joined Indata.

The court case is a committal hearing against a former AMP client manager
who is charged with 12 counts of attempting to defraud AMP.  The fraud
involves payments to Indata totalling $324,809 (Aus). AMP is expected to
claim that was not aware of the illegal purchase of the electoral roll and
that their client manager had inappropriately authorised payment to Indata.
AMP has demanded return of the money.

The committal hearing will continue next month.

andrew waugh


De facto Daylight Savings

Matt Welsh <mdw@CS.Cornell.EDU>
Sun, 7 Apr 1996 13:31:38 -0400
At http://www.timing.se/Daylight.html there is a brief discussion
of the rules for Daylight Savings Time changeovers for central Europe
and the UK. At the end of the page it says:

> NOTE: From autumn 1996 the rule of changing from standard time to
> daylight time is changed. The new rule is valid for central Europe
> including the UK is:
>
> Standard time    to  Daylight Saving       LAST SUNDAY OF MARCH
> Daylight Saving  to  Standard time         LAST SUNDAY OF OCTOBER
>
> The rule is a "de facto standard," not a law.
>
> The switching occurs at 01:00 UTC for central Europe (Stockholm Paris etc.)
> Local time that is at 02:00 STD to DST  and  03:00 DST to STD.
> (STD = Standard time, DST = Daylight Saving Time or Summer Time.)
>
> Note: The legal switching is steered by laws that state dates for a couple
> of years. When a period ends a new law is issued that gives the dates for
> the next years.
>
> The Laws do not state any general rule. Only dates for a couple years
> each time. The "de facto rule" works, but there is no warranty it will
> work forever!

With all of our scrambling about to deal with the Year 2000 problem,
shouldn't we be just as concerned with this inconsistency that arises
yearly (especially if there are no 'hard and fast' laws/standards to dictate
DST changeovers)?

M. Welsh, mdw@cs.cornell.edu


Re: Teen Accused of Hacking

William Ehrich <ehrich@minn.net>
Sat, 6 Apr 1996 11:32:31 -0600
If my bank kept my money in a cardboard box in their parking lot and
children stole it, I would blame the bank before the children. As long as
corporations and institutions design their computer systems only for
convenience and least cost, with maybe a superficial gesture at something
called 'security', they won't solve the problem.

The biggest risk of all is from people who won't accept their responsibility.

- William Ehrich


Microsoft Exchange helpfully misdirects e-mail

John Hoffmann <john@netweave.com>
Mon, 8 Apr 1996 11:40:21 -0400
Like most e-mail clients, Microsoft's Exchange allows you to maintain lists
of user's addresses along with aliases.  In our simple configuration, we
have two, a personal list and a global list.  Up until recently, since our
e-mail system was closed and limited to project members, my personal list
was almost empty.  Since we have added an Internet gateway, I've begun
adding addresses not on the global list to my personal list.

Exchange has another useful feature as well, it will expand names from just
the first characters.  If multiple names match the abbreviation, it will ask
you to pick one.

Today I sent out an internal message, using "schu" as an abbreviation for
schumacher, which I have done many times in the past.  Shortly there after
the message was returned from the AOL e-mail daemon as undeliverable, highly
surprising since it was an internal message not destined for the Internet.

It turns out that last week I incorrectly added an AOL user whose name also
begins with "schu" to my personal address list.  Exchange apparently only
checks one list at time, flagging multiple possibles only within the list.
In this case, it checked my personal list first, matched the AOL user, and
quietly sent the message on.  If the name at AOL had been correct, I would
have not known about the misdirection at all.

The risks are obvious - instead of a somewhat trivial and incomprehensible
internal message, the message could have been highly confidential or time
critical.  The solution is trivial as well - check all mail lists for
conflicts (or at least have that as the default configuration & easily
selectable).


Re: Notes on e-mail: Use diaeresis (Sandee, RISKS-18.01)

Tim Pierce <twpierce@midway.uchicago.edu>
Fri, 5 Apr 1996 19:09:29 GMT
>Usenet (at least NNTP) is generally 8-bit transparent, and any European
>soc.culture group will tell you that ISO 8859-1 usually works, ...

Though many machines on Usenet are eight-bit clean, NNTP is defined to be
seven-bit.  There's no guarantee that the use of raw characters in
ISO-Latin-1 will come out unharmed on the other end.

More risks: assuming that an action is advisable simply because it "usually
works."  This, unfortunately, is becoming more and more common even among
news software developers, some of whom have simply conceded the seven-bit
encoding battle and now write for an eight-bit net.


Re: Notes on e-mail: Use diaeresis (Sandee, RISKS-18.01)

Otto Stolz <Otto.Stolz@uni-konstanz.de>
Tue, 9 Apr 1996 10:39:53 -0500
On 2 Apr 1996 16:20:16 GMT, sandee@Think.COM (Daan Sandee) said:
> [...] "co=F6perate", "na=EFf", and "Bront=EB.".  [...] It was already
> mangled in the RISKS posting

Apparently, these examples were sent to RISKS encoded as "quoted-printable".
I guess, they were contained in an e-mail item adorned with the appropriate
MIME headers to announce that transfer encoding to any interested parties.
However, in the process of digesting, all header fields (except the From,
To, and Subject fields) were stripped off.

This seems to be a general problem with contemporary mail-digesting software.
Of course, the transfer-encoding has to be undone before you can safely
remove the pertinent header field. I hope, our moderator will be able to find
a mail-digesting program that handles MIME headers properly.

> [...] I wish people wouldn't assume that the way their machine handles
> non-ASCII characters is the same as everyone else's.

This is exactly the reason MIME was invented for.

> Usenet (at least NNTP) is generally 8-bit transparent, and any European
> soc.culture group will tell you that ISO 8859-1 usually works [...]

Not quite so! There are mail transfer agents, and perhaps other intermediate
software, that still will drop the most significant bit of every 8-bit
character.

> This post of mine, however, goes out by e-mail (SMTP) and upper bits will
> be stripped [...]

Hence, contributions to RISKS, and other e-mail based services, must exploit
MIME to convey those characters (until, eventually,  the powers that be might
agree on a 8-bit, or even 16-bit, based mail protocol). It is the digester's
duty to undo any transfer-encoding before the mail is digested, and to encode
the whole digest for transport, as necessary.

> Well, I can handle diaereses all right, as long as they arrive in a form
> recognizable by my software.

And it will be the subscriber's duty to undo the transfer-encoding of the
whole digest.

        Otto Stolz

   [I have asked several folks what I would need to do to MIME-ify RISKS.
   I get responses that it is not that easy, or that it won't help
   those who don't deal with MIME, or that perhaps I should just
   wait until things settle down.  Meanwhile, we have a justification
   for indigestion with undigestification.   PGN]


CompuServe's "secure login protocol": two steps forward, one back

Heinz-Bernd Eggenstein <eggenste@noether.informatik.uni-dortmund.de>
Thu, 04 Apr 1996 19:34:12 +0200
Summary: a new CompuServe Information Service (CIS) logon protocol was
designed to prevent passive and active attacks (where the attacker
impersonates a CompuServe node) but a flawed implementation in the
WinCIM 2.0(.1) client software still allows active attacks.

Version 2.0 of the "WinCIM" access software introduced a new logon protocol.
Previous versions of the software had transmitted the user's UID AND his/her
password in plaintext during logon. The risks are obvious, especially when
connecting via the Internet to CompuServe (e.g. to save long distance
telephone charges).

The new, "secure logon protocol" is a challenge-response type protocol where
the "challenge" is to compute a keyed hash-function, the key is derived from
the shared secret, the user's password:

1) The client (WinCIM) generates a pseudorandom string of bits, its "nonce"
   (RB)
2) The client transmits the user's UID (e.g. 12345,6789) and the additional
   parameter "/secure:1" to request a secure login.
3) The host transmits its pseudo random nonce (RA) (The old protocol would
   instead prompt for the password)
4) client sends RB to the host
5) client computes  UR:=MD5(S|Z|RA|RB|S) and sends it to the host
   (where S (128 bits) is a function of the password, "|" stands for
   concatenation, Z is a 128bits block of 0s and MD5 is the well
   known message digest function.)
6) The host performs the same calculation with it's copy of the user's
   password. If the results match, the host sends HR:=MD5(S|Z|RB|RA|S)
   (Note the symmetry in the calculation of HR and UR)
7) The client software verifies HR with it's copy of the password to
   make sure the host is really a CIS node (!)

(See the script-files cserve.scr and seclog.scr in the subdirectory SCRIPTS
of a WINCIM 2.0(.1) installation, WinCim is available via anon. ftp
at ftp.compuserve.com).

Weaknesses:

a) The scriptfile cserve.scr (versions 3.8 & 3.8.1) has the following bug:
   even after requesting a secure logon, the client software will fall back
   into the old protocol when receiving a "Password" prompt (Client: "I want
   a secure logon" Host:"OK, but anyway, give me your password" Client "Well
   ok then, here it is ..."). It will send the password in plaintext! This
   makes the protection against active attacks (see step 7) obsolete.

b) A timeout condition or even an invalid HR response form the host will
   (seclog.scr & cserve.scr version 3.8.1) restart the protocol (it won't
   disconnect!), using *the same* client-nonce RB again, instead of
   generating a new one. If a spoofing host can predict RB as in this
   situation, it can pick the same nonce, leading to HR=UR=MD5(S|Z|RB|RB|S),
   so the host can just send back UR as HR.

Note that unlike a), b) does not compromise the user's password.

There may be other ways to predict the client software's nonce e.g. *if* the
PRNG used by WinCIM is predictable (this calls for further investigation).

Note that *offline* dictionary attacks to guess the password are possible
after a passive, eavesdropping attack (so you still have to pick a "good"
password). It's debatable whether CIS's password recommendation
(<word>

IBMMAIL e-mail address woes

Erik Naggum <erik@naggum.no>
03 Apr 1996 13:11:21 UT
You may not know the IBMMAIL system.  Internet addresses are translated to a
seven-digit number, which users use instead of real addresses.  It so
happens that I once ran a large mailing list and needed to track down which
messages were not delivered to which people, and so generated a unique
Return-Path for each message.  This caused a large number of IBMMAIL numbers
to be assigned to such addresses.  About once a month, I receive
confirmations of business transactions between Hong Kong and Singapore
companies to one of these addresses.  Clearly, the RISK is that humans
mistype numbers all the time, and when the addresses in a given range are
all valid, will send mail to the wrong recipient every now and then, just as
people misdial telephone numbers.

All information expressed in long numbers whose accuracy matter to either
party include redundant digits to reduce the number of valid numbers and to
provide consistency checks.  The same should be true of IBMMAIL numbers.
(Indeed, it should perhaps be true of domain names and usernames, too.)

#<Erik>


Re: X-Confirm-Reading-To: Pegasus woes on mailing lists...

Peter Yamamoto <pjyamamo@daisy.uwaterloo.ca>
Thu, 4 Apr 1996 10:42:36 -0500 (EST)
> Recently, on a mailing list I maintain, a Pegasus (the name of a
> Mac/Windows e-mail reader) user posted a message with a line:
>
> > X-Confirm-Reading-To: 

The risks of .forward

<cpbeaure@undergrad.math.uwaterloo.ca>
Tue, 2 Apr 1996 11:12:20 -0500 (EST)
Standard procedure for us net types is to leave .forward files when we
change accounts.  This is what I did when I left my previous employer.

Because of the nature of the Internet firewall we had there, to access the
net users had to actually log into the firewall machine - a bad idea in
itself, but it gets worse.

One fine day, I logged in to find a message informing me that the
firewall password had changed.  Conveniently, the message also included
the new password.  It seems that when I left, not only had they not
erased the .forward file, but they hadn't removed me from the system
alias file.

The risks?

1) Clean up after your old employees.
2) E-mail goes everywhere.
3) Don't e-mail passwords.  Ever.


Re: Wrong approach to Java security (Stuart, RISKS-18.01)

Andrew Berman <aberman@cs.washington.edu>
Fri, 05 Apr 1996 16:59:49 PST
>In RISKS-17.95, Jacob Palme suggests that the reputation of "well-kept
>depositories" and PICS-like ratings can be used to guard against malicious
>Java code.  A more useful idea along the same lines is to allow for code to
>carry a digital signature.  ...

Neither PICS-like ratings nor Digital Signatures is going to solve the
problem.  Yes, they might constrain some malicious users.  But what about
the data loss from buggy software?  Also, decentralization of code is a
promise of web-based languages.  A world in which every piece of code has to
be checked against a database of signatures is a much less flexible world
than one in which code runs in a "safe" environment.

Not to mention that a digital signature for a company will undoubtedly be
known by more people than a digital signature for a single user.  Thus,
the opportunities for theft of the signature would increase dramatically.

Andrew P. Berman  Dept. Of Computer Science, University Of Washington
aberman@cs.washington.edu|  http://www.cs.washington.edu/homes/aberman


Re: Risks of rewritable BIOSes (Epstein, RISKS-8.01)

JEREMY J EPSTEIN <JEPSTEIN@mail.cordant.com>
Tue, 09 Apr 1996 09:58:42 -0500
After my posting in RISKS-18.01, several people sent me e-mail.  A few
clarifications to my original note:

* Some PC vendors have a jumper that disables writing the flash.  In my
experience, this is unusual, although it's clearly present in some cases.
For those who are lucky enough, the jumper is even documented.  Clearly this
is a good solution for those whose PCs have the option.  Of course most
users won't read the manual that comes with the PC and thus won't realize
that there's a risk, much less understand how to thwart it.  [Pointed out by
mark@leasion.demon.co.uk (Mark Evans) and
afelson@milton.ecte.uswc.uswest.com (Adam Felson).]
    [AND also by "Nicholas C. Weaver" <nweaver@CS.Berkeley.EDU>,
    with the default being disabled -- see the next item.  PGN]

* I wrote "...each vendor has solved the problem differently..."  The word
"vendor" should be understood as the vendor of the motherboard, which may
not be the same as the PC vendor.  That is, a brand X PC may use a brand Y
or brand Z motherboard.  So looking at the outside of the case may be
insufficient to determine whether the PC is "safe".  [Pointed out by Mark
Evans.]

* As an aside I wrote that the risk would be eliminated if people used more
modern systems such as UNIX, OS/2, or NT.  As pointed out by Benedikt
Stockebrand (benedikt@devnull.ruhr.de), it doesn't *eliminate* the risk,
because there may be bugs that allow subverting the system and thus gaining
access to the flash RAM.  Stockebrand also pointed out that (on UNIX
systems) if you can get the virus/trojan run by root, then all bets are off.
Perhaps I should have said that running a more modern system *reduces* the
risk, since a virus/trojan would have to be a lot smarter than in a
DOS/Windows environment.

The above not withstanding, the point stands: most Pentium-based PCs are
extremely vulnerable to flash-based attacks.


Re: Risks of rewritable BIOSes (Epstein, RISKS-17.81)

"Nicholas C. Weaver" <nweaver@CS.Berkeley.EDU>
Fri, 5 Apr 1996 10:52:40 -0800
Although I believe software solutions are necessary for correcting the
flash-BIOS problem on existing motherboards, I think all future motherboards
should just resort to an old-fashioned physical jumper.  If the jumper is in
place, then the BIOS is reprogrammable.  (If a malicious person has access
to your motherboard, he/she can do a LOT more damage then simply reflashing
the BIOS, but a malicious program can't -- especially if the motherboard is
shipped without the jumper in-place.)


Re: Computers, Freedom and Privacy '96 (RISKS-18.01)

"Shabbir J. Safdar" <shabbir@panix.com>
Sat, 6 Apr 1996 15:59:55 -0500 (EST)
My RISKS commentary about the Bruce Sterling piece at CFP '96 drew
many pieces of e-mail.  You can get a RealAudio recording of it from
  URL:http://www.w3.org/pub/WWW/CFP4/live.ram
(I don't have a RealAudio player on this machine, so I cannot verify
that it works..)

The live version left me feeling numb and panicky.

   [oram@unixg.ubc.ca (John Oram) reported that the audio version
   of the entire CFP 96 is available for your listening pleasure
   "(in the bandwidth-conserving RealAudio format)" at:
     http://swissnet.ai.mit.edu/~switz/cfp96/ .]

Please report problems with the web pages to the maintainer

Top