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 20 Issue 97

Thursday 27 July 2000

Contents

o House hearing on FBI's "Carnivore"
Alan Davidson
o Fake Paypal site collects user ids and passwords
Avi Rubin
o Followup on cause of SeaLaunch rocket failure
Kenneth Basye
o Outlook bug allows self-executing Trojan horses
Kevin Poulsen
o Powergen: More credit-card info exposed
Ursula Martin
o Civilian payroll problem
Stan Niles
o The Least Mail Online
Rob Slade
o AT&T exposes account info
John Chapin
o Re: Sliced fiber-optic cable ...
Mark Richards
o Re: London Underground magnetic ticket bug
Clive D.W. Feather
o Trust and Risk in Internet Commerce, Jean Camp
PGN
o 9th USENIX Security Conference 2000
Hali McGrath
o Info on RISKS (comp.risks)

House hearing on FBI's "Carnivore"

Alan Davidson <abd@cdt.org>
Wed, 26 Jul 2000 23:04:40 -0400
  [Written by Lina Tilman <ltilman@cdtmail.org>]

Oversight Hearing on Fourth Amendment Issues
Raised by FBI's "Carnivore" Program
Subcommittee on the Constitution, House Committee on the Judiciary
Monday, July 24, 2000, 1:00 p.m.

Chairman Canady opened the hearing by introducing the Carnivore system as
one that "isolates, intercepts and collects" information that passes through
an ISP. Canady expressed hope that evaluations of the system would be based
on facts instead of "irrational fears and suspicions". Canady concluded by
acknowledging the potential for abuse of the system as a significant
concern.

Rep. Watt briefly addressed his concern regarding Big Brother in general and
the government's ability to invade citizens' privacy in particular. Watt
acknowledged that such ability has been enhanced by advancements in
information and communication technologies.

Rep. Hyde first noted the legitimate need of the law enforcement to access
information required for criminal investigations. Hyde then described the
tension between such necessary access and the citizens' right to the
"valuable commodity" of privacy.

Rep. Conyers introduced a number of questions as part of his inquiry into
Carnivore's ability to "bite more than it can chew". Conyers first noted his
concern regarding the applicability of the pen register authority, under
which Carnivore collects transactional electronic data, to the online
environment. Conyers' other concerns included the FBI's refusal to allow
ISPs themselves to deliver the necessary information once a lawful order is
obtained.

Rep. Hutchinson stated that while Carnivore appeared to be a minimization
tool, there exist legitimate questions regarding its application. Concerns
include proper monitoring of Carnivore's collection and filtering of e-mail
communication. Hutchinson mentioned the Privacy Commission bill, which he
co-sponsors with Rep.  Moran, as an attempt to establish a body of experts
who would, among other things, examine the data collection practices of law
enforcement to determine whether they violate the privacy rights of the
U.S. citizens.

Rep. Bachus stated that in Carnivore's case, technology appears to have
"outrun the law". Bachus expressed his suspicion that criminals would easily
evade the system and it would exclusively monitor the communications of law
abiding citizens. Bachus further expressed his concern regarding
illegitimate access to confidential files within agencies such as the FBI.

The  first panel  consisted  of Dr.  Donald  Kerr, FBI  lab director,  Larry
Parkinson, FBI General Counsel, Kevin DiGregory, DOJ and David Green, DOJ.

Dr. Kerr introduced FBI's Carnivore as a tool, analogous to a "packet
sniffer", of lawful interception of criminal communication. After being
installed on a network pursuant to a court order, Carnivore collects the
transactional information of its targets' e-mails; its configuration and
filter settings depend on the specifics of the court order. Carnivore
conducts neither broad searches nor long-term surveillance; instead, it
filters out all content information and stores only the non-content "to" and
"from" lines of targeted communication. Carnivore is passive on the network
and is used only by a technical team of the law enforcement; in its two
years of existence, it has been used very infrequently and
narrowly. Dr. Kerr concluded by stating that the FBI presently plans an
independent review of the system by industry and academic experts.

Mr. Parkinson testified that Carnivore is a minimization tool that operates
under substantial oversight. Mr. DiGregory, in turn, argued that Carnivore
is equivalent to other simple investigative tools that law enforcement uses
offline.

Chairman Canady asked whether Carnivore captures the URLs of communications
with Web sites. The panelists answered that it does not, unless a URL is
included in the transactional information of an e-mail. Rep. Watt appeared
upset that independent review was scheduled after Carnivore has been in use
for two years. A number of Members expressed distrust regarding the law
enforcement's use of Carnivore under described limitations. Rep. Hutchinson
asked whether the FBI has ever captured content that it then had to filter
out. The panelists answered that it has not. Panelists noted that in
addition to restrictions and specifications that limit data collection prior
to Carnivore's activation, there exist safeguards on law enforcement's use
of collected data when it is first examined and, later, at trial.

The second panel consisted of Barry Steinhardt, ACLU, Alan Davidson, CDT,
Tom Perrine, Pacific Institute for Computer Security, Robert Corn-Revere,
Hogan & Hartson, Matt Blaze, AT&T Labs, Stewart Baker, Steptoe & Johnson,
and William Sachs, ICONN.

Mr. Steinhardt stated that Carnivore is an unprecedented maximization tool
that has the potential to access all communications that pass through an
ISP. Mr. Steinhardt analogized Carnivore to a digital wiretap, expressing
concern that its broad access is inconsistent with restrictions set by the
Fourth Amendment and the ECPA. Mr.  Steinhardt noted that the FBI has a
"checkered past" with regards to First and Fourth Amendment violations.

Mr. Davidson addressed the differences between transactional data in the on-
and off-line environments, noting that off-line Fourth Amendment protections
do not neatly translate into online communications. Davidson showed a series
of slides that displayed sample packets that Carnivore could obtain; he
argued that "non-content" data that Carnivore currently accesses under a pen
register or trap and trace authorization reveal a great amount the actual
content of a target's communication. Davidson argued that Congress must
increase statutory protections for electronic communications, raising the
Carnivore authorization standard from relevant to probable cause.

Mr. Perrine noted that Carnivore is technically capable of monitoring all
traffic that passes through the network. Mr. Perrine spoke about the
inapplicability of telephony concepts to the online environment.  He stated
that the FBI's use of Carnivore lacks accountability, noting that it is
impossible to monitor the system or keep track of its configurations or
filters without the knowledge of its source code. Mr. Perrine argued that
Carnivore represents a threat to privacy that is protected under original
wiretap legislation.

Mr. Corn-Revere argued against a number of points brought up by government
witnesses on the first panel. Mr. Corn-Revere appeared skeptical that the
FBI would use Carnivore's capabilities in limited ways that protect
individuals' privacy. He noted disconcerting implications inherent in the
system's ability to switch its level of surveillance. In conclusion,
Mr. Corn-Revere stated that there presently exists no way to ensure
accountability of FBI's use of Carnivore.

Mr. Blaze argued that while the FBI operates with good intentions, it is
difficult to ensure that Carnivore operates as intended. The system may
inadequately filter, target the wrong individual or extract pieces of
communication out of context. Mr. Blaze noted that large-scale systems such
as Carnivore are problematic and tend to fail silently -- without operators'
knowledge -- due to bugs, vulnerabilities and mistakes. Mr. Blaze argued
that widespread publication of Carnivore's source code and architecture is
the best way to ensure its soundness.  [See
  http://www.crypto.com/papers/openwiretap.html; PGN]

Mr. Baker stated that communication concepts from the telephony world do not
apply to electronic communication. Mr. Baker argued that it is "crazy" and
"bizarre" not to acknowledge that there exists a reasonable expectation of
privacy in the content-revealing "to" and "from" lines of an e-mail. He
urged the Members to institute a notice requirement when a system such as
Carnivore monitors e-mail communications.

Mr. Sachs testified that ISPs are capable of providing the FBI with
requested communications when a lawful order exists. He noted that Carnivore
represents the most intrusive method of obtaining transactional data of
e-mail messages. Mr. Sachs acknowledged that albeit technically feasible,
such monitoring by an ISP discourages free online communication, protected
by the First Amendment, and slows down network traffic.

During the Q&A period, Davidson noted that little is known about Carnivore's
precise capabilities and functions. Rep. Watt expressed concern that
currently available Carnivore-like electronic surveillance systems allow
anyone to monitor online traffic.  Panelists noted that there exists an
a-priori legal issue with the FBI's installation of Carnivore -- in the
telephony world, the FBI would not be able to install, on a telephone
service provider's network, a device that would monitor all passing
communications.  Panelists and Members appeared to agree that there must
exist a notice requirement; presently, notice depends on the individual
ISPs' policies. Davidson argued that two things must occur: (1) the standard
for access to transactional data on the Internet must be raised, and (2)
"trap and trace" must be re-defined for the online environment. Mr. Perrine
noted that according to the Supreme Court, transactional data may not
disclose the target's identity. Mr.  Steinhardt observed that the FBI
witnesses addressed the use of Carnivore in the e-mail context only; it
remains unclear how the system monitors files transferred using other
protocols. Furthermore, it is unclear what statutory protections govern such
file transfers.  Mr. Steinhardt argued that the notion and significance of
non-content data has changed since CALEA was adopted, and urged the Members
to consider two changes to existing surveillance guidelines: (1) judges
should be given discretion in matters of online pen register and trap and
trace orders, and (2) the standard for obtaining a pen register and trap and
trace must be raised for both the online and the telephony environments.

Lina Tilman, Center for Democracy and Technology
1634 Eye St. NW Suite 1100, Washington, DC 20006
202 637 9800  fax 202 637 0968
ltilman@cdtmail.org  http://www.cdt.org/

  [From EPIC Alert 7.14, 27 Jul 2000, http://www.epic.org, I find
Testimony presented at the House Judiciary Committee hearing:
      http://www.house.gov/judiciary/2.htm
The hearing can be viewed in its entirety over the web at:
      http://www.cspan.org/technology_science/
More on the history of FBI monitoring of Internet communications and the
"digital telephony" law (or CALEA) is available at the EPIC Wiretap Page:
      http://www.epic.org/privacy/wiretap/
  PGN]


Fake Paypal site collects user ids and passwords

Avi Rubin <rubin@research.att.com>
Tue, 25 Jul 2000 15:23:18 GMT
Somebody in the Ukraine registered PayPaI.com (note the resemblance to
PayPal, especially with the upper-case I [in some fonts]), then copied
Paypal's HTML and sent mail to a bunch of paypal users saying 'J. Random has
just transferred $827 to you using PayPal, log in at http://www.paypaI.com/
to claim it!'  of course, as soon as you "logged in" your password was
mailed to some free e-mail service.  For more on the story see
http://www.msnbc.com/news/435937.asp?cp1=1 among other places.

Avi  http://avirubin.com/

  [Monty Solomon notes that Paypai.com is registered to Birykov Inc. in
  South Ural, Russia, according to MSNBC: http://www.msnbc.com/news/435937.asp
  PGN]


Followup on cause of SeaLaunch rocket failure (RISKS-20.84)

<Kenneth_Basye@dragonsys.com>
Thu, 27 Jul 2000 15:45:22 -0400
According to an article at space.com, the cause of the failure in March was
"a single line of code" which allowed the rocket to be launched with a valve
open in the second stage, setting the stage (sorry) for a helium leak.
SeaLaunch is preparing for another launch tomorrow (July 28th).
(http://www.space.com/missionlaunches/sea_launch_000714.html)

Ken Basye <kbasye@dragonsys.com>


Outlook bug allows self-executing Trojan horses

Kevin Poulsen <klp@well.com>
Wed, 19 Jul 2000 21:09:06 -0700 (PDT)
http://www.securityfocus.com/news/62

A newly discovered vulnerability in Microsoft's Outlook and Outlook Express
programs leave thousands of computers open to attack from malicious e-mail,
and puts the lie to the conventional wisdom that you can't get a computer
virus if you don't open attachments.

Microsoft issued an advisory on the bug Wednesday morning, after a
programmer announced it to the world over the Bugtraq mailing list Tuesday.
In the advisory, Microsoft says Outlook users can eliminate the
vulnerability by upgrading to Internet Explorer 5.01 Service Pack 1, or,
Explorer 5.5. Either upgrade will patch the hole on Windows 95, 98 or NT.
Windows 2000 users must install the Service Pack to close the hole.

The bug is a classic "buffer overflow" error in the section of Outlook that
parses the Date field of each incoming e-mail.  By padding the date with a
long string of characters, an attacker can escape from the area of memory
reserved for storing it, and into a section that executes instructions.
From there, the attacker's e-mail could secretly infect a victim computer
with a "back door" program like Back Orifice, or instruct it to send the
offending e-mail back out to the net like the LoveLetter virus.

The vulnerability doesn't require any attachment to the e-mail; Outlook users
need only read a message to be hit.  Outlook Express users are even more
vulnerable, and can fall prey to malicious code without reading the message,
or even being at their computer when it comes in.

"This has the potential to be the worst one we've seen yet," said Brian
Martin, a senior security engineer at Maryland-based Digital Systems
International Corporation.  "If this can execute as soon as the mail is
received, oh man, that's just perfect."

Based on a hurried analysis Tuesday night, Martin said that the bug could
likely be used to take control of vast numbers of machines at a time.  "What
if you had a mail list with thousands of people and you posted to that?,"
said Martin.  "One well-placed e-mail and you can probably infect thousands
of people with a Back Orifice or a NetBus."

Aaron Drew announced the bug to the Bugtraq mailing list on Tuesday, along
with code that ostensibly demonstrates the hole. MSNBC reported that the
hole was also discovered over a month ago by researchers at USSR Labs, which
also boasts working exploit code. Both the news service and the security
group kept it a secret while awaiting a Microsoft fix. The Microsoft
advisory credits USSR Labs for reporting the bug to them, "and working with
us to protect customers."

Outlook's vulnerability to running malicious code without any user
interaction raises the ominous threat that a virus writer might create a
fast spreading worm that would spread in the style of Melissa or last May's
"ILoveYou" virus, but without the need to trick people into running hostile
attachments. Experts fear that many users -- perhaps most -- will invariably
fail to close the hole and will thus remain open to attack.  "Nobody
downloads their security patches," said Dan Schrader, an anti-virus expert
at Trend Micro Tuesday. "Which is unfortunate, because it's relatively
simple to do."

Martin warned that attackers won't be losing interest. "Between [USSR
Labs] already having the code, and someone else posting follow up code to
a public source, there are probably a dozen people working on their own
version. And they're probably each figuring out the best ways to exploit
this."


Powergen: More credit-card info exposed

Ursula Martin <ursula@csl.sri.com>
Thu, 20 Jul 2000 21:03:48 -0700
The UK electricity utility Powergen advised all its online customers
to change credit-card numbers after details of 7000 customers were
mistakenly made available on the web in early July 2000.
[Source: http://www.guardianunlimited.co.uk/netprivacy/]


Civilian payroll problem

"Stan Niles" <sniles@arl.army.mil>
Mon, 24 Jul 2000 13:40:04 -0400
  ``Civilian Payroll Problem: A major systems problem with the Automated
  Time and Attendance Production System (ATAAPS) has resulted in a significant
  loss of Time and Attendance (T&A) Report data.  All transactions that were
  entered into ATAAPS between Saturday, 8 July 2000 and Tuesday, 18 July 2000
  have been lost and are not recoverable.  The lost transactions include
  leave, premium pay, tour of duty changes, default job order changes, and
  corrections that were made between those dates.''

I just got back from being away from work without checking in on my e-mail
for a whole week (yippee!).  This is what greeted me.  I don't really know
their process and I too busy digging out from the accumulated pile of mail
etc. to find out.  But ten days of lost payroll data? Haven't they ever
heard of "backups"?

Stan Niles  Army Research Lab  <sniles@arl.army.mil>


The Least Mail Online

Rob Slade <rslade@sprint.ca>
Fri, 21 Jul 2000 09:07:26 -0800
E-mail generally works so well that we have started to take its successful
operation for granted, forgetting that delivery is still not guaranteed.  As
a case in point, Sprint Canada's The Most Online service had one of its
regularly unscheduled outages last week, this time affecting incoming e-mail.
The timing was particularly unsettling to me, as a group of us were in the
final stages of negotiation with a publisher, and the discussions were being
conducted via e-mail.

From the date stamps on some late e-mail that is starting to dribble in, the
outage probably started late Wednesday night.  I didn't notice anything
until late Thursday, when I expected to download the usual 150 messages that
would have built up in the time I had been away from Net access.  Instead I
couldn't get anything.  Calling the Sprint support line got a recorded
announcement that "some subscribers may experience some problems in
obtaining incoming e-mail."  Friday a dribble of e-mail started to come
through, but the announcement persisted over the weekend.  Wednesday a fair
number of old messages started to come through, so it seems that some of the
backlog is starting to clear.

However, there is no indication that I am going to get all my e-mail.  In
addition, during this whole outage I was sending mail from others of my
accounts to the Sprint account.  Of all the messages sent, some of the
delayed at least six days before delivery, only one generated any kind of a
bounce message or notification.  (That bounce, generated at least five days
after the original message was sent, stated that delivery had been
impossible for at least 4 hours.)  Therefore, it's quite possible that a
number of people are mad at me for not responding to mail I've never seen.

Once again, the risk is that we are seeing the Internet system, dependable
though it may be, as completely reliable.

(As usual, I submitted this to Sprint for their reaction before sending it
out.  They replied within about eight hours--confirming that the outage had
occurred, and pointing out that their terms don't guarantee any minimum
level of service at all :-)

In the meantime, you know where to reach me.  But maybe you'd better copy more
than one address, just to be sure  :-)

rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade


AT&T exposes account info

John Chapin <jchapin@lcs.mit.edu>
Mon, 24 Jul 2000 20:00:37 -0400
I recently had occasion to call the AT&T Credit Management Center,
1-800-532-7486.

You can type a home phone number into their voice menu system and it will
answer back with the account standing, recent payment amounts and dates,
without any password or other authentication. Perhaps this only applies to
delinquent accounts (mine was, temporarily).

AT&T only recently began billing residential long distance customers
directly here in the Boston area, rather than through Bell Atlantic. They
appear to be new to the privacy management side of customer accounts too.

John Chapin, Assistant Professor, MIT Laboratory for Computer Science
545 Technology Square, Cambridge, MA, 02139, 617/253-3538, fax 617/258-8607
jchapin@lcs.mit.edu   http://sdg.lcs.mit.edu/~jchapin


Re: Sliced fiber-optic cable ... (RISKS-20.93)

"Mark Richards" <mark.richards@massmicro.com>
Thu, 6 Jul 2000 09:57:16 -0400
The same thing happened in our town - a much smaller scale - but the poor
response of our phone service semi-monopoly Bell Atlantic is worth noting:

Here in Massachusetts, and perhaps in other states in the US, we have
something called "Dig Safe".  It's both an admonition for the brain dead and
an actual service for identifying buried utilities.  With a simple phone
call, Dig Safe coordinates the identification and marking of buried
utilities so that excavators are not electrocuted or blown up.

In our small community someone either forgot to call them or the marking was
incorrect.  They plunged a backhoe through a Bell Atlantic buried phone
cable and "disrupted" service to a few thousand customers for several days.
It was an "old" cable - the wires weren't colour-coded - making the
wire-matching task extremely impossible.

The really ugly part of the story is that no one, particularly Bell
Atlantic, bothered to notify the local public-safety agencies.  Their lame
excuse, following this debacle, was that "the police should have known,
considering we requested an officer at the scene for traffic control".  The
"accident" left thousands without access to emergency services and the
emergency services were not given proper notification to employ a backup
plan.

By the way, the backup plan has already been thoroughly tested.  Thanks to
the incompetence of Bell Atlantic, our 911 emergency service has been
knocked out twice in the past several months.  Each time it's blamed on
"defective equipment".

These problems continue, while our Public Utilities Commission sleeps at the
switch.  The only time they wake up is when Bell wants a raise.

Mark Richards <mark.richards@massmicro.com>


Re: London Underground magnetic ticket bug (Boyd Roberts, RISKS-20.95)

"Clive D.W. Feather" <clive@demon.net>
Thu, 27 Jul 2000 10:27:24 +0100
Actually, the risk here is in misunderstanding the system.  The system as
a whole (not just the automated gate) worked exactly as designed.

The ticketing gates have 40 or 50 heuristics for detecting problems and
fraud. If the gate is unhappy with the ticket presented, it displays the
message "Seek Assistance" and a code number that the staff can use to
determine what the problem is.

The staff member at the barrier line can apply much more intelligence to the
situation than a machine can. In particular, if you talk to railway staff
you'll discover that they soon acquire a "sixth sense" of when people are
trying to fiddle and when they are being honest. There are also various
"trick" questions they can ask.

Mr Roberts was caught by the "in-out-in" detector. This applies *at a
station*. It is quite possible to exit at a *different* station before
the timer (15 minutes, I think) expires, because this detector will not
then apply.

>It could be even worse; say there's a fire and you need to get out and the
>station is not staffed.

The barrier line *MUST* be staffed at all times. If the member of staff
has to leave for some reason, he or she *MUST* deactivate the system,
which opens all the gates. This is a Health and Safety issue, and LU
would be fined heavily if caught breaking it.

>The Paris Metro, RER and SNCF does this right.  There's an entry timer, but
>it's not used to control exiting.

The Paris Metro is a flat fare system, so there's no need for ticket checks
on exit. The situation isn't exactly comparable.

Clive D.W. Feather  <http://www.davros.org> <clive@demon.net> +44 20 8371 1138


Trust and Risk in Internet Commerce, Jean Camp

<"Peter G. Neumann">
Mon, 24 Jul 2000 16:59:48 -0400
Trust and Risk in Internet Commerce
L. Jean Camp
MIT Press, 2000
292 pp., ISBN 0-262-03271-6
http://mitpress.mit.edu/promotions/books/CAMTHF99

As Internet-based commerce becomes commonplace, it is important that we
examine the systems used for these financial transactions. Underlying each
system is a set of assumptions, particularly about trust and risk.  To
evaluate systems, and thus to determine one's own risks, requires an
understanding of the dimensions of trust: security, privacy, and
reliability.

In this book Jean Camp focuses on two major yet frequently overlooked issues
in the design of Internet commerce systems--trust and risk.  Trust and risk
are closely linked. The level of risk can be determined by looking at who
trusts whom in Internet commerce transactions. Who will pay, in terms of
money and data, if trust is misplaced? When the inevitable early failures
occur, who will be at risk? Who is "liable" when there is a trusted third
party? Why is it necessary to trust this party? What exactly is this party
trusted to do? To answer such questions requires an understanding of
security, record-keeping, privacy, and reliability.

The author's goal is twofold: first, to provide information on trust
and risk to businesses that are developing electronic commerce systems;
and second, to help consumers understand the risks in using the
Internet for purchases and show them how to protect themselves. Rather
than propose a single model of an Internet commerce system, the author
provides the information and insights needed by merchants and consumers
as they develop the Internet for commerce.

L. Jean Camp is Assistant Professor at Harvard University's Kennedy
School of Government.


9th USENIX Security Conference 2000

Hali McGrath <hali@usenix.ORG>
Wed, 26 Jul 2000 18:57:04 GMT
9th USENIX Security Symposium 2000 Conference August 14 - 17, 2000 Denver,
Colorado, USA Conference URL: http://www.usenix.org/events/sec2000

Presentations by top notch instructors and industry experts such as: Avi
Rubin, Daniel Geer, Tina Bird, Brad Cox, Char Sample, Jim Duncan, Rik
Farrow, and Marcus Ranum, Ian Goldberg, Suelette Dreyfus, Mudge, and
Mark Chen.  Keynote Speaker Dr. Blaine Burnham, Director of the Georgia
Tech Information Security Center and former NSA program manager.
Full program details and registration are available online at
  http://www.usenix.org/events/sec2000.

Please report problems with the web pages to the maintainer

Top