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…
Dennis Rears will no longer be providing his very valuable .mil/.gov redistribution service. For many years, he has minimized the traffic flow from CSL to those domains, allowing me to send just ONE message for all of his subscribers. MANY THANKS to Dennis. Those of you who were thusly subscribed have now been moved to CSL's majordomo server, as of this issue. This change may entail some new problems. Two people were unable to receive mail sent to a list, and I have given them individual one-of-a-kind subscriptions. Several dozen people had addresses that bounced when sent from SRI. Some of those bounces were apparently already blacklisted even from Dennis's .mil site, and other bounces may be due to sites blocking RISKS from SRI as a result of overly aggressive spam filtering. If you have friends and colleagues who complain that they are no longer getting RISKS, please show them this message, and suggest that they resubscribe at risks-request@CSL.sri.com. The majordomo server still has a few problems with its challenge-response mechanism, mostly due to upper/lower case incompatibility problems and also to certain noncompliant mailers. If you experience any difficulties, please let me know.
The number of identity thefts doubled in 2002, with 162,000 reports of identity theft compared to 86,000 the previous year. However, the Federal Trade Commission says that the rise in identity theft complaints does not necessarily mean an increase in actual crimes — it may simply reflect an increasing public awareness of the problem and a greater likelihood that such incidents are now being reported. But an official of the Michigan State Police points out that many former violent criminals are now using the Internet for identity theft: "They are switching over to white-collar crime because it's more lucrative and they know they will get less time. Identity theft is not necessarily a sophisticated crime." [*The New York Times*, 23 Jan 2003; NewsScan Daily, 23 Jan 2003] http://partners.nytimes.com/2003/01/23/politics/23THEF.html
Crooks, operating in the Birmingham (England) area, are preying on people using public access terminals for Internet banking. The scam came to light after a *Register* reader discovered to his horror an authorised transfer of 6,300 pounds from the joint account he and his wife hold with Lloyds TSB. ... "Lloyds have advised me that there is a large-scale Internet banking fraud taking place, affecting customers in the Birmingham area, and has been ongoing for several weeks. Apparently branches have been alerted," the victim, a company director of a West Midlands Net services firm, told us. "It appears that account details are being harvested from public access points (such as Internet Cafes, and more worryingly, Internet Kiosks)." [Source: John Leyden, *The Register*, 27 Jan 2003; PGN-ed] http://212.100.234.54/content/6/29054.html
The "/Trivial/ Risks of Technical Arrogance" post in RISKS-22.46 reminds me of a personal frustration, related to a game which *should* work on a recent operating system, but which, due to some apparent oversight by the programmers, simply refuses to run. A certain popular video game, originally released on a rather failing console system but later re-released on the PC-- I won't mention it by name, but let's just say that its main character is a blue, spiny, fleet-footed anthropomorphic animal-- can even now be found in the discount racks of many software stores for $10 US. I bought this game before I upgraded to Windows XP; it was quite fun, and under Windows 98, it played exactly like the console version. However, after I upgraded to XP, I discovered a sad truth about the game: it DOES NOT work on that operating system at all. Anywhere beyond the title screen, it causes a General Protection Fault in one of the old, obsolete DLLs used by the game, *even in the strictest compatibility mode that XP provides*. Technically, this is covered on the system requirements-- which state "Windows 95/98"-- but there is nothing on the manufacturer's site mentioning an incompatibility with XP (something one generally wouldn't expect, given that every other Win98 game I've played works almost flawlessly in the new OS). If the game in question were so-called abandonware — that is, having gone out of production years ago — I'd excuse it. But, as I mentioned, it can be found on store shelves at this very moment, and if I recall correctly, was also re-released in unaltered form either last year or the year before in a compilation. And yet "Earthworm Jim", whose PC version was released even *earlier*, works absolutely fine in XP. Go figure...
Simon Vallor, from Llandudno, Wales, was sentenced two years in prison by a London magistrate who said that Vallor's actions "cried out for the imposition of a deterrent sentence." The judge brushed aside Vallor's request for leniency, saying: "These offenses were planned and very deliberate. Frankly, when you go to this trouble to make a sophisticated virus, programmed to leave damage this week, next week and the week after, it is absurd to claim you do not intend to do harm. These were by no means isolated offenses and they were committed over a period of time." Vallor wrote the viruses called Admirer, Redesi B, and Gokar, and was judged to be responsible wreaking damage in at least 46 countries. [*The Western Mail*, Wales, 22 Jan 2003; NewsScan Daily, 24 Jan 2003] http://shorl.com/hydragryhogrebro
A rapidly spreading computer worm infested networks and bogged down Internet traffic across the globe on Saturday, crippling online services in one of the world's most wired countries, South Korea. Called "Sapphire" or "SQL Slammer," the worm carries a self-regenerating mechanism that enables it to multiply quickly across the web, said Mikko Hypponen, manager of anti-virus research at F-Secure, a Helsinki-based computer security firm. [Source: Jane Macartney and Bernhard Warner, Reuters, 25 Jan 2003] http://finance.lycos.com/home/news/story.asp?story=31132872
The bandwidth-crunching Slammer worm caused all manner of damage since its
appearance on the Net in the early hours of Saturday morning. The spread of
the worm was so severe that the majority of Bank of America's 13,000
automatic teller machines "were unable to process customer transactions",
according to *The Washington Post* — which quotes the bank saying it was
able to restore services on Saturday evening but a Seattle-based Reg reader
tells us he was "unable to make a deposit to my Bank of America Account on
Sunday at about noon Pacific time".
[*The Washington Post* article is not explicit about why the worm disrupted
the ATM network. Whether the ATMs are attached to the Internet or whether
the BoA server used by the ATM was infected, this does not sound very
comforting.]
REFERENCES:
ATMs, ISPs hit by Slammer worm spread, by John Leyden, 27 Jan 2003
http://www.theregister.co.uk/content/6/29054.html
http://www.washingtonpost.com/wp-dyn/articles/A43267-2003Jan25.html
Over the weekend the SQL Slammer worm wreaked havoc across the Internet.
As usual the two most common responses are:
1. Blame Microsoft for producing code with holes in.
2. Blame the sysadmins for not patching systems.
[and 3. Nobody blames the anti-social [deleted] who wrote it]
Of course, (1) is a little unfair as Microsoft patched the hole
six months ago. (2) seems to be a more reasonable response.
At risk of being flamed, I would like to suggest that it isn't.
We are frequently reminded in RISKS that we need to balance our
viewpoint. There are risks in using technology, and risks in not using
technology, and we need to accept that there is a tradeoff between the two.
This is a case in point. When a Service Update is applied to a system, a
number of things are introduced:
- Bug Fixes
- New Bugs (due to changes in the system)
- New Code Behaviour (also due to changes in the system)
In theory, when a Service Update is applied to a computer, the Applications
that are affected by the Service Release need to be re-tested to make sure
that the Application still works correctly with the new level of the
Operating System/DBMS.
Because Service Releases have such a wide scope this can be difficult in a
development environment and near impossible in the live environment. In any
case, testing takes time.
The requirement to maintain a "Stable Production Environment" may mean that
some Service Releases cannot be applied, regardless of what holes they fix.
This is not just a vague generalisation. I have seen systems I maintain
brought down by DBMS Service Releases. There are also many examples that
have appeared in the Risks Digest.
Our current system is held at a very old release because the next Service
Release WILL break the application. This will require extensive work to find
out all the places where code fixing is required.
Note that I am not saying that Service Releases should never be applied, I
am saying that they should never be applied blindly.
It's unlikely that there will be much additional destruction from the so-called Slammer computer worm that wreaked damage on the Internet over the weekend, by infecting more than a quarter of a million computer servers and clogging networks throughout the world. The worm targeted a known virus in Microsoft's 2000 SQL server database server; the company had issued software security patches in July 2002, but many network administrators had failed to install them. But now the worst appears to be over, says an executive at the security firm Symantec. [*USA Today*, 27 Jan 2003; NewsScan Daily, 27 Jan 2003] http://www.usatoday.com/tech/news/2003-01-26-networm_x.htm
'Slammer' Feared to Strike Again Michelle Delio, Wired.com, 26 Jan 2003 The global worming attack that fried much of the Internet this weekend may return on Monday as unpatched systems and applications boot up at the start of the workweek. The worm can attack a multitude of Microsoft applications as well as applications distributed by other companies including administration, helpdesk, corporate antivirus and assorted security applications. Network administrators may not even be aware that their systems harbor programs that need to be patched. ... http://www.wired.com/news/infostructure/0,1377,57409,00.html
By one account, some Canadian government agencies were embarrassed to have been caught off guard by the so-called SQL Slammer, a string of self-replicating computer code spread through data servers using Microsoft SQL [Server]. Royal Bank of Canada, Bank of Montreal and Canadian Imperial Bank of Commerce all reported virus-related glitches on Saturday. RBC's telephone and on-line banking systems were down for hours, and some CIBC and BMO cash machines worked sluggishly or not at all. Toronto-Dominion Bank also had problems but gave no details. Bank of Nova Scotia said its systems were unaffected. [*The Globe and Mail*, 26 Jan 2003] http://www.globeandmail.com/servlet/ArticleNews/front/RTGAM/20030126/winterna M Taylor http://www.mctaylor.com/
CERT Advisory CA-2003-04 MS-SQL Server Worm http://www.cert.org/advisories/CA-2003-04.html Cisco Security Advisory: MS SQL "Sapphire" Worm Mitigation Recommendations http://www.cisco.com/warp/public/707/cisco-sn-20030125-worm.shtml SQL Sapphire Worm Analysis http://www.eEye.com/html/Research/Flash/AL20030125.html Microsoft SQL Slammer Worm Propagation http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21824 Unauthenticated Remote Compromise in MS SQL Server 2000 http://www.nextgenss.com/advisories/mssql-udp.txt Sapphire SQL Worm Analysis http://www.techie.hopto.org/sqlworm.html Sapphire SQL Worm Scanner Tool http://www.eeye.com/html/Research/Tools/SapphireSQL.html Slammer slugs Internet, down but not out http://www.infoworld.com/articles/hn/xml/03/01/25/030125hnsqlnetupd.xml
Matt Blaze has recently written (in http://www.crypto.com/masterkey.html and http://www.crypto.com/papers/mk.pdf) about his discovery of a vulnerability in master-keyed mechanical lock systems. The paper is a well-written and detailed exposition of the technique, and will serve well to educate readers both about the workings of mechanical locks and about this particular attack. However, the attack may not be as exciting and ground-breaking as claimed. For example, a friend and I figured out how to do this in high school, but we realized that it would be much more time-consuming and persnickety than other attacks that were practical in that environment. As for whether the attack uses "cryptanalytical techniques", that claim is hard to justify unless you consider "cryptanalytical" the most appropriate term for recursive exhaustive search. It's hardly surprising that the technique is not widely covered in locksmithing texts. That's because it isn't particularly useful in legitimate contexts. No locksmith would ever bother going through all that rigmarole when he could instead disassemble the lock and read the master key directly--which is almost always possible if one has both a legitimate purpose and a legitimate key. Given the generally low quality of original work in the underground community, I'm not very surprised that it's not well-known there, either. Most techniques I've gleaned from there have fairly clear origins in the adult world. That's not to say that execution by the underground isn't clever--but finding the 99th new buffer overflow in Internet Explorer is more a matter of persistence, I think, than it is of original thinking. After all, buffer overflows have been well-understood as a security flaw for over 30 years. The "MIT Guide to Lockpicking", for instance, is a clear and educational exposition of lockpicking, but doesn't present anything that hasn't been well-known in the locksmithing trade since before the invention of computers. The basic vulnerability--that there are many more keys which will open the locks in a masterkeyed system than are ever actually delivered with such a system--IS well-understood and publicized to the trade. Locksmithing texts (some, at least) explicitly warn about deploying different masterkey systems in the same geographic area that use the same kind of keys, for that very reason. Lock manufacturers sell recommended keying patterns that are explicitly designed to avoid the problem, and I'm sure there is computer software that locksmiths use today for the same purpose. A more interesting question is how to deduce the master key when you *don't* have a legitimate change key. That, too, is something we understood in high school, and it involves deducing patterns from several (temporarily) disassembled locks. Here, there's something resembling a geniune (although not especially difficult) cryptanalytical problem, in that one must deduce the pattern the lock manufacturer (or installer) used to assign the keys, and the manufacturer in turn can try to make that pattern difficult to deduce. That's the technique we used in actual practice, and it was an absorbing intellectual challenge at age 16. The observation that customers aren't warned about this problem, well, that's hard to assess. One could make the same complaint about not warning customers that most mechanical locks can be picked in a few seconds. Fortunately, a lot of contexts where this is an issue (such as hotels) have already converted to different technologies that may be more secure.
When the original paper on Computer Viruses was sent to CACM for possible publication, they spent a year debating whether it should be considered for publication because of the potential harm that could be caused by people knowing about the vulnerability. I was so disgusted that I have not sent a paper to the ACM since that time. Fred Cohen - http://all.net/ - fc@all.net - fc@unhca.com tel/fax: 1-925-454-0171 Fred Cohen & Associates - University of New Haven
Congratulations to Matt Blaze for his extraordinary discovery about the vulnerability created by many master keys and especially for his forthright decision to publish his findings - after carefully weighing all of the consequences. The usual responses have been to keep findings like this a big 'secret' or to disclose the findings without any responsible planning or precautions.The critical messages he is receiving from the ostriches in the business are variations on a theme we have seen in other contexts. Matt tells it like it is, and he's a hero for doing so. Robert Ellis Smith, Privacy Journal, PO Box 28577, Providence RI 02908 ellis84@rcn.com 401/274-7861 http://www.privacyjournal.net fax 401/274-4747
A slight clarification. CSS-- the encryption used on DVDs-- was not designed to prevent the duplication of DVDs, illegal or otherwise. One can easily perform an 'image copy' of a DVD and the resulting copy will play just fine. On a Macintosh, it is trivial to create a disk image-- a virtual piece of media-- of any filesystem, including a DVD. The "virtual DVD" plays just fine and has the added advantage of lowering power usage on portable systems. CSS is intended to prevent unlawful access to the content in three ways. First, it makes it possible to enforce region codes in that it is [was] impossible to decode the content without a licensed-- and likely region locked-- decoder. Region locking prevents a DVD targeted for the Japanese market from being played on a DVD player sold into the US market. The motivation behind this is to supposedly prevent cannibalization of sales between different units of large distribution companies. That is, Capital Records' US division does not want folks in the US purchasing something from Capital Records' UK division. Second, it hinders direct lossless access to the contents of the DVD. This prevents folks from directly stealing the content and producing a derivative work. It also hinders digital to digital conversion to other, smaller, formats such as Video-CD (VCD's are hugely popular in the far East). Finally, CSS provides a much greater degree of control over the distribution of content. This allows the content producers to tightly tune release cycles, marketing, etc.. to the business climate in a particular market. That is, they can charge what the market will bear in the target region. It also allows the media companies to control the production of the playback devices-- the content decoders. If you want to market and sell a DVD player, you have to buy a very expensive decryption key from the agency that controls CSS decryption keys [I believe it is the MPAA, but I'm not sure].
BKAUINSY.RVW 20020825 "Auditing Information Systems", Mario Piattini, 2000, 1-878-28975-6, U$139.95 %E Mario Piattini %C 1331 E. Chocolate Ave., Hershey, PA 17033-1117 %D 2000 %G 1-878-28975-6 %I IRM Press/Idea Group %O U$139.95 717-533-8845 fax: 717-533-8661 cust@idea-group.com %O http://www.amazon.com/exec/obidos/ASIN/1878289756/robsladesinterne %P 246 p. %T "Auditing Information Systems" Chapter one is a general overview of auditing, with few details. COBiT is not being used as intended by the majority of purchasers, we are told in chapter two. There is a rather random discussion of some security (and some network) concepts in chapter three, which changes format rather abruptly towards the end. Chapter four notes that software maintenance has dangers and a structured process would help. It also suggests a COBiT style list of objectives. All kinds of things it would be nice to have in the perfect data warehouse are described in chapter five. Chapter six looks at a few legal issues with respect to information. The theme of chapter seven seems to be that databases should do what they are supposed to. (I suppose Gene Spafford could sympathize: his definition of a secure computer is one that does what it is supposed to.) Chapter eight attempts to recreate ISO 9000 as a COBiT table. Task analysis by another name (audit function points) is described in chapter nine. Even though the name of COBiT is repeatedly invoked in this book it is really hard to say what it has to do with auditing. copyright Robert M. Slade, 2002 BKAUINSY.RVW 20020825 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
BKIISMRS.RVW 20020825 "Internet and Intranet Security Management", Lech Janczewski, 2000, 1-878-28971-3, U$69.95 %E Lech Janczewski %C 1331 E. Chocolate Ave., Hershey, PA 17033-1117 %D 2000 %G 1-878-28971-3 %I IRM Press/Idea Group %O U$69.95 800-345-432 fax: 717-533-8661 cust@idea-group.com %O http://www.amazon.com/exec/obidos/ASIN/1878289713/robsladesinterne %P 302 p. %T "Internet and Intranet Security Management: Risks and Solutions" There is a heavy emphasis, in the preface, on the book's being up to date. Yet the very first article relies on survey data that was three years old at the time the essay was written. Part one supposedly talks about the state of the (security, one assumes) art. Chapter one is a vague and superficial look at random topics and technology related to security, plus results of the aforementioned opinion poll. A list of Internet security problems, and solutions that are not connected to the difficulties, make up chapter two. Part two deals with managing Internet security. Chapter three has terse descriptions of a number of theories of trust, related to some generic security concepts. There are brief overviews of the TCSEC (Trusted Computer System Evaluation Criteria), Common Criteria, and not-really-the-BS7799 in chapter four. Out of thirty three pages in chapter five, three discuss the general subject of Web security, while there is almost nothing on the titular topic of management of Web security. Part three reviews cryptographic and technical security standards. (There are a great many grammatical errors, and the authors use almost-but-not- quite standard terminology.) Chapter six is an opinionated piece, but does touch on some basic cryptographic ideas. Myths and limitations of cryptography are listed in chapter seven. Chapter eight has descriptions of ISO cryptographic standards, both overly technical and incomplete. Part four talks about law and security. Chapter nine discusses privacy, but only in regard to employer monitoring of employee email. The weaknesses of the New Zealand privacy law are commented on in chapter ten. It is difficult to say that any audience would benefit from this vague collection of unfocused ideas. copyright Robert M. Slade, 2002 BKIISMRS.RVW 20020825 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