precedence: bulk Subject: Risks Digest 22.93 RISKS-LIST: Risks-Forum Digest Tuesday 7 October 2003 Volume 22 : Issue 93 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at http://www.risks.org as http://catless.ncl.ac.uk/Risks/22.93.html The current issue can be found at http://www.csl.sri.com/users/risko/risks.txt Contents: Walter Cronkite: The New Inquisition (Chuck Messall via Dave Farber) Re: Spam abounds (PGN) California spammin' (NewsScan) Worm FAQ (Stuart Staniford) Jury convicts man in DMCA case (Paul Festa via Monty Solomon) Broward considers dumping $17 million in touch voting machines (Kim Alexander) Diebold voting machines in Volusia County FL (Brent M.P. Beleskey) Identity Denial really exists (Roger Clarke) Difficulties with Census Bureau income data among wealthiest (George Mannes) Fun with stolen credit-card numbers (Jonathan Kamens) Credit cards as ID (Ben Laurie) REVIEW: "Intrusion Detection with Snort", Jack Koziol (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 07 Oct 2003 13:58:43 -0400 From: Dave Farber Subject: Walter Cronkite: The New Inquisition [The last sentence is right on. djf] From: CMESSALL Walter Cronkite: "...Unfortunately, security and liberty form a zero-sum equation. The inevitable trade-off: to increase security is to decrease liberty and vice versa. In the past, such trade-offs have been temporary -- for the duration of the crisis of the moment. But today, we cannot see an end to the War on Terrorism, and that forces us to decide how secure we have to be and how free we want to be." Wow, have we already forgotten Ben Franklin's statement: "People who are willing to trade security for freedom soon find out that they have neither."? In all fairness to Walter (who, I would have thought, might have actually *heard* Ben say those magic words ;-)), the trade-off might be correct at any given point in time, for the technology that applies at that instant. The secret of course is to change the rules (i.e., the technology) so that we can have more security AND retain our liberty. - Chuck Messall IP Archives at: http://www.interesting-people.org/archives/interesting-people/ ------------------------------ Date: Tue, 7 Oct 2003 11:16:28 PDT From: "Peter G. Neumann" Subject: Re: Spam abounds (RISKS-22.92) Thanks to many of you who responded thoughtfully to my plaintive cries of Spam-woe. The simplest approach something that I have been contemplating for some time is to suggest that, if you want to significantly raise the probability that your message to RISKS will not be ignored, use the current string to include in the subject line. "RISKS" itself in the subject line is less than ideal, because a surprising number of spams actually include that. But for the foreseeable future, to radically improve my well-being and ability to separate the wheat from the chaff, let's try the string notsp: in the subject line followed by a meaningful subject, or perhaps "notsp" appended to the subject line (CASE INSENSITIVE). This pass-string will remain relatively stable unless it gets abused, in which case I will announce a phased-in change. Many thanks for putting up with this inconvenience. Other remedies were suggested by RISKS readers (although some of them are not really suitable for RISKS-types of operations): * Greylisting * Spambayes (following the inspiration of Graham, extensively tested and improved) * Indirection to a Web page that has the CURRENT valid address that changes as needed, plus procmail filters * TMDA anti-spam challenge-response software * Client-side POPFile proxy (open source, cross-platform) * Bogofilter and various other filters * Just change your e-mail address as often as desired, and notify your regular communicators (clearly not applicable for RISKS, which graciously receives e-mail from first-time contributors and needs the stability of a permanent address). An important concept in any such approach is that YOU should have flexible control over it, rather than some third-party who tells you what you should be willing to accept or reject. There is no one-size-fits-all. However, * Tripoli is a flexible approach that could help significantly. ------------------------------ Date: Thu, 25 Sep 2003 06:31:25 -0700 From: "NewsScan" Subject: California spammin' California's new anti-spam law may face the same fate as a similar law in Utah earlier this year. Kevin Johnson of the e-mail marketing company Digital Impact warns: "Hard-core spam will still come through, but legitimate companies will be more hesitant to send e-mail"; he also warns that when companies try to determine whether e-mail recipients live in California, spammers and advertisers may be forced to learn more about consumers, thereby reducing privacy. E-mail marketer Trevor Hughes suggests that the only answer is national legislation to harmonize spam laws in more than 30 states. [*USA Today*, 24 Sep 2003; NewsScan Daily, 25 Sep 2003] http://www.usatoday.com/tech/news/2003-09-24-spam_x.htm ------------------------------ Date: Mon, 6 Oct 2003 15:34:48 -0700 From: Stuart Staniford Subject: Worm FAQ I just finished a first cut at a FAQ on worms and worm containment (my obsession for the last couple of years). It may be of interest to RISKS readers: http://www.NetWorm.org/faq/ Stuart Staniford, President Tel: 707-445-4355 x 15 Silicon Defense - The Cyberwar Defense Company ------------------------------ Date: Thu, 25 Sep 2003 01:51:39 -0400 From: Monty Solomon Subject: Jury convicts man in DMCA case (Paul Festa) Paul Festa, Staff Writer, CNET News.com, 23 Sep 2003 A federal jury has convicted a Florida man of violating the Digital Millennium Copyright Act, in the first jury-trial conviction under the controversial law, according to a U.S. attorney's office. The Los Angeles jury found 38-year-old Thomas Michael Whitehead guilty on Friday of selling hardware that could access DirecTV satellite broadcasts without paying for them, according to the U.S. attorney's office in Los Angeles. Whitehead, who was also known by his computer name "JungleMike," was convicted on one count of conspiracy, two counts of selling hardware that unlawfully decrypted the broadcasts, and three counts of violating the DMCA. With the six felony convictions, Whitehead faces up to 30 years in federal prison and fines of as much as $2.75 million. Sentencing is scheduled for Jan. 26, 2004. ... http://news.com.com/2100-1025-5080807.html ------------------------------ Date: Thu, 25 Sep 2003 08:39:48 -0700 From: Kim Alexander Subject: Broward considers dumping $17 million in touch voting machines Here's some good news out of Florida. Broward County is lobbying for approval of printers for touchscreens, and one of their election officials expresses regret for purchasing them in the first place. Here's an excerpt: The touch-screen machinery accounted for part of the problems in the 2002 elections in Broward. During the September primary, election workers found more than 1,000 votes that had not been reported in initial tallies to the state because machines had not been shut down properly. And then in the November election, officials botched the numbers by not including in the tallies ballots cast by English-speaking early voters. "Hindsight is 20/20, but I wish we had stayed with optical scan," Commissioner Kristin Jacobs said. Source: Broward considers dumping $17 million in touch voting machines, Scott Wyman, 24 Sep 2003, *South Florida Sun-Sentinel* Kim Alexander, President, California Voter Foundation kimalex@calvoter.org, 916-441-2494, http://www.calvoter.org ------------------------------ Date: Wed, 24 Sep 2003 09:57:44 -0400 From: "Brent M.P. Beleskey" Subject: Diebold voting machines in Volusia County FL ELECTION THEFT 2000! A NEW BOMBSHELL!: A Diebold Voting Machines in Volusia County, Florida, Tallied a Vote-Count of -16,022. That's NEGATIVE 16,022: When will this all-important story break out in the US mainstream press? When will the Democrats confront the issue? What is at stake here is the future of democracy. Diebold Internal Support Memos [The original article to which this post refers was originally published on 29 Nov 2000 in *USA Today* by Philip Meyer. When I did a search for the article on the www.usatoday.com website I came up with this page which clearly provides the details of the article and even offers a link to a free preview of the article. However, when you click on the link, it gives you a page void of the article. What happened to it? One can only speculate. Nevertheless, I have obtained the original article. BMPB] [Contact Brent Beleskey for the article, PGN] A remarkable exchange concerning Diebold's voting machines in Volusia County, Florida: On January 17, 2001, Lana Hines, a county elections official sends out an inquiry as to how Al Gore ended up with a vote-count of -16,022. That's NEGATIVE 16,022 -- which just happens also to have been the total number of votes cast for various independent and third-party candidates who also ran. (It was the largest number of such votes cast in Volusia County's history.) Pay close attention to the final entry, from "Tab" (Talbot) Iredale, Vice President of Research & Development at Global/Diebold: ...The error could only occur in one of four ways: 1.Corrupt memory card. This is the most likely explanation for the problem but since I know nothing about the 'second' memory card I have no ability to confirm the probability of this. 2.Invalid read from good memory card. This is unlikely since the candidates['] results for the race are not all read at the same time and the corruption was limited to a single race. There is a possib[ili]ty that a section of the memory card was bad but since I do not know anything more about the 'second' memory card I cannot validate this. 3.Corruption of memory, whether on the host or Accu-Vote. Again this is unlikely due to the localization of the problem to a single race. 4.Invalid memory card (i.e., one that should not have been uploaded). There is always the possib[i]lity that the 'second memory card' or 'second upload' came from an unauthorised source. And that's only the tip of the iceberg. ------------------------------ Date: Sat, 27 Sep 2003 11:17:22 +0800 From: Roger Clarke Subject: Identity Denial really exists [Admittedly this is a story from mainlaind China, and stories from there are often mistranslated linguistically and culturally when they reach English- language papers. But it appeared in the quality Hong Kong daily. It would seem reasonable to assume that their staff can read the original, and not make too many mistakes in the translation.] Woman wins case against in-law for ID cancellation A 98-year-old woman will be paid damages for psychological injury inflicted by her daughter-in-law, a Beijing court has ruled. The *Beijing Daily* reports that the elderly woman discovered her relative cancelled her identity registration card seven years ago. The defendant claims she cancelled the card to ensure her mother-in-law would not be cremated after she died. Cancelling the card made the woman non-existent in the eyes of the law. Source: *South China Morning Post*, dateline Beijing, 26 Sep 2003 [They have a closed web-site, so I can't find the URL] Roger Clarke http://www.anu.edu.au/people/Roger.Clarke/ +61 2 6288 1472 Xamax Consultancy Pty Ltd, 78 Sidaway St, Chapman ACT 2611 AUSTRALIA ------------------------------ Date: Tue, 7 Oct 2003 14:46:24 -0400 From: George Mannes Subject: Difficulties with Census Bureau income data among wealthiest The Five Dumbest Things on Wall Street This Week By George Mannes, Senior Writer, 3 Oct 2003 http://www.thestreet.com/markets/dumbestgm/10117038.html [George sent RISKS an excerpt, namely, the FIRST of five dumbest things. I had difficulty trying to abridge it for RISKS, and decided to include it in its entirety. See the URL for the other four. PGN] 1. I Dream of the Gini Index We at the Five Dumbest Things Research Lab hate to go all anti-academic on you, but here's a little advice: The next time you see a statistic in the newspaper, don't believe it. It's wrong. OK, OK. That's overstating our case a little. It's not necessarily wrong. But it's not right, either. Exhibit A: The 2002 household income figures released last Friday by the U.S. Census Bureau. The takeaway from the report, as you may have read in *The Wall Street Journal*'s Monday account, was that the poverty level rose, but income inequality didn't, because rich folk's income took a beating, too. But something further down in the write-up caught our eye. "Difficulties in recording seven-figure incomes," reported the Journal, might have resulted in underreported income among the wealthiest Americans. In other words, the rich may be richer. That's odd, we thought. People pay a lot of attention to these annual income-disparity figures. How come no one's getting worked up about inaccurate data from such a key segment of the surveyed population? This can't be true. We called up Edward Welniak, chief of the Census Bureau's income survey, to check. Indeed, there are difficulties with high-income data, Welniak told us. Here's why: Starting with the 1993 numbers, the bureau's staff -- which interviews a sample of 78,000 households for the income survey either in person or over the phone -- has been entering people's responses directly into portable or desktop PCs. As part of the survey, respondents are asked to report how much money they made the previous year from numerous sources -- stuff like the job held the longest, interest and dividends. And here's the catch: In each category, the highest dollar amount one can enter is $999,999. So let's say a Census employee had dropped by the $15,000-umbrella-stand- festooned apartment of ousted Tyco Chairman Dennis Kozlowski in 2001. And let's say the then-executive wanted to report the $50 million or so in undisclosed compensation the Securities and Exchange Commission says he received in 2000. Well, Kozlowski couldn't have done it. The Census would have recorded his salary at a mere million bucks. "The fact that we're not recording the full dollar value is going to understate the share of income controlled by households at the highest levels," says Welniak. But, says Welniak, there's a good reason for capping monetary entries at six digits: It limits the potential for error. One extra digit at the high end, and you're talking about, say, a $9 million paycheck instead of a $900,000 payout. Errors at the high end of the income scale have a much larger impact than errors at the bottom. The increased accuracy introduced by more possible digits, says Welniak, would be more than offset by the decreased accuracy from newly enabled errors. Welniak has even investigated the exact effect of rounding all multimillion-dollar income sources down to a megabuck. According to his analysis of numbers from 1999 -- a year for which 26 respondents reported employment compensation of at least $1 million in at least one category -- data-entry limitations effectively understated income inequality by 1%, using a standard measure of income distribution known as the Gini Index. But, given that the error appears to be constant year after year, says Welniak, "Measuring changes in income inequality from one year to the next is not going to be affected." In other words, ignore the absolute number and look at the trend. Mindful of that, we point out that over the past decade, the Census Bureau's Gini Index has been creeping upward -- implying increased income inequality. Starting at 45.4 in 1993, it peaked at 46.6 in 2001 but retreated to 46.2 last year. (For purposes of comparison, the United Nations Development Program -- which puts the U.S. at 40.8 -- says Japan is a 24.9 and Brazil is a 60.7.) In fact, someone has gotten worked up about the low-balled high incomes: the Center on Budget and Policy Priorities, a D.C.-based research group. The CBPP has been complaining about the Census data for years, griping not only about the $999,999 cap but also about the Bureau's exclusion of capital gains from household income. "The census data has useful information," says Isaac Shapiro, a CBPP senior fellow. "But at the high end, it's not useful." Based on Congressional Budget Office data, the CBPP says the average household after-tax income in the top 1% of the population tripled from $286,000 in 1979 to $863,000 in 2000, while the lowest fifth of the population saw household income rise a mere $1,100 to $13,700 over the same time period. Put that in your Gini Index and smoke it. George Mannes, 14 Wall Street - 15th Floor / New York, NY 10005 phone: 212-321-5208 / mobile: 646-641-2093 http://find.thestreet.com/cgi-bin/texis/author/?au=A0000332 ------------------------------ Date: Fri, 5 Sep 2003 11:31:57 -0400 From: Jonathan Kamens Subject: Fun with stolen credit-card numbers Yesterday, I got an e-mail message from Amazon.com which I am including here in full (word wrapped and with some details obscured but otherwise unmodified) because I believe it will be of interest to RISKS readers. Additional comments from me follow the message. X-AMAZON-TRACK: Date: Thu, 4 Sep 2003 16:01:07 -0700 From: charge-inquiries@amazon.com To: jik@kamens.brookline.ma.us Cc: charge-inquiries@amazon.com Subject: Your Credit Card Account Greetings from Amazon.com. We perform routine reviews of orders to protect our customers. During one of these reviews we discovered that an account was opened with a card used by you on another account. For your reference the card in question is a American Express card with the last five digits of [deleted]. As it appears the card was used without your authorization, we have closed this new account and cancelled any outstanding orders. If the account is indeed yours, we apologize for any inconvenience caused and ask that you notify us by replying to this email message as soon as possible. If the card was used without your authorization, we recommend you cancel the card immediately by contacting the financial institution that issued the card. Unfortunately, if this is the situation, you should know that a charge in the amount of $556.94 was processed by us. You should review all recent charges made to this card, reporting any unauthorized charges, including those mentioned above, to your financial institution. The financial institution, in turn, will send you forms to formally dispute the unauthorized charges, the applicable merchants will be notified and charged back, and your account subsequently credited. Additionally, you may wish to report this matter to the applicable law enforcement agency. We were able to verify that your card was not compromised from our site. Our credit and debit card data is stored on a computer that is not connected to the Internet. When data is received it is sent to a dedicated computer via a proprietary one-way interface across a simple serial connection. The information is stored no other place, access to the data is restricted and, when accessed, logged. Although we are not permitted to provide you with any details about the unauthorized use, we will provide this information to any law enforcement agency investigating this matter as well as to the financial institution. Please don't hesitate to contact us if you have any further questions or concerns. Sincerely, Ben Investigation Specialist Amazon.com http://www.amazon.com Earth's Biggest Selection ========================= I went to the American Express Web site and checked the unbilled activity on the card, and, indeed, found a charge of $556.94 to Amazon.com on August 31 which I did not make. I also found another charge I did not make of over $500 to Amazon.com on August 27. I called the telephone number on the back of my card, navigated through voice-mail for several minutes and then spoke to three representatives. The first deactivated my card, issued me a new one, and transferred me to the customer service department. The customer service rep transferred me to the fraud department. The fraud rep ask me a few questions that were probably from a script ("Was your card ever out of your possession?" "Did you make these charges?", etc.). Then she said that the charges would be removed from my account and investigated. Some things here worked very well. It's good that Amazon caught the bogus charges relatively quickly and notified me about them. It's good that American Express was polite and was able to deactivate my card, issue me a new one, and remove the bogus charges from my account quickly. Some things did not work so well. Why didn't Amazon stop the perpetrators in real-time from making a purchase using a card already registered to another account, as opposed to only detecting the situation after the fact? Since I assume that the fraudulent purchase was shipped to an address other than mine, why didn't Amazon require additional verification before shipping over $500 of merchandise to an address other than the card's billing address? There are some questions whose answers I do not know, and neither Amazon nor American Express is telling. Did the perpetrator use my name? Did s/he know my correct billing address? Did s/he know the security code printed on the front of the card? And if the answer to any of these questions is "no," why did Amazon allow the charge? And the biggest question, to which I'll probably never know the answer, is, how did the perpetrator steal my info? Even if they catch him/her and find out, it's unlikely that the information will trickle back to me. Today I'll be contacting all the credit-reporting agencies to put a fraud alert on my report and ask them for free copies so that I can verify that this is merely a case of isolated credit-card number fraud as opposed to full-scale identity theft. Who knows, this may be the start of a very bumpy ride. Jonathan Kamens ------------------------------ Date: Fri, 03 Oct 2003 12:50:21 +0100 From: Ben Laurie Subject: Credit cards as ID About a week ago, our front door was broken down at 3 in the morning. The burglars took my wife's handbag from the hall and ran (luckily, it didn't contain her car keys, because a common strategy is to return in a few hours and take the car, too). Today, we received a number of phone contracts. These may or may not have been paid for with the stolen credit cards [1], but (we are informed) the credit cards were used for ID. This got me thinking. My credit cards are often used for ID, too. But they never check whether the card has been stolen - all they check is that it has the right name on it. Now, given that the most common case of this occurring is when I take internal flights in the UK, I'm suddenly worried. The risk is obvious. Incidentally, the incidents also show the lack of value of photo ID - at least one of the contracts requires proof of address, and the only proof in the handbag was my wife's driving licence. Which has a photo on it. So I guess we can add that as a second risk (i.e. relying on photo IDs for fraud prevention). [1] Since my wife spent the time waiting for the police cancelling all her cards, they may not have been used. http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ------------------------------ Date: Mon, 6 Oct 2003 21:22:12 -0800 From: Rob Slade Subject: REVIEW: "Intrusion Detection with Snort", Jack Koziol BKINDTSN.RVW 20030901 "Intrusion Detection with Snort", Jack Koziol, 2003, 1-57870-281-X, U$45.00/C$69.99/UK#32.99 %A Jack Koziol %C 201 W. 103rd Street, Indianapolis, IN 46290 %D 2003 %G 1-57870-281-X %I Macmillan Computer Publishing (MCP) %O U$45.00/C$69.99/UK#32.99 800-858-7674 info@mcp.com %O http://www.amazon.com/exec/obidos/ASIN/157870281X/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/157870281X/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/157870281X/robsladesin03-20 %P 340 p. %T "Intrusion Detection with Snort" Chapter one is a good introduction to the basics of intrusion detection, although it is odd that the list of detection methods is missing some important entries, such as heuristic rule-based and statistical methods. The background overview of Snort, in chapter two, describes alerts, related applications, and even has recommendations for sensor net architecture. Most of the content in regard to the components of Snort, in chapter three, deals with the preprocessors, and various attack signatures. Chapter four's advice about planning for the installation of Snort is broadly based, addressing policy, architecture, and even incident response, but the material is quite abstract, and could have benefitted from more practical examples. Some of these missing considerations are dealt with in chapter five, which looks at hardware and operating system factors. The text concentrates on server and sensor performance, but also addresses the network connection. Directions on building a Snort server under Red Hat Linux version 7.3 are given in chapter six. The sensor and console instructions are provided in chapters seven and eight, respectively. A few optional architectures are described in chapter nine. Chapter ten deals with tuning various rulesets and components in order to reduce the level of false alarms. Creating real-time alert systems is discussed in chapter eleven. Chapter twelve is a major one, outlining the creation and modification of rules for filtering and analyzing traffic. Chapter thirteen is supposed to be about upgrading and maintaining Snort, but concentrates on ancillary management tools. Advanced or unusual configurations of Snort are described in chapter fourteen. The book is generally lucidly written and easy to study, but it contains many typographical errors and a great deal of clumsy wording in the text. Better copy editing word have improved readability, as well as confidence in the reliability of various commands and settings. However, the meaning is usually clear, even if the expression is sometimes jarring. For those planning to use Snort, this should be a serviceable introduction. copyright Robert M. Slade, 2003 BKINDTSN.RVW 20030901 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@sun.soci.niu.edu http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 30 May 2003 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@CSL.sri.com . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address " ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .UK users should contact . => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES: http://www.sri.com/risks http://www.risks.org redirects you to the Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 22.93 ************************