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…
When the US Navy forgot to renew registration on NavyDallas.com - apparently because Network Solutions forgot to send them a renewal notice - it was snapped up by a pornography site. NSI accepted the new registration despite the new owner being identified simply as "Bog". Meanwhile, NavyBoston.com now directs users to an eBay auction site: http://www.newsbytes.com/news/02/176741.html Porn hijacking is annoying, but at least it's pretty obvious. IIRC RISKS has previously mentioned some of the nastier things that can be done when someone has the opportunity to impersonate a 'trusted' domain, and allowing somebody to do so without even giving reasonable contact details looks like a recipe for trouble. Geoffrey Brent - g.brent@student.unsw.edu.au
Hackers gain entry to key state database Ryan Kim, *San Francisco Chronicle*, 25 May 2002 Computer hackers have cracked into the state's personnel database and gained access to financial information for all 265,000 state workers, including Governor Gray Davis, officials said Friday. The database, housed at state's Teale Data Center in Rancho Cordova, holds names, Social Security numbers, and payroll information for everyone from office workers to judges. Authorities said that so far they have found no evidence that the information has been used illegally. <http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2002/05/25/MN179392.DTL>
Thomas C Greene in Washington, The Register 27 May 2002 http://www.theregister.co.uk/content/55/25444.html The face recognition system in experimental use at Palm Beach International Airport on 15 volunteers and a database of 250 snapshots. The success rate is less than 50%. Extrapolations also suggest a false-positive rate of about 50 passengers a day for a single checkpoint handling 5,000 passengers. "Eyeglasses gave the system a great deal of difficulty, in spite of copious Visionics marketing hype denying this particular glitch. Small rotations of the head, fifteen to thirty degrees off the camera's focal point, also bamboozled it repeatedly, and the lighting had to be just right." [PGN-ed for RISKS. For Dave's IP archives see: http://www.interesting-people.org/archives/interesting-people/ ]
Re: WashDC database crash linked to a death by a falling tree (R 22 08), here is another computer angle on dead tree branches: http://nu.nl/document?n=57035 (dutch only) [Loose translation] The Dutch city of Bloemendaal is going to implant chips in all its trees. With a portable computer, it will become easy to track the trees' health. The city thinks this will make tree maintenance cheaper and better, allowing trees to remain healthier and live longer. Each chip contains a unique ID. Each tree's data is stored in a portable computer. The cost reduction is in not having to carry big stacks of paper and maps around while monitoring trees' health. More can be done in less time, and it will be easier to track exactly what maintenance was applied to which tree. Added bonus is that when a dead branch drops on a car, the city will be able to show that this was not caused by lack of maintenance. Cost of implanting all trees with these so-called "transponders" is 56.722 euro. Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/> [Note that linguistically, a "transponder" is anything that works across the pond (familiarly, the Atlantic Ocean). PGN]
In a newsletter sent to 40,000 recipients, I included a block of HTML code showing a forged header. The e-mail list software spotted what it thought was the end of the document and inserted the e-mail address of each recipient in that person's copy of the newsletter, making many readers believe that their e-mail address had been distributed to the entire list. Result: hundreds of letters (some nice, some not). LESSONS: (1) When designing macros that scan for search strings associated with a particular condition (in this case, the end of a message), it would be wise to test the presumption that the condition is in fact true. In this example, perhaps a second check might verify that there is in fact no further text in the message before inserting the valediction. (2) When quoting control language (in this case, HTML), and in the absence of some sort of escape character (meaning "the following is literal text, not command language"), we may avoid accidents by using symbol substitution to prevent accidental misreading of the quoted strings as if they were actually to be interpreted. M. E. Kabay, PhD, CISSP — AssocProf Information Assurance, DeptCompInfoSys, Norwich University, Northfield VT http://www2.norwich.edu/mkabay/index.htm
``For about 45 minutes on 14 May 2002, visitors to the United Airlines Web site were able to buy roundtrip tickets for $25. United blames it on an error by a computer that distributes fares for major airlines... It's not the first time United has sold $25 tickets on its site. In January, 142 passengers bought tickets to international destinations for as little as $25.'' However, from the article, it sounds like it may have been due to human error, because ATP Co., the clearinghouse that distributes new sale fares to their Web site, was trying to fix a problem where a $5 online discount was not reflected in the sale prices but ended up loading all prices but the actual fare itself. So the $25 includes just the "taxes, facility charges and a $5 surcharge". Full story: http://www.cbsnews.com/stories/2002/05/15/national/main509107.shtml
I strongly disagree. The CD is not "corrupted"; it contains an additional data partition, with malware on it. It is a trojan horse, because you execute that malware when you are trying to do something else. It prevents normal use of the CD (playing it for one's listening pleasure in a CD player, if that CD player is controlled by a computer). I've listened to audio CDs on computers a handful of times, not many; but I've never extracted any audio data from them, because I don't need to because I already have the data (on CD). I imagine that a great many RISKS readers are in a similar situation, as are the majority of the victims of these malware CDs. It prevents the regular use of the product with the consumer's choice of equipment, like any "embrace and extend" technological maneuver.
Apple has apparently softened their original position. I followed the link provided in the article, and found this end note, instead: If a disc with copyright protection technology remains inside the drive after following the procedures above, or if the computer does not start up normally, it is recommended that you contact an Apple Authorized Service Provider (AASP) or Apple Technical Support. Audio discs that incorporate copyright protection technologies do not adhere to published Compact Disc standards. Apple designs its optical disc drives to support media that conform to such standards. No mention of repair fees or the like, so I'll assume they will cut users some slack the first time they bring in their machines for service. Benjamin Robinson bjr7@freenet.tlh.fl.us
How's this for a possible scenario? - A Ford employee walks away from a workstation without locking it first. - A watchful contractor/employee/visitor/whoever walks up to the system with a prepared, custom-burned CD in hand. - S/he pops the CD in, and an autorun program loads and immediately ejects the CD. - The perpetrator takes the CD, closes the tray, and walks away within 10 seconds of approaching the workstation. - The program that was just loaded goes to work in the background. - The original employee returns with a fresh cup of coffee and resumes working, unaware that anything has happened. - Later, at home/cafe/wherever, this person connects to the zombified system (which has opened a path to itself through the firewall) and gets busy. Sound farfetched? No. Any programmer with the proper motivation (13,000 credit reports are very motivating), a few bits of publicly-available developer knowledge, a simple development system, and a cheap CD-R drive could do just that. All firewalls have the same basic weaknesses that can be taken advantage of, as long as the activity initiates from inside. The most secure Internet connection is no Internet connection at all. This is all just informed speculation, but an office is only as secure as the weakest habits of its employees.
This reminds me of an incident that happened not too long ago on the University campus (in the UK) that I attended. The vending machines on campus were the style where you can't see the item (Chocolate) before it is dispensed - you dial a two digit number and it gives you the product or tells you it's out of stock or how much it costs as appropriate. The machines usually had about 10 varieties of chocolate/chewing gum in them, so the valid entries were typically in the range 10-19 although some had more or less choices. It seems some of the machines had been misprogrammed and some debt-ridden students had discovered that some of the higher numbers (80+) dispensed chocolate with the incorrect prices. Some of these prices were very high but others were ridiculously low - a few pence (less than 10 cents) per item. Some even had a zero value! As you can imagine, it does not take long for news like this to spread and very quickly everyone knew if you wanted free or cheap chocolate and didn't care what you got then you could just walk up to the nearest machine and start punching buttons at random until you got something. What is even more surprising is that the engineers that came to fill the machines with food and empty the cash did so several times before someone actually came along (A different engineer) and reprogrammed all the machines to fix this problem. I'm surprised this problem hadn't been discovered before at other sites, so I suspect either we had a badly setup batch of machines or the problem was known about but they didn't have the resources to reprogram every machine just in case. The Risks here are obvious - as with almost every other Risks item, buggy software doesn't just cause bad PR, it can cost money!
FYI, here is some info on the architecture of (admittedly older) vending machines: Consists of the executive (typically the note acceptor/coin box) which controls the peripherals (typically the dispenser which also displays prices and come-on message, accepts your selection choice and vends the products). All these components are separate devices communicating via a shared bus. The executive controls the peripherals via a query-response protocol (either Protocol A or the newer MDC protocol). Neither of these protocols are particularly well-define in terms of exception handling. Moreover, manufacturers' implementation of these protocols can differ significantly (what a surprise). The executive will tell the dispenser, for example, how much credit is available and when to vend (but _not_ what to vend). If memory serves, the protocols define the acceptable states of a peripheral. E.g., the dispenser may not vend until it has received a 'credit' message. If one selects a product before the dispenser has received such a message the dispenser will (usually) display the product's price. I'll leave it as an exercise to the reader to find as many RISKy (<groan>) scenarios as (s)he can with this setup. >The risks? I suspect that the software that went in to the machine was >tested by the programmer and not tested in the field before being released >-- though the only way to find out would be to ask. Not doing real-world >testing is a common risk but this fault was dumb and should have been easy >to catch before the software was released. Hhmmm...i'm not so sure. As for all timing-related errors (such as this), testing for them reliably can be tricky. Even worse is the differences between different manufacturer's vending peripherals (and their 'adherence' to the vending protocol). We've had the situation where our executive works reliable in 2 different types of vending machines only to fail horribly in the third type (from the same manufacturer). > [Just wait until the thing starts accepting debit and credit cards. More > good ways to make the software fail! }:-} ] The company I currently work have an executive that uses a smartcard as the payment token (in a closed payment system). At least this method has the advantage of being offline (i.e. doesn't have to communicate with a bank to authorise the payment) which supposedly reduces the risks of fraud (hah!).
Of course there is an obvious risk with Vipul's Razor: corruption of the black list, either by accident — it just takes a single provider to pipe all mails through the reporting script — or on purpose, to prevent others from receiving a certain message, such as a virus warning. Collaborative filtering with trusted co-readers can be very helpful, not just for spam tagging but general rating of information, yet I prefer to not let every stranger in the world filter my e-mail. Klaus Johannes Rusch KlausRusch@atmedia.net http://www.atmedia.net/KlausRusch/
As a ***VERY*** happy customer of SpamAssassin, I was interested to see you've adopted it for the RISKS list. Note that Kevin's (nobody@tex.kom) advice should not be necessary -- SpamAssassin already incorporates (and scores appropriately) information from the Vipul's Razor system.
> How did her mobile phone make a call by itself at 5am? I have had a similar event occur, and often it is related to the phone call blocking caller ID. Take my cell phone, a Nokia 6210 for example. It has caller ID capability here in New Zealand. If the number is not blocked, it will display the number and log in a register of the 10 most recent received/missed numbers. If the number is blocked, then it is not added to the register. However, if you miss a call, it will provide a 'list' command that will display the number of the most recently missed call from the missed call register. This works fine if last call had a called ID number that was added to the missed calls register. If the last call had a blocked caller ID, then no number was added to the top of the register, and if you hit list, the top of the register displays the last valid caller ID number before that. So all that had to happen was for you mum's last recorded caller ID call to be from her mobile to her home, and then then next call to be from a caller ID blocked phone, and it is possible that the displayed number was the last previous identifiable number, rather than the last actual call. Of course this depends on her caller ID unit, and what I've noted from my cell phone, my not be applicable towards her caller ID unit.
Largely as a result of the previous postings on this list, I decided to get my act together and re-install the anti-virus scanning for my ISP. (The last time I turned it on, a configuration error caused the anti-virus to eat several thousand email messages, so in the meantime I had developed some automated email testing tools.) In any event, I'm stunned. My ISP has less than 1500 active mailboxes, but we're receiving several copies of W32/Klez-G per minute. Some users are actually receiving 30-60 copies of this virus every day. (Hopefully they are running their own anti-virus...) It just goes to show the danger of a monoculture. More than 50% of the viruses are being sent by one or two people who have cable modems. It makes you wonder if there should be any liability for these individuals.
This is very strange, because I have had exactly the opposite experience. I have one confirmed case of the envelope address indicating the actual sender of the infected message — the envelope sender matched up with the Received lines, and when I spoke to the envelope sender, who is a friend in town and thus easily reachable, he confirmed that his computer was infected. In the vast majority of the other copies of this virus I've received, the envelope sender has matched up with the Received lines, and none of the so identified individuals whom I've contacted have responded with a claim that their machines were actually not infected (although they also have not responded to confirm that they *were* infected). Perhaps there is a new Klez variant that I haven't yet seen, which forges the envelope sender as well?
A machine I co-administer recently suffered what at first looked like a mailbomb attack. On further investigation, it seems that it was probably a side effect of the Klez worm, possibly unintended but rather destructive. As was explained in a previous issue, the Klez family send e-mail from an infected computer A to an address B, with the From address forged as a third party C. B and C are selected apparently at random from the address book of A, or possibly other sources. Any bounce messages caused by the attempted delivery to C will be sent to B. Readers will probably have suffered over the last month mailboxes full of not just Klez worms but also bounce messages or auto-generated virus warnings. (Incidentally, one might hope that e-mail anti-virus vendors would be smart enough to send notifications to A rather than B in this case, but apparently many are not.) If both addresses B and C are configured to auto-reply to messages, then a rather more destructive mail loop can occur, producing network traffic and also filling mailboxes or databases at both ends. In the particular attack we observed, B was a robot that sent instructions about an FTP archive, and C was a bug-submission address that sent automatic acknowledgements. Of course, mail loops are always a risk when programs automatically generate e-mail. They can be avoided if either program is sufficiently smart to detect and break the loop: the BSD vacation program, and most mail transports agents do this quite well, for example. However, many other programs can't detect loops under some circumstances, particularly if the other party is also somewhat RFC-ignorant: for example, if it drops the X-Loop header, or does not set a Precedence or Sender appropriately. "Untested code is broken code", and many of these bugs have never been thrown up because bug databases don't normally get into arguments with FTP robots. Because Klez picks addresses apparently at random, it kicks off interactions between programs that might never normally occur. In general, the most likely situation for an autoresponder loop is probably an SMTP bounce message, but since most mailers try to avoid loops the autoresponder can get away with only simple checks for loops. When two such robots talk to each other, loops can easily occur. Interestingly, the machines most affected by the event need not be vulnerable to the worm, or even running Windows at all! Like some previous DDOS attacks, the disruption is amplified by the autoresponders, so A sends only one message to start the chain reaction. It seems that some mail autoresponders need to be better defended against conversations with poorly-designed or malicious remote parties. Countermeasures might include setting the reply address to one that will not cause more mail to be sent, and using a global or per-address rate limit.
BKCISPA1.RVW 20020503 "CISSP All-in-One Certification Exam Guide", Shon Harris, 2002, 0-07-219353-0, U$79.99 %A Shon Harris shonharris@hotmail.com %C 300 Water Street, Whitby, Ontario L1N 9B6 %D 2002 %G 0-07-219353-0 %I McGraw-Hill Ryerson/Osborne %O U$79.99 905-430-5000 +1-800-565-5758 fax: 905-430-5020 %P 971 p. + CD-ROM %T "CISSP All-in-One Certification Exam Guide" Chapter one is a very reasonable review of the CISSP (Certified Information Systems Security Professional) credential, and the (ISC)^2 (International Information Systems Security Certification Consortium) exam process, including recertification. As with most of the chapters in the book, it has a set of sample questions, and while I could quibble with some, they cover a decent range of topics and a representative extent of difficulty. There are resources listed in this and other chapters, mostly Web sites. Web sites are, of course, most easily accessible, but they also die on a regular basis, and it might have been an idea to include references to other books on specific topics. It is difficult to see the point of chapter two--an opinion-piece level overview of various security related topics. Chapter three begins the first of the ten domains of the Common Body of Knowledge (CBK) with security management practices. It is obvious that the material has been structured and based on the (ISC)^2 CBK review course, even to the use of specific tables and diagrams, but the material is, at least, enhanced and extended by narrative discussion. Access control is explained clearly (and sometimes amusingly) in chapter four (although biometrics is generally considered to be a form of authentication, not identification). In general, the coverage of security architecture and models in chapter five is quite useful. However, there is too much emphasis on the old "Orange Book" TCSEC (Trusted Computer System Evaluation Criteria) and not enough on the newer Common Criteria. (The inclusion of a section on computer hardware is also a bit odd.) Chapter six has many of the blind spots about physical security common to most computer security types (including some erroneous information about Halon from the old CBK course). The telecommunications and networking material, in chapter seven, presents the underlying concepts well, but for some reason fails to address many of the security technologies. The explanations of cryptography, in chapter eight, are problematic. Fortunately, the content is not necessarily wrong. The author obviously is not familiar with this area, and the text in such areas as DES (Data Encryption Standard) modes and one way encryption doesn't make sense, although it does not necessarily misinform the reader. Chapter nine, dealing with business continuity and disaster recovery, is reasonable, but not as detailed as other sections. Law, Investigation, and ethics is pretty good, although some old crimes and the insistence on the salami scam myth are some notable flaws in chapter ten. Chapter eleven, applications development, contains the basic information but does not always make the connections to security. Operations security gets a sensible review in chapter twelve. The material is much more reliable and better structured than the SRV Press books (cf. BKCISPET.RVW), and much more reliable and complete than the Andress work (cf. BKCISPEC.RVW). Like the Krutz and Vines volume (cf. BKCISPPG.RVW) it is quite obvious that the content and organization is copied from the old CBK course (sometimes slavishly), although Harris does put more explanatory and narrative substance into the text. (Interestingly, there are some indications that this is based on an even older version of the course than Krutz and Vines used.) Even considering the noted weak areas in this book, it should provide a reasonable basis as a study guide for the CISSP exam, although those who use only this work should not expect to get a particularly high mark. copyright Robert M. Slade, 2002 BKCISPA1.RVW 20020503 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