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…
[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]
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]
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>
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."
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: 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>
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
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
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>
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 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 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