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…
Unsurprisingly, the *Daily Racing Form* is doing a better job of covering the scam than the general media, here are a couple of references: The "3rd member" of the party (whose account was used to make the "test runs" of the fix prior to the Breeders Cup) was already under investigation by the OTB http://www.drf.com/members/web_news.generate_article_html?p_news_head=42153&p_arc=1 The fired Autotote employee pleads guilty to one count of wire fraud: http://www.drf.com/news/article/42458.html Also it seems that he (and his 2 confederates) were cashing unclaimed tickets that he found in the Autotote system. As in many cases of this type it looks like greed was their undoing. Here's a link to another betting scam from the 1970's: http://www.drf.com/members/web_news.generate_article_html?p_news_head=42077&p_arc=1 I think that the fact that the OTB was already looking into the 3rd person's suspect account indicates that the checks were there, that they didn't act sooner indicates prudence on their part. The worst thing (from a creditability standpoint) that a betting organization can do is withhold a payout and accuse a player of cheating, only to be proved wrong. --Danny Lawrence, Tiassa Technologies Inc. http://www.tiassatech.com/domino/saga.nsf/story/uk
The University of Oslo had to change the passwords of 52,000 users and reinstall software on dozens of computers after crackers managed to infiltrate the network and extract the institution's central password file. http://www.aftenposten.no/english/local/article.jhtml?articleID=437439
***UNPROVEN RISK*** gamers with modded XBoxes are banned by Microsoft. banning means they can be recognized. recognition requires a unique ID, the pozited unique ID is serial no and MAC address. Xbox hackers allege that by changing serial number and MAC address and turning off their modchip they succeeded in registering in Xbox gamezone. Therefore, since integers between 0 and the size of the register in the chip are a finite resource, they have 'stolen' some unsold/unregistered machines ID. Therefore there is an identity theft risk. And there is a DoS game here: walk the space, with your modded box, and lock out the entire XBox userspace from the gamezone Yes, its a large numberfield, maybe a 128-bit sequence space. But I bet you can walk it for fun and profit... >From SlashDot: >Changing serial numbers and macs... >by AtariDatacenter on 11:11 AM November 22nd, 2002 (Score:5, Insightful) >(#4727735) >(User #31657 Info) mailto:jmccorm@yahoo.com?Subject=SlashdotResponse Neutral > > > So they said they changed their serial number *and* MAC address to > get back on. This is interesting and points back to something > someone said in a previous thread. All you need to do is to make > a program to burn through serial number space and get them marked > invalid, and you've got a DoS of entertaining proportions.
There are all kinds of new risks with higher-power processors and metal cases: http://www.cnn.com/2002/WORLD/europe/11/22/health.laptop.reut/index.html [Alo noted by Mark Brader. PGN]
[A letter I'm about to send to the Massachusetts Secretary of State and the City of Boston's Election Department:] Dear Sirs, I was dismayed to learn recently that the City of Boston has decided to replace its lever-activated voting booths with Diebold AccuVote-OS machines, and indeed has already purchased the Diebold machines. As you may know, with the Diebold machines you mark your votes by coloring in circles on a paper ballot, then you feed the ballot through the machine and into a ballot box. After you feed your vote through the machine, a count of successful votes displayed by an LED on the front of the machine is incremented. I asked the volunteer demonstrating the machine to me, "But how do I know that the machine recorded my vote correctly?" In response, she told me that since the number was incremented, my vote was counted. I didn't even try to make her understand that since a ballot could have multiple races on it, and since I could abstain from any of them by not filling in any of the circles for that race, there was no way for me to distinguish between the machine correctly registering all the votes I recorded and the machine registering some of them and missing some and treating them as abstentions. Not to mention the possibility that the machine might register my votes wrong, rather than just register some abstentions where I actually voted. It's certainly a good thing that this voting machine uses a paper ballot. Such a human-readable, physical record of each vote is an essential part of any reliable voting system, electronic or otherwise. However, without explicit acknowledgment from the machine to the voter of which votes were and were not registered, and a chance for the voter to correct any errors or omissions revealed by that acknowledgment, the functionality provided by this machine is simply not adequate for reliable, accurate voting. Furthermore, I cannot help but wonder what happens if the machine says that it didn't successfully register my vote, if the back of the machine feeds directly into a ballot box as the volunteers at my polling place led me to believe it would. Presumably the ballot box is locked, so they can't remove my first ballot. Do I get to try again? And what if there is then a recount of the paper ballots, and my first ballot is legible the during the recount — I got to vote twice! In short, this technology is simply not acceptable. I am deeply disturbed that the City of Boston has chosen to ignore the reams of scholarly evidence of this fact and went ahead with the purchase of simply inadequate voting technology. If you are unfamiliar with all the evidence of why most electronic voting machines are inadequate and of how electronic voting might be done properly, a good place to start researching it is at the Web site of Rebecca Mercuri, "http://www.notablesoftware.com/evote.html". Thank you for your time. Sincerely, Jonathan Kamens
I'm in the middle of preparing a grant proposal for the National Science Foundation, using FastLane, NSF's (now mandatory) online system for proposal preparation, submission, reviewing, etc. For the first time in my grant-writing life, I'm going to have "Co-PIs" (co-Principal Investigators; I am the PI on this proposal). Each Co-PI has to be able to log in to access and modify the proposal; (Co)-PIs' names must be entered on the "Cover Sheet" form, and that form states that "Only Co-PIs entered here will be available on other forms in this proposal." How must they be entered? "To add Co-PIs, enter the SSNs of the Co-PIs and then save the remainder of the cover sheet by clicking on the "OK" button at the bottom of this screen." In other words (as I have confirmed with a phonecall to the FastLane help desk), *either* my Co-PIs have to give me their Social Security numbers so that I can enter them on this form (and thereafter they can log in by themselves), *or* I have to give my Co-PIs my FastLane password (and my SSN, that being [unfortunately] required as well as the password to log in) so that they can log in as me and enter their own SSNs (and thereafter log in by, but not necessarily *as*, themselves). Of course, there's a third choice, the one I will actually make: I can walk over to each Co-PI's office in turn, log in to FastLane on that Co-PI's computer, and let him or her enter his or her SSN. That's easy enough; we're all working at the same university. However, if we were at several universities several hundred miles apart, using FastLane to *facilitate collaboration* among distant colleagues (one of its purported reasons for being), this third choice would not be quite so practical. The RISK is left to the reader.
Since many of you are interested in the topic of E-mail spam, e.g., the techniques used by the spammers to evade filtering and the techniques used by everybody else to try to outsmart them, I thought you might be interested in the following new spammer trick which I first saw on October 17 and have seen numerous times since then. I use a home-grown script to analyze the "Received:" headers of the spam that I receive, determine the appropriate sites to whom to complain, and generate the complaint messages. Spammers figured out quite a while ago to insert forged Received: headers in their messages, but they're usually pretty easy to weed out, e.g., they refer to nonexistent hosts, they list bogus envelope recipients, they have bogus dates, the destination host of one Received: header doesn't match the sender host of the next one in the chain, etc. However, at least one spammer has figured out how to forge a Received: header which more convincing than any I've seen. Here are some of the headers of a spam message I received on October 17: Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jik.kamens.brookline.ma.us (8.12.5/8.12.5) with ESMTP id g9HBd2aP009915 for <jik@kamens.brookline.ma.us>; Thu, 17 Oct 2002 07:39:02 -0400 Received: from 146-153-179-208.pajo.com (146-153-179-208.pajo.com [208.179.153.146] (may be forged)) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id HAA12722 for <jik@mit.edu>; Thu, 17 Oct 2002 07:39:01 -0400 (EDT) Received: from 13217 (20458 [53.86.86.54]) by 6432 (8.12.1/8.12.1) with ESMTP id 27244 for <jik@mit.edu>; Thu, 17 Oct 2002 04:39:00 -0700 From: "Consult" <wizard_21@360.ru> To: "jik@mit.edu" <jik@mit.edu> Subject: Компьютеры и комплектующие по САМЫМ низким ценам. Date: Thu, 17 Oct 2002 04:39:00 -0700 Message-ID: <811325562@mlnCplw1hgx> Note the last Received header. Both the date and the envelope recipient listed in it are correct, and the rest of the header is pretty much formatted correctly; the only tip-off that something strange is going on is the numeric host names. But whoever is doing this got a little smarter pretty quickly. Here's the last Received: header from a spam message I receive on November 6: Received: from delphi.com (mailexcite.com [85.34.182.181]) by aol.com (8.11.6/8.11.6) with ESMTP id 9874 for <jik@mit.edu>; Wed, 6 Nov 2002 09:37:38 +0000 Much better, eh? I've seen various incarnations of this since then with data that seems at first glance to be correct but does not withstand closer inspection. Note that you can't use a simple regular expression match to filter out all messages with headers in this format, because this is a valid Received: header format and I've received real non-spam messages that use it (albeit with data that isn't bogus). They're getting smarter. I just hope by bogofilter database can keep up with them :-).
eTags are (optionally) used in Sydney for automated highway toll collection. [risk #1 - well known - loss of privacy] Background: If the tag does not read electronically, then your licence plate is photographed. Before sending out an infringement notice, they lookup your licence plate on the database of eTag account holders. In Sydney we have many different types and colours of licence plates (for fashion reasons) and the type of plate forms part of the unique key. [risk #2 - makes identity harder] Motorcyclists are not allowed to have eTags because they haven't found a secure way to attach them to motorcycles. My friend Robyn had this experience: I have an eTag for my car which I have used on my bike on a number of occasions. Once it didn't work when I used it on my bike so I thought rather than wait to get a fine I'd ring them. Although they did tell me I should not be using it on my bike they said it didn't matter because it had come up as a misread on my account and that they had just automatically charge my account anyway. The interesting thing is that I had not told them that I have a bike!!! So how did they know to charge it to my account ??? Well, the number plate [licence plate] on my car is exactly the same as the number plate on my bike (car has black & white plate with 2 letters & 3 numbers the same as the bike plate but its yellow). So basically if you have a number plate on your bike that is the same as a car with an eTag you can go through the express lane and it will just get charged to someone else's account. (A bit of a worry if you're the account holder.) Robyn [The main risk, #3, their licence plate database apparently does not seem to include the colour of the plate in the field.] [Robbin' Robyn to Pay Pal? That's Round-Robyn. PGN]
BKSECENG.RVW 20021015
"Security Engineering", Ross Anderson, 2001, 0-471-38922-6, U$65.00
%A Ross Anderson ross.anderson@ieee.org rja14@cam.ac.uk
%C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8
%D 2001
%G 0-471-38922-6
%I John Wiley & Sons, Inc.
%O U$65.00 416-236-4433 fax: 416-236-4448
%P 612 p.
%T "Security Engineering: A Guide to Building Dependable Distributed
Systems"
The preface states that this book is intended as a text for self-study or
for a one term course, a reference for professionals, an introduction to the
underlying concepts, and an original scientific contribution in terms of the
foundational principles for security engineering. A very tall order to
promise, but one which, for once, seems to have been fulfilled. I have
often been asked, in regard to these reviews, whether there are, in fact,
any books that I like. Well, I like this one. If you are involved with
security and you haven't read it, you should.
Part one deals with the basic concepts of engineering and security. Chapter
one presents four example situations of security needs. Protocols are not
limited to the precise but limited structures computer people are familiar
with. A set of more conceptual, but more formal, authentication problems
and protocols are advanced in chapter two. It is unlikely that the models
presented exhaust the field, but some thought indicates that they are
applicable to a wide variety of applications. (Anderson's writing is clear
enough, but he does betray a taste for symbolic logic that might limit the
audience for the book. Still, perseverence on the part of the reader will
be amply rewarded.) Much the usual thoughts and advice on passwords is
issued in chapter three, although the research is better documented, and
some additional research (passphrase generated passwords are as secure as
randomly assigned ones, and as memorable as naively chosen ones) is
presented. It is strange not to see any mention of the work factor of
passwords overall. Chapter four reviews access control, but primarily from
the perspective of system and hardware internals. Cryptography, in chapter
five, is covered reliably and well, although Anderson does not work overly
hard to make the material easy to follow. The problems of distributed
systems are examined; in terms of concurrency, failure resistance, and
naming; in chapter six.
Part two uses a number of applications of secure systems to introduce
particular concepts or technologies. Chapter seven discusses multi- level
security, which encompasses most of the formal security models such as
Bell-LaPadula. Medical (and census) databases are used, in chapter eight,
as examples of multilateral, or compartmented, security: the need to deal
with information of equal sensitivity, but restricted to different groups.
There is good discussion of inference and aggregation problems. Integrity
controls, particularly related to the banking system and fraud, are
presented in chapter nine, although the material is long on anecdotes, and
contains weaker analysis than the preceding text. Chapter ten reviews
monitoring systems, of both monitoring and metering types. In regard to
nuclear command and control systems, chapter eleven examines the tension
between availability (the ability to fire a missile) and confidentiality (or
authentication: making sure nobody else does). Various aspects of the
technology for security printing and seals is dealt with in chapter twelve.
Biometrics, in chapter thirteen, gets a good, but fairly standard,
treatment. Chapter fourteen delves into tamper-resistance in cryptographic
gear and smartcards. The TEMPEST and Teapot (no, I'm not kidding) projects
on emission security are reviewed in chapter fifteen. There is good
coverage of the basics of traditional electronic warfare in chapter sixteen,
although the material on information warfare is not as thorough. Chapter
seventeen looks at telecommunications system security, with some material on
phone phreaking and lots on cellular encryption. Network attack and
defense, in chapter eighteen, is less focussed than other chapters, and adds
malware. (There is an odd, and unexplained, assertion that malware would
formerly have merited a full chapter: In correspondence, Anderson has said
that the new email viruses show less diversity than the old DOS versions. I
disagree. But then, I would, wouldn't I? :-) The relation of types of
antiviral and intrusion detection systems is good. Chapter nineteen, on
protecting e-commerce systems, has good information but mixed in a bit of a
grab bag: e-commerce is always a bit of a fuzzy topic. There is solid
coverage of recent controversies in regard to copyright and privacy
protection, in chapter twenty.
Part three turns to politics, management, and assurance. Chapter twenty one
has a fascinating discussion of major issues in public policy. Management
issues, in chapter twenty two, are presented in an interesting but generic
manner. The discussion of system evaluation and assurance asks the usual
question of how we know our systems are secure. In a sense, though, the
subtitle of the book is wrong: much of the material points out how *not* to
build dependable systems, and chapter twenty three is a bit disheartening.
The conclusion, in chapter twenty four, is that we need more engineers and
engineering.
Although the material is presented in a very formal way, the writing is
usually quite readable, and the exceptional stilted passages are still
accessible to the determined reader. On occasion, one could hope for
additional explanations of some items that are mentioned briefly and passed
over, but, by and large, one has to agree with Bruce Schneier's assessment,
reprinted on the book jacket, that this is one of the most comprehensive
works on security concepts that is available. The constant emphasis on how
security protections have failed can be depressing, but the examination of
the errors of others does provide the basis for better designs in the
future.
copyright Robert M. Slade, 2002 BKSECENG.RVW 20021015
rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com
BKNTINDT.RVW 20021009 "Network Intrusion Detection", Stephen Northcutt/Judy Novak/Donald McLachlan, 2001, 0-7357-1008-2, U$45.00/C$67.95/UK#34.99 %A Stephen Northcutt stephen@sans.org snorthcutt@hawaiian.net %A Judy Novak %A Donald McLachlan don_mclachlan@hotmail.com %C 201 W. 103rd Street, Indianapolis, IN 46290 %D 2001 %G 0-7357-1008-2 %I Macmillan Computer Publishing (MCP)/New Riders %O U$45.00/C$67.95/UK#34.99 800-858-7674 http://www.newriders.com %P 430 p. %T "Network Intrusion Detection: An Analyst's Handbook, Second Ed." The introduction for the first edition of this work was a bit confusing. The front matter for the second edition is much more so. The only item listed in the table of contents is the introduction, but, while still stating that the book is intended as a training aid and reference for intrusion detection analysts, it is much the smallest item of the many at the beginning of the book. There is a longish, and not very clear, history of the "shadow" program. In addition, there is a preface, which meanders around presenting opinions about various aspects of the Internet and security. It does finally provide a rather interesting definition of intrusion detection; the purpose is to identify threats and make sure the network is hardened against them; but does not make clear what the book is for, or how it approaches the subject. Chapter one is a basic overview of TCP/IP. The material is reasonable, albeit limited, but not exemplary. TCPdump is examined before TCP itself, in chapter two. Again, the content is informative, but there are definite gaps. Fragmentation uses, issues, and patterns in TCPdump are presented in chapter three. Chapter four does provide some idea of the use of ICMP (Internet Control Message Protocol), but not a comprehensive or clear one, and not in the stated introduction. The coverage of ICMP attacks is neither particularly lucid nor particularly complete. It does, however, furnish some convincing arguments for the use of stateful inspection. Chapter five presents a few "normal" transactions that you might see in network traffic, and some that might indicate some type of attack. The material is interesting, but is not displayed in a structure that would make it useful to the reader. DNS (Domain Name Service) is explained in some detail in chapter six, although the attack and exploit coverage is terse. In chapter seven (chapter one, from the first edition), we are given some details of the TCP hijacking attack Kevin Mitnick launched against computers used by Tsutomu Shimomura. In fact we are given rather a lot of details, and not a little C code, much of which is simply thrown out at us. The experienced UNIX network analyst and C programmer will, of course, have no difficulty with the material, and any reasonably experienced computer user will likely be able to find references in order to work through the real implications of the text. Late in the chapter there is a promise of explaining how to detect such an intrusion with two different systems: this promise is not fulfilled. The concept of filters and signatures is introduced in chapter eight, although the examples tend to be either system specific and heavily coded, or overly simplistic. The initial section of chapter nine attempts to present a means for determining which events are important enough to record and analyze, and does not succeed very well. The latter portion, on considerations for intrusion detection system (IDS) architecture is much more useful. Chapter ten starts out with a look at a variety of attempts at interoperability between intrusion detection vendors (making me think of the bygone days of standardized virus signature files: the availability of standards is shown to be problematic) and then tenders some ideas about suspicious types of traffic, finishing with a few thoughts on database queries and data reduction. A number of IDSes are described in chapter eleven, although the level of detail, and even the general writeup structure, varies greatly. Chapter twelve seems to be out of place: the prediction about the future usually happens at the end of the book. Exploits, denial of service, and scan patterns are described in chapters thirteen, fourteen, and fifteen, repeating some of the material from chapters five and seven. Although interesting, not all of the content would be helpful to analysts or IDS administrators. Signatures related to the use of RPC (Remote Procedure Calls) as an attack tool are given in chapter sixteen. Chapter seventeen describes various options for filtering traffic for or with TCPdump. A "cracking" session, after a system has been penetrated, is presented in limited detail in chapter eighteen. In this case we are presented with a log of UNIX shell commands, and, rather ironically, a great deal more exegesis than is available in other sections (although the attempts at humour do confuse the issue, here and elsewhere in the book). A discussion of blackhat communities and resources has been added in this edition. A "detection" is outlined in chapter nineteen, but with a supremely anticlimactic ending: the summary admits that no reason for the anomalous traffic has been found. Chapter twenty reviews some basic security topics, such as policy development and risk assessment, but in a very simplistic and terse fashion. A number of possible responses to an intrusion are outlined in chapter twenty one. Chapter twenty two closes with suggestions on ow to make a business case. Those who need to know about intrusion detection should probably first look at Bace's (cf. BKNTRDET.RVW) or Amoroso's (cf. BKINTDET.RVW) books, both (somewhat annoyingly) titled "Intrusion Detection." Because of the lack of structure in the work, this volume is not usable as an overview introduction to the field, although the examples do contain a great deal of informative content: if you can dig it out. For those who do have the basic concepts, the material does provide numerous practical examples, and some real-life considerations for implementation. copyright Robert M. Slade, 1999, 2002 BKNTINDT.RVW 20021009 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
Please report problems with the web pages to the maintainer