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…
An America Online employee, Jason Smathers, has been charged with stealing AOL's list of 92-million customers and selling it it to an Internet spammer/marketer/online-gambling purveyor Sean Dunaway (who then resold it for $52,000 a pop). Dunaway was also charged. Smathers has been fired. [Sources: Monty provided several items, which were PGN-ed.] Reuters, 23 Jun 2004 - http://finance.lycos.com/home/news/story.asp?story=42133939 Andrew Orlowski, 24 June 2004, UNITED STATES v. JASON SMATHERS, SEAN DUNAWAY http://news.findlaw.com/hdocs/docs/cyberlaw/ussmthrs604acmp.pdf http://www.theregister.com/2004/06/24/aol_spam_insider/ ]
Today Riksförsäkringsverket (the central authority that pays all social benefits and illness-related salary-supplements) was disabled by virus attacks. This concerns all of Sweden's population of 9M persons. Not all of us rely on this money, but every Swede who happens to be eligible for any payments is. A lot of errors seem to contribute. One of the larger is basing a national insurance system on computers that are defenseless against any external threat, another that those "toy-computers" are exposed to external threats. Maybe the golf-tours made the difference during the purchasing procedures?? There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. )
A senior Justice Department official has told a Senate committee that law enforcement faces new threats from Internet-based telephone services, and warned that legislative efforts to deregulate VoIP (Voice over Internet Protocol) services could undermine the ability of law enforcement officials to investigate criminal or terrorist activity. The Justice Department has asked the FCC to require Internet phone companies to design electronic conduits in their networks that would make it easier to tap conversations. James X. Dempsey of the Center for Democracy and Technology says that a better approach would be for investigators to work cooperatively with Internet phone providers. (*The Washington Post*, 16 Jun 2004; NewsScan Daily, 17 Jun 2004] http://www.washingtonpost.com/wp-dyn/articles/A47882-2004Jun16.html
[Written on 4 June, but only sent now because of a problem with my Usenet server. :-(] Canada's largest bank, the Royal Bank of Canada, has been unable to process deposits or report balances for the last five days. The bank is blaming "a processing disruption during a routine programming update to one of our computer systems". Direct deposit to a bank account is a common way to pay salaries here, especially for large employers, and among those affected are employees of the Government of Ontario, Canada's largest province, which apparently uses the Royal Bank for its payroll. The Royal Bank has 10 million customers, about a third of Canada's population. It says that it "processes tens of millions of transactions each day". The bank confirms that "the processing disruption was national in scope so we expect a significant number of clients have been affected". The bank promises that: "We will fully refund any service fees or overdraft interest charged to RBC clients' accounts due to this processing delay. Any other reasonable costs incurred as a result of this delay will be handled on an individual basis". It also says that: "All the other banks are aware of this situation and we have asked them to be as accommodating as possible". (There are seven major banks in Canada.) More information at: http://www.royalbank.ca/client_faq.html http://www.globeandmail.ca/servlet/story/RTGAM.20040604.wrbc0604/BNStory/Business/
Peter, I'm pleased to announce the availability of detailed registration, schedule, program, hotel, and other information relating to our People For Internet Responsibility (PFIR) "Preventing the Internet Meltdown" conference here in L.A. from July 26 through 28, 2004. The registration period for the conference commences immediately. The conference information is all available from the Meltdown official announcement document and related linked pages via: http://www.pfir.org/meltdown In the time since you, Dave Farber, and I originally suggested this conference, the situation with many issues related to the Internet have become even more complex and controversial. These range from Internet governance and control to Homeland Security issues; from VoIP, WHOIS, DNS, and privacy to spam, viruses, and other attacks on the Internet infrastructure and its users; and much more. The Internet and the global populations who depend upon it are at real risk. We hope that this gathering will aid in mapping out some specific courses of action that can help us all avoid the many negative impacts that an Internet meltdown would impart. We're looking forward to a most interesting and productive event. Thank you very much. Be seeing you! --Lauren-- Lauren Weinstein lauren@pfir.org or lauren@vortex.com or lauren@privacyforum.org Tel: +1 (818) 225-2800 http://www.pfir.org/lauren Co-Founder, PFIR - People For Internet Responsibility - http://www.pfir.org Co-Founder, Fact Squad - http://www.factsquad.org Co-Founder, URIICA - Union for Representative International Internet Cooperation and Analysis - http://www.uriica.org Moderator, PRIVACY Forum - http://www.vortex.com Member, ACM Committee on Computers and Public Policy
A company called Symbiot Security has created "Intelligent Security Infrastructure Management Systems" (iSIMS) that not only provide traditional defensive measures against viruses, worms, and other kinds of network vandalism — but also offer the victims of vandalism a gradual escalation of retaliation measures. These include the ability to flood the attacking computers with data. However, some experts say that retaliatory actions could be a very bad idea. Adrian Vanzyl of the security firm Seclarity comments: "So you are in effect breaking into each of those systems as you follow this person back. Are you legally liable for that? It's a very, very good question." And Dorothy Denning, professor of defense analysis at the Naval Postgraduate School, warns: "We've seen worms that have had major impact like causing delays in airline schedules, shutting down ATM machines, 911 systems and so on. Putting any kind of worm out there would be dangerous." (AP/*San Jose Mercury News*, 18 Jun 2004; NewsScan Daily, 21 Jun 2004] http://www.siliconvalley.com/mld/siliconvalley/8957335.htm
Press release dated June 11 (plus other stories found through Google): http://www.newsroom.ucla.edu/page.asp?RelNum=5275 The story says that a laptop was stolen from the University of California, Los Angeles in 11/2003, containing a database of 145,000 blood donors that was password-protected but not encrypted. The database contained names, birthdates, and social security numbers. The victims were not notified until a week before the story was filed, roughly six months after the theft. The laptop was stolen from a locked van. A second laptop was stolen in late May from an office, putting another 62,000 people at risk — UCLA will notify these people, "...in the next few weeks." Nothing really new here. Question is, when will these stories stop getting resurrected from the grave? Of even more interest to me is that none of my usual sources have popped up with this story; I learned about it during a trip to LA this past weekend, more than a week after it hit the news. Are we getting that blase about this? Aahz (aahz@pythoncraft.com) http://www.pythoncraft.com/
A network vandal has broken into computers at sensitive South Korean research institutes and government agencies, infecting more than 60 PCs with a variation of the Peep Trojan program. The National Cyber Security Center (NCSC) said the hacker had broken into computers at the Agency for Defense Development, which develops weapons, the Korea Atomic Energy Research Institute, the Korea Institute for Defense Analysis and three other government agencies. [*The Australian*, 21 Jun 2004; NewsScan Daily, 22 Jun 2004 ) Rec'd from John Lamp http://tinyurl.com/24wyw
Some time ago, in 2003, CERT announced a WAP service, so you could check current CERT alerts and so on from your phone, at http://wap.cert.org/. WAP hasn't been wildly successful, of course, but all phoes have it, at least in the UK. Since I'm away from home a lot, and I'm responsible for the security of our machines (and sometimes of clients' machines too), I thought it would be useful: it's nice to be able to check that there is nothing to panic about from a device I carry all the time anyway. This is also potentially a nearly-ideal use of a phone-type interface - the amount of information needed is absolutely tiny (`sendmail issue, patch now!'), and promptness is very important. Push would be better than pull, but you can't have everything. Fortunately, although I put the URL in my bookmarks, I didn't use it very often, because something completely toxic happened. For whatever reason, CERT obviously lost interest in the WAP interface, and *left a static version of it in place*. If you check that URL (from a phone) now, you'll find some information from November 2003, and *no indication at all* that all the information is hopelessly out of date. This is the worst possible scenario for a system like this. A system which is meant to be providing alerts of some kind needs to either work, or fail in such a way that its users know it's failed. This is the equivalent of the coolant level meter reading `full' while coolant pours from some fractured pipe and the core melts. If the coolant meter is broken it's way better to have sparks and smoke pouring from it than for it to quietly repeat the last reading... I'd urge anyone who provides security information over the net to arrange life so that when the system breaks or they lose interest, it fails in a way that is extremely visible to its users.
http://www.billingsgazette.com/index.php?id=1&display=rednews/2004/06/19/build/wyoming/55-arrest.inc Summary: A vacationing Wyoming teacher's aide was rousted from her cruise ship bed, shackled and dragged into federal court based on information in a federal warrant database that wrongly accused her of failing to pay a fine after she was cited in a US national park last year. The RISKS: Federal agents apparently blindly relied on the database, even though the court had a copy of the citation showing she had paid. The US Attorney even continued to ask for the woman to have to appear in court in Wyoming after being told that the citation showed she had paid, and standard procedure for the park is that visitors must pay fines before they can leave. Clearly, federal law enforcement authorities continue to place too much reliance in computer databases and not enough on the information in front of them. Further, the fine was a matter of US$50 for failing to properly store her hot chocolate and marshmallows, yet the federal authorities saw fit to drag the woman out of bed, shackle her like a mass-murderer, and haul her into court.
A repairman working on a soft drink vending machine in Park Place Medical Center in Port Arthur, Texas apparently triggered an explosion which converted the freon in the machine to phosgene gas, a poisonous gas that was used in WWI as a weapon. Reference: (*Houston Chronicle*) http://www.chron.com/cs/CDA/ssistory.mpl/metropolitan/2647290
On the way to work this morning, around 9:45 am I heard a surprising traffic announcement on the radio (WAMU). On this road, one is legally allowed to drive on the right shoulder (aka breakdown) lane until 10am. To indicate when it is permissible, lights over the lane either indicate a red X or a green arrow. Apparently, today the lights were showing red (thus closing down one lane). The announcer indicated that, since it was still legal to drive on the right shoulder until 10am, motorists should ignore the computerized signs and drive on the right lane anyway. It wasn't clear whether the insight into letting motorists decide to ignore the signs was made by the announcer or Virginia state police; however, it doesn't seem like a good idea to train motorists that the only reason why the lane might be closed is because of computer malfunction and thus ignore the signs when the motorist "knows" that the lane should be open.
I just completed the process of legally changing my name. I am no longer Erann Gat. I am now Ron Garret. The interesting thing (I have been reading RISKS far too long for this to be shocking or even surprising) is that the only time during the entire process that I was asked to produce any identification was when I tried to pay the court fees with my credit card. If I had paid in cash I could have gone through the entire process without ever having to produce an ID. And, of course, so could anybody else. Ron Garret f.k.a. Erann Gat
Peter da Silva questions who would think autorun a good idea. The answer should be obvious. Most computer users aren't technically sophisticated and want to have "plug and play" devices. A few minutes with market research or support personnel will show that a typical consumer wants to plug a device into a computer and user it. The consumer doesn't want to have to perform a software installation step using a CD which was probably lost months ago, nor answer a bunch of "do you want to enable this device you just plugged in" questions. Anybody with non-technically inclined relatives who's been asked to help setup a system should also see the reasons for plug and play features. Obviously this opens up security concerns. Autorun is subject to abuse. So is the lack of autorun (just create a CD with a virus named "setup" and tell the user to install it). There is a fundamental conflict between security and convenience. Many common system features are security holes such as programmable access to network features, copy/paste clipboards, I/O redirection, and allowing default "other read" file access. Most features which allow one to do useful work can also be abused. Similarly, the feature of the automobile which allows one to travel faster than a walk also allows one to be more easily killed in a collision. In the same Risks edition, Aahz objects to labeling Verity technology as data mining software. Yet in some sense, any search program is a form of data mining. And as with any search, it can be used (find the best price for product X) and abused (find all information about John Doe).
Fred Cohen mentions wanting to be able to prove things like "the green lights will not be on in non-parallel directions at traffic lights". One thing software professionals must always remember, and may easily forget, is that software is dependent on hardware. No amount of software will protect against a short in the hardware, and even with fault tolerant techniques one must ultimately ensure that the hardware is properly designed or provides the proper interlocks. In the traffic light case, while software may be cheaper, hardware interlocks may ultimately be the most reliable solution.
> ... when I dial a number I know is good, I get the message that I am calling a disconnected number. This sounds similar to a problem I have. Here in BC, in November 2001, we switched to 10-digit dialing, where you always have to dial the area code even if your area code is the same. If you get it wrong, you get a polite message telling you that you need to redial with the "604". The problem is that I occasionally get the same message when I have dialed the 604. Just as Jerry described, I hang up, press "redial" and the call goes through. I haven't actually bothered trying to report it. In this age of Windows, "try it again", "it worked that time", "well ok, then. Goodbye" seems to have become the norm.
BKSECWRR.RVW 20040509 "Security Warrior", Cyrus Peikari/Anton Chuvakin, 2004, 0-596-00545-8, U$44.95/C$65.95 %A Cyrus Peikari %A Anton Chuvakin %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 2004 %G 0-596-00545-8 %I O'Reilly & Associates, Inc. %O U$44.95/C$65.95 800-998-9938 fax: 707-829-0104 nuts@ora.com %O http://www.amazon.com/exec/obidos/ASIN/0596005458/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0596005458/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0596005458/robsladesin03-20 %P 531 p. %T "Security Warrior" The preface isn't a really clear piece of writing, but does, eventually, get around to stating that the book focuses on security from an attack, rather than defence, perspective. I have, in numerous other reviews, pointed out the errors and limitations in this position. Part one deals with cracking software, primarily involved with breaking copy protection. Chapter one explains a few concepts about assembly language quite well, and then ends abruptly. Some Windows tools for reverse engineering are listed in chapter two, plus a couple of poorly explained examples. The material on reverse engineering in Linux is longer and more detailed, but still has very limited tutorial value, and is padded with extensive code listings of dubious worth. Chapter four is supposed to deal with reverse engineering for Windows CE, but contains an odd mix of CE operating system architecture, a partial list of ARM CPU opcodes, and a description of how to crack the registration code check in a program written solely to allow you to crack the registration code check embedded within it. Overflow attacks, in chapter five, explains buffer and other overflow conditions, and gives an example of a buffer overflow as a crack in another fake program. Part two presents information about networks. Chapter six is a rather unstructured overview of TCP/IP and a listing of some sniffing tools. (TCP is explained before IP itself, and the relationship of the various protocols in the suite is not discussed. A section on "covert channels" emphasizes a strange misuse of header fields, and then drifts into something like session hijacking.) Social engineering can be used in a variety of ways, so it is strange that chapter seven should be here rather than in the "Advanced Defence" of part four. The random content provided has little organization and a fair number of errors: the authors insist that social engineering attacks can be divided into active and passive types, but, by its nature, social engineering is almost entirely active. (The book does seem to tacitly admit this: there is a list of example "active" attacks, but no corresponding "passive" list.) Chapter eight mentions a few methods of reconnaissance with differing levels of detail. Some more advanced techniques for identifying the operating systems in chapter nine, but the particulars are similarly inconsistent. Part three lists attacks against specific platforms. The authors betray their lack of study once again in chapter eleven: UNIX is *not* "reborn from" MULTICS (although it was heavily influenced), and TCSEC (the Trusted Computer System Evaluation Criteria) is definitely *not* the Common Criteria. The various security related aspects, tools, and hardening of UNIX are not bad, but lack definition. The UNIX attacks listed in chapter twelve are good: ironically, because of the generic nature of the descriptions the examples are probably useful as a guide to defensive measures, rather than being outdated tricks. The Windows client attacks listed in chapter thirteen, because they are specific, have limited the material both in scope and utility. Chapter fourteen, listing Windows server attacks, notes some interesting security bugs in Server 2003 and other programs (and one bit on smartcards.) "SOAP XML Web Services Security," in chapter fifteen, is a long title for a short piece on XML digital signatures. "SQL Injection," in chapter sixteen, has some examples of malformed data attacks, and also points out the dangers of adding programming functionality to applications. As with social engineering, the tie to networks is thin, seemingly limited to the PHPNuke program. Some aspects of wireless antennae, sniffing, and a brief review of the weaknesses in WEP (Wired Equivalent Privacy) are in chapter seventeen. Part four looks at more advanced defence. Miscellaneous thoughts on logging are in chapter eighteen. Chapter nineteen has a confused explanation of intrusion detection systems (IDS). There is no mention of rule (or activity monitoring) based engines, signature based engines are said to be restricted to net-based IDS, different terms are used for anomaly detection engines on hosts versus networks, and there is a muddled attempt to tie Bayesian analysis to odd mathematical ratios of false positive (false rejection) and false negative (false acceptance) errors. The installation of a simple honeypot is described in chapter twenty (which probably *should* be in part two). There is a good initial outline of incident response in chapter twenty one, but it breaks down when getting into specifics. Forensics and antiforensics, in chapter twenty two, gives some background and tools for data recovery and obfuscation. It is ironic that the book starts out with a quotation from "The Code of the Samurai," stating that "[a]ll samurai ought certainly to apply themselves to the study of military science. But a bad use can be made of this study to puff oneself up and disparage one's colleagues by a lot of high-flown but incorrect arguments that only mislead the young ..." This assessment fits Peikari and Chuvakin's work almost perfectly. There is a lot of interesting information in this volume: if you have limited technical background in the fields examined, you will find that a quick perusal will provide you with some superficial familiarity with the topics. However, the uneven coverage ensures that the information is spectacular, rather than tutorial. The disjointed jumps from one subject to the next prove the technical erudition of the authors, but do not help the reader very much. copyright Robert M. Slade, 2004 BKSECWRR.RVW 20040509 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
Please report problems with the web pages to the maintainer