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 19 Issue 48

Friday 5 December 1997

Contents

o Risks in a public database
David Lesher
o Risks of bundling in Microsoft Internet Explorer
Bear Giles
o Point-of-sale data diddling in Quebec
Mich Kabay
o Lufthansa combats mobile phone Risk
Jim Griffith
o GSM hack -- operator flunks the challenge
Ross Anderson
o Bug threatens Net software: land.c
Stevan Milunovic
o Kuji Walks
David Kennedy
o Date-based random numbers and Y2K
Alan Hamilton
o Re: Y2K and canned-goods expiration dates
Mark Brader
o Ontario removes privacy controls on education
David Collier-Brown
o Re: SET security
Jerome Svigals
o nando.net shut down by custodian
Jitendra Padhye
o Damage from powerline surges
David R Brooks
o Web cache risks
Bjorn Borud
o Perils of grammar checkers redux
Azeem Azhar
o URL for paper on European encryption policy
Mike Ellims
o Info on RISKS (comp.risks)

Risks in a public database

David Lesher <wb8foz@nrk.com>
Thu, 4 Dec 1997 17:43:24 -0500 (EST)
At least a hundred criminal defense lawyers across Maryland are legally
soliciting new clients by notifying people wanted by the police, sometimes
tipping off suspects before officers have had a chance to arrest them.  In
Maryland, arrest warrants are public records when issued.  The lawyers pay
LETS Co. in Edgewater MD to search those records, generating mailing lists,
and sending letters to the defendants.  In some cases, suspects have been
tipped off before they could be arrested.  [Source: Philip P. Pan and
Katherine Shaver, Lawyers' Solicitations Tipping Off Suspects, *The
Washington Post*, 4 Dec 1997, Page A01, PGN Abstracting]
[http://www.washingtonpost.com/wp-srv/WPlate/1997-12/04/178l-120497-idx.html]

  The RISK? Public data being used by the public?  [DL]


Risks of bundling in Microsoft Internet Explorer

Bear Giles <bear@coyotesong.com>
Fri, 5 Dec 1997 14:10:13 -0700 (MST)
The online press has been reporting an unexpected risk of bundled MS
Internet Explorer.  Some programs automatically install MS IE 3.0 during
installation -- and a few don't provide a way for the user to prevent this
installation.  If MS IE 4.0 is already installed, the resulting mess leaves
neither 3.0 nor 4.0 in a runnable state.

I've also heard rumors that installing (at least one version of) MS IE will
remove competing browsers from the registry.  This is easier to fix than
mismatched MSIE DLLs, but few people would understand why installing one
program (e.g., Quicken was listed) would result in their preferred browser
becoming unusable or deregistered.

Finally, such bundling disregards the fact that some of us actually prefer
the earlier releases of the browers.  My copy of Netscape (2.02) may not
have all of the latest bells & whistles, but on the other hand it doesn't
have all of the latest bells & whistles.  If it meets my needs, why would I
want to load a larger, slower program which includes "features" I'll never
use, such as "push channels."

Bear Giles  bear@coyotesong.com


Point-of-sale data diddling in Quebec

"Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com>
Fri, 5 Dec 1997 09:03:51 -0500
Some Quebec restaurateurs have been using a U.S.-made computer program (a
"zapper") that skimmed off up to 30% of the receipts, thereby evading
Revenue Canada and provincial government tax payments (millions of dollars
estimated for the latter).  [Source: Timothy Appleby, Rhe'al Se'guin and
Geoffrey Rowan, Restaurants' tax-evasion scam pursued: System found in
Quebec may be used elsewhere, Revenue Canada says, *The Globe and Mail*, 05
Dec 1997, p. A:1.  PGN Abstracting]

A related story in the *Montreal Gazette* added that *Le Point* journalists
succeeded in getting technical support on the zapper programs from POS
equipment vendors; there seemed to be nothing unusual about the programs,
judging from the matter-of-fact way the vendors responded to requests.

M. E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA)  <http://www.ncsa.com>
(will be *International* Computer Security Association as of 1 Jan 1998)


Lufthansa combats mobile phone Risk

Jim Griffith <griffith@netcom.com>
Wed, 3 Dec 1997 15:39:13 -0800 (PST)
A Reuters article today describes a new effort by Lufthansa to identify
dangerous in-flight use of mobile telephones.  They are testing a hand-held
passive sensing device which detects mobile phone signals and helps the
operator locate the offender.  The article goes on to mention that beyond
the safety factor, using mobile phones in flight is illegal in Germany
(along with use of CD players or laptops with CD-ROM drives or printers).

What actually drew my attention to the article was its poorly-chosen title
-- "Lufthansa to snoop on airborne phone users".  The device is clearly
neither able nor intended to "snoop".  Considering the idiocy of using a
device that can directly cause the death of you and several hundred people
around you, it occurs to me that the detector can double as an in-flight IQ
test...

Jim


GSM hack -- operator flunks the challenge

Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
Wed, 26 Nov 1997 17:36:36 +0000
On Friday 13th September 1996, I read in comp.risks that:

> MobilCom, a subsidiary of German TeleKom (since 100 years monopolist on
> telephone communication in Germany, with its monopoly ending in 1998)
> publicly offers 100,000 DM to a telephone hacker who is able to communicate
> at the expense of the (national) number 0171-3289966. The related chipcard
> is said to be safely stored in lawyer`s office. In an attempt to paint this
> dubious offer somewhat "politically correct", the successful hacker will
> have to donate his earnings to a social institution of his(her) choice.

This caught our attention - Cambridge University, being a registered
charity, surely qualifies as a `social institution', and 100,000 DM would
buy us a state-of-the-art triple-wavelength laser microprobe workstation for
chipcard breaking. So we had a look at GSM and found a way to hack it. We
worked out what equipment we'd need and where we could borrow it, assembled
the team, checked that the attack would work in principle, and then started
trying to find the right person in Deutsche Telekom to speak to. We needed
to know the IMSI (international mobile subscriber identification) and get
written confirmation of the challenge; otherwise the attack might have been
interpreted as an offence under Britain's Wireless Telegraphy Act.

After some chasing around, unanswered e-mails and so on, we went to a mobile
phone fraud conference in June and made contacts there which suggested some
names, leading to further unanswered correspondence, and finally a faxed
reply.  Here is a translation of the original German, online at
<http://www.cl.cam.ac.uk/ftp/users/rja14/roesner.gif>:

   Dear Dr Anderson

   Many thanks for your fax of the 6th October 1997. Please
   excuse the late reply to your fax.  The matter that you mentioned did not
   originate from T-Mobil but from one of our service providers, the firm
   Mobilcom in Schleswig.  We understand that the offer has since also been
   withdrawn by them.  Yours etc.

How does our attack work? Well, when a GSM phone is turned on, its identity
(the IMSI) is relayed to the authentication centre of the company that
issued it, and this centre sends back to the base station a set of five
`triples'. Each triple consists of a random challenge, a response that the
handset must return to authenticate itself, and a content key for encrypting
subsequent traffic between the mobile and the base station. The base station
then relays the random challenge to the handset. The SIMcard which
personalises the handset holds a secret issued by the authentication centre,
and it computes both the response and the content key from the random
challenge using this secret.

The vulnerability we planned to exploit is that, although there is provision
in the standard for encrypting the traffic between the base station and the
authentication centre, in practice operators leave the transmissions in
clear. This is supposedly `for simplicity' (but see below).

To break GSM, we transmit the target IMSI from a handset and intercept the
five triples as they come back on the microwave link to the base
station. Now we can give the correct response to the authentication
challenge, and encrypt the traffic with the correct key. We can do this
online with a smartcard emulator hooked up through a PC to a microwave
protocol analyser; in a less sophisticated implementation, you could load
the handset offline with the responses and content keys corresponding to
challenges 2 through 5 which will be used on the next four occasions that
you call.

The necessary microwave test set costs about $20,000 to buy, but could be
home built: it's more than an undergraduate project but much less than a
PhD, and any 23cm radio ham should be able to put one together.  We would
have borrowed this, and reckoned on at most 3 person months for SIM-handset
protocol implementation, system integration, debugging and operational
testing.

Given such an apparatus, you can charge calls to essentially any GSM phone
whose IMSI you know. IMSIs can be harvested by eavesdropping, both passive
and active; `IMSI-catchers' are commercially available.

The fix for our attack is to turn on traffic encryption between the GSM base
stations. But that will not be politically acceptable, since the spooks
listen to GSM traffic by monitoring the microwave links between base
stations: these links contain not only clear keys but also clear telephony
traffic. Such monitoring was reported in the UK press last year, and now the
necessary equipment is advertised openly on the net. See for example
<http://www.gcomtech.com/>.

The RISK for intelligence agencies? Making systems like GSM give government
access to keys can have horrendous side effects (especially where this
access is via channels that aren't properly documented and evaluated). These
side effects can get you into serious conflict with powerful commercial
interests.

The RISKS for phone companies? Firstly, letting spook agencies bully you
into a bad security design with the assurance that it will only compromise
your customers' privacy, has as a likely side-effect the compromise of your
signalling and thus your revenue. (David Wagner, Bruce Schneier and John
Kelsey made this point for the US cellular system: see
<http://www.counterpane.com/cmea.html>.)

Secondly, most phone companies have no crypto expertise. Their security
managers are largely ex-policemen or accountants, and so are unable to
evaluate the security claims made by equipment manufacturers and
intelligence agency representatives.

Thirdly, by restricting parts of the security specification to people who
signed a non-disclosure agreement, the GSM consortium deprived itself of the
benefit of open scrutiny by the research community.  It is this scrutiny
that has led to protocols such as SSL and SET having their holes found and
fixed. However, the global deployment of GSM ensured that many people would
be cleared to know the design, most of which can be got anyway by observing
traffic or by reverse engineering unprotected equipment. So public scrutiny
was inevitable - but only after billions of dollars' worth of equipment had
been deployed and the system could not changed. So the GSM
security-by-obscurity strategy gave them the worst of all possible
worlds. The consumer electronics industry should take note.

The specific RISK for Deutsche Telekom: responding to cynicism about GSM
security claims by putting up a reckless challenge and thus motivating an
attack.

The RISK for GSM users: that crooks running a call-sell operation will book
a very expensive phone call on your account. An established modus operandi
is to set up a conference call which their clients and counterparties join
in succession. As the bill isn't forwarded to the service provider until the
phone goes on-hook, you can end up with a five-figure bill for a call that
lasted several days and involved hundreds of overseas telephone
numbers. Some GSM operators (such as Vodafone) limit this exposure by
terminating all calls after six hours; but your IMSI can be used on a
network that doesn't do this.

And of course, as with `phantom withdrawals' from cash machines, the use of
cryptography will `prove' that you're liable for the bill.

Ross Anderson, Cambridge University Computer Laboratory
<www.cl.cam.ac.uk/users/rja14>

Acknowledgement: our research students Stefan Hild, Abida Khattak, Markus
Kuhn and Frank Stajano contributed in various ways to researching and
planning this attack. An academic paper on the subject will appear in due
course.


Bug threatens Net software: land.c

Stevan Milunovic <stevan@netscape.com>
Fri, 05 Dec 1997 09:10:05 -0800
Somebody has released a program, known as land.c or Land Attack, which can
be used to launch denial of service attacks against various TCP
implementations.  The program sends a TCP SYN packet (a connection
initiation), giving the target host's address as both source and
destination, and using the same port on the target host as both source and
destination.  Vulnerable systems include Windows NT, some versions of SunOs,
Cisco routers and Catalyst software.  [Source: Bug threatens Net software,
4 Dec 1997 http://www.news.com/News/Item/0%2C4%2C17009%2C00.html?ndh.idirect]


Kuji Walks

David Kennedy <76702.3557@compuserve.com>
Wed, 26 Nov 1997 02:38:10 -0500
Matthew Bevan (a.k.a. Kuji), now 23, has been cleared in court, when three
charges of "unauthorised access and modification" (into systems at Griffiss
Air Force base and Lockheed Space and Missile Company in California) were
dropped.  He had been allegedly involved with Richard Pryce (a.k.a.
Datastream Cowboy, breaking into NASA, USAF, and USArmy systems; see
RISKS-18.15), who was fined 1,200 British pounds earlier this year.
[Source: Lucie Morris, Security Risk Claim Computer Ace Cleared, *PA News*,
21 Nov 1997; PGN Abstracting]

[DMK: Two of the best publications regarding the Rome Air Force Base
hack-ins are the GAO Report available online through
http://www.gao.gov/reports.htm under title [AIMD-96-92] Information
Security: Computer Attacks at Department of Defense Pose Increasing Risks
and the Fall 96 Computer Security Institute's journal, both articles written
in whole or in part by Jim Christy, the Air Force investigator involved.
  Mixed messages.  Is the interpretation to be, if you hack, you'll get off?
Or if you hack some other country's computers, you won't be prosecuted
because it costs too much?  Of if your partner in crime gets off with just a
fine, prosecutors won't spend a lot of money going after you?
  So Bevan *may* have hacked into computers worldwide.  But he has no
convictions.  How long until he's peddling his skills as a computer security
expert, or even on a "Tiger Team" or penetration testing group?]

Dave Kennedy [CISSP] Director of Research, National Computer Security Assoc.


Date-based random numbers and Y2K

Alan Hamilton <alanh@primenet.com>
1 Dec 1997 13:05:02 -0700
I had a friend report to me a problem with the game Freecell on his PC.
Ordinarily, Freecell starts a different numbered game each time a new game
is started.  However, his copy was stuck on #3389.

It turns out that his system date had been accidentally changed to 2097
rather than 1997.  Correcting the date fixed the problem.

This made me think about how many programs use time/date-based random
number generators.  You would not expect Freecell to have a date-based bug,
but it does.  I suspect there are a lot of other programs with the same
bug.  Although they may not necessarily fail at 1/1/2000, they may fail at
some other point.  (Where a computed value exceeds 16 bits, for instance.)

There are a lot of programs that obviously use dates, but I'm afraid we're
going to find a lot of others that seemingly don't fail due to date-based
problems too.

Alan Hamilton <alanh@primenet.com>


Re: Y2K and canned-goods expiration dates (Pereira, Risks-19.47)

<msb@sq.com>
Wed, 26 Nov 97 23:37:21 EST
There is, of course, a different and much simpler Y2K problem that also
affects expiry dates, though it's unlikely to pertain to canned goods.
If you see an expiry date of APR01, say, then it's useless unless you
correctly understand whether the product is one likely to last for
several years or not.  Otherwise -- well, is that next (or perhaps
*last*) April 1, or is it April of 2001?

(People who would write the former as "01 APR" are probably laughing at
this point, but they need only think about the confusions when April
is converted to 04 instead, and a common standard is not followed...)

I've been pleased to see a number of long-lived products these days using
4-digit years in their expiry dates, but as Fernando's story shows, there
are still plenty that don't.

Mark Brader, Toronto, msb@sq.com

[For Your Amusement: I initially wrote the item using February as the
example month, and then did a substitution to a more foolish example.  I
missed one instance at first, and nearly sent off the message with a
reference to April being converted to 02...]


Ontario removes privacy controls on education

David Collier-Brown <davecb@Canada.Sun.COM>
Mon, 01 Dec 1997 13:38:33 -0500
In a(n otherwise somewhat contentious) bill, the Government of Ontario has
removed the ``personal information'' of students from the control of the
Protection of Privacy acts.  Later in the bill, it deems disclosure by
institutions to automagically ` `be for the purposes of complying with this
act''.

This would be merely annoying, until one finds out the definition of
``personal information''.  This happens to include things such s sexual
orientation and political beliefs.

  Further comment withheld to avoid intemperate remarks (:-))

David Collier-Brown, 185 Ellerslie Ave., Willowdale, Ontario CANADA M2N 1Y3
davecb@hobbes.ss.org, 416-223-8968 http://java.science.yorku.ca/~davecb


Re: SET security (RISKS-19.31-36)

<smartcard@sprynet.com>
Tue, 25 Nov 1997 17:42:54 -0800
InternetWeek Newsletter - Nov. 25   (Copyrighted CMP Media Inc).

Mr Matthew Friedman of the InternetWeek Newsletter offers the following
report on the SET specifications progress:

        After six months there is not one operational deployment.

        Merchants and banks report a serious flaw - set compliance
        does not guarantee cross vendor compatibility.

        set is reported as too complex to integrate cleanly with existing
        legacy transaction systems.

        Two implementers (HP/Verifone and IBM) have provided their own set
        1.0 program to assure interoperability.  Set was supposed to be
        interoperable.

        set 0.0 use has been extended three months to avoid a christmas
        season work conflict in migrating to set 1.0.

        Set providers acknowledge its three tiered architecture is complex.
        These are the client wallet, the merchant server and the banks
        gateway.  These use software from multiple vendors. The set process
        will be dependent on millions of certificates from merchants and
        consumers.

        The bank industry must resolve the operational issues to tie together
        the specs, the system components, software, the actions of many
        people (users, merchants, bankers), card acceptor units and
        issuing/using millions of certificates.

jerome svigals, smartcard@sprynet.com


nando.net shut down by custodian

Jitendra Padhye <jitu@cs.umass.edu>
Fri, 21 Nov 1997 10:08:52 -0500
The Nando.net site was out of service for about three hours on 20 Nov 1997
because of a power outage.  During routine custodial service, a vacuum
cleaner caused an electrical overload in the room that houses Nando.net's
main servers, which cut power to the main data servers, which in turn caused
them to crash, requiring 2.5 hours to repair.  [Seen on the *News and
Observer Times* Web site by Jitu <jitu@cs.umass.edu>.]  Seth Effron, Exec.
Editor, Nando.net, 21 Nov 1997, http://www.nando.net.  PGN Abstracting.]


Damage from powerline surges

David R Brooks <daveb@iinet.net.au>
Tue, 25 Nov 1997 18:40:56 +0800
[While this doesn't strictly involve computers, it certainly shows what a
bad power surge can do.  Dave Brooks <http://www.iinet.net.au/~daveb>]

A three-hour crisis at Broken Hill Proprietary Ltd. (Australia's biggest
steel producer) resulted from a power surge that ignited the plant's
high-voltage transformer, causing a series of fires and evacuation of all
3,500 workers.  The general consensus is that the consequences could have
been much worse.  [Source: Richard Macey and Helen Trinca, Steelworks fire
emergency blamed on power surge, *Sydney Morning Herald*, 25 Nov 1997, PGN
Abstracting]


Web cache risks

Bjorn Borud <borud@guardian.no>
27 Nov 1997 18:22:33 +0100
Picture this: you are standing in front of a classroom full of students
(most of them female I might add).  You are going to teach the students how
to use a service that lets you perform searches a huge library database
containing alle the books in Norwegian college libraries.  Your PC is hooked
up with a video canon that projects a LARGE image of what's on your screen
on the wall.

You bring up the web page of the service you are about to demonstrate.  The
page loads, the graphics for the various buttons in the interface is
loading...but something is wrong.  One of the buttons is not a button at
all.  It's a large, particularly nasty, pornographic image which was
definitely NOT put there by the providers said service.

This happened earlier this week at a Norwegian college where a friend
of mine works as a system administrator.

Now, how did this happen?

Well, like every responsible institution on the net they have a local web
cache in order to speed things up and save bandwidth.  this cache sometimes
forwards request to yet another cache, and it was this cache that caused the
embarrassing incident.

It turns out the second cache was out of disk space and somehow this
messed up the mappings between URLs and the actual images stored in
the disk cache, so every now and then the cache would serve the wrong
file from the cache.  several people could confirm this behaviour.

 Bjørn Borud <borud@guardian.no>  Guardian Networks AS
 http://www.pvv.org/~borud/   http://www.guardian.no/


Perils of grammar checkers redux

"Azeem Azhar" <az!nospam!@nospamxx!nospam!nospam.int>
28 Nov 1997 10:20:54 GMT
Several people asked what the sentence I referred to in RISKS-19.47 was.  It
was (without the quotes) "However, as this flexibility applies only to the
time at which we will seek payment and not to the liability for payment, we
will not be issuing a credit note. " [I've run it through my version of Word
97 SR-1, standard grammar checker, and it certainly works.]

Azeem BBC  [Back reference corrected in Archive copy]


URL for paper on European encryption policy (Ellims, RISKS-19.47)

Mike Ellims <mike.ellims@pigroup.co.uk>
Thu, 27 Nov 1997 09:36:37 -0000
Looks like "the cat" has struck again. It seems that the URL I gave for the
EC report on the use of encryption was incorrect.  The full title of the
report (from it's web title page) is as follows,

    Towards A European Framework for Digital Signatures And Encryption

    Communication from the Commission to the European Parliament, the
    Council, the Economic and Social Committee and the Committee of
    the Regions ensuring Security and Trust in Electronic
    Communication (Adopted by the Commission on 8 October 1997)

Title page at http://www.ispo.cec.be/eif/policy , content at
http://www.ispo.cec.be/eif/policy/97503.html .

The following address also works:
http://194.119.255.200/eif/policy/97503.html

I have checked out these address and they appear to work. I've checked the
spelling but this doesn't mean anything as it's a MS spell check
program. I'd also like to thank the people who pointed the correction.

None of the above reflect the views of my employer or my cat. The cat is
hiding from embarrassment.

Mike Ellims  -  Pi Technology  -  mike@pires.co.uk  -  +44 (0)1223 441 256

  [Also noted by Lindsay F. Marshall, Jim Horning, Sander Tekelenburg.  PGN]

Please report problems with the web pages to the maintainer

Top