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…
The *NYTimes* on 15 May 2008 has an editorial (We'll Have to Check, Sir) noting that the no-fly list is still populated with names that cause too many false positives. [We've mentioned Senator Edward Kennedy and everyone named David Nelson here before.] One airline reports 9,000 false hits every day, according to DHS head Michael Chertoff. He is proposing each would-be flier provide airlines with his/her date of birth (which would cut down extensively on bogus hits—but ONLY if the person's DoB was given accurately AND if the birthdate of the actual terrorist were known!). The terrorist watch list now contains more than 900,000 names. TSA estimates that 15,000 people have actually managed to get their own names off the list, although the process is reportedly "frustratingly slow".
[Source: Emil Protalinski, ArsTechnica, 15 Apr 2008] Internet users are quite familiar with the Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA), a quick method that verifies whether or not the user trying to sign up is a person or a bot. A picture with swirled, mangled, or otherwise distorted characters is displayed and the user then types in the correct letters or numbers. Thus far, the system has worked well to slow down malicious bots, but recently the groups behind such software have made significant strides. A security firm is now reporting that the CAPTCHA used for Windows Live Mail can now be cracked in as little as 60 seconds. Back in early February, a group cracked Windows Live Hotmail's CAPTCHA. A few weeks later, Gmail's version followed suit. In just over a month's time, some anti-spam vendors were forced to completely block the domain for the popular service as bots signed up for thousands of bogus accounts and began to flood the tubes with e-mail advertisements for lottery tickets and watches. The close proximity of the two cracks has done everything but sealed CAPTCHA's fate. To make matters worse, Websense Security Labs is now reporting that the method for getting around Windows Live Mail's CAPTCHA has been improved to the point that a bot can decipher the text and make a guess in less than six seconds, on average. Windows Live Hotmail's Anti-CAPTCHA automatic bot, which hooks itself into Internet Explorer on a victim's machine, has a success rate of about 10-15 percent. That means that it takes up to one minute for a single bot to create a new account. ... http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html
"A computer hacker in Chile has published confidential records belonging to six million people on the Internet, officials say." Full story at: http://news.bbc.co.uk/2/hi/americas/7395295.stmAmos Shapir
The Dilbert site (www.dilbert.com) wants me to install a special 'widget' to let me see their cartoons. That rings all my alarm bells. Even if honest and safe, it seems a bad precedent. Like some other sites, they want an e-mail address which would presumably get a corresponding entry in my spam filter.
There have been plenty of stories of used laptops and hard drives containing confidential data, and my impression is that even the non technical people I know now understand this risk when disposing of old hardware. But recently I picked up two items at the local Goodwill store for $5 each; a home-style DSL router/NAT box, and a burglar/fire alarm panel, evidently removed during a renovation. Both have user manuals available online, and both contained easily readable data that would provide at least the basis for a denial of service attack, and possibly much more. Although the router was password protected, a particularly bad (but documented) design allows for access to be regained and the existing password to be discovered, all through the browser interface. The router also contained a PPPOE userid and password, and a first name - quite possibly enough for some social engineering, and probably enough to log in to the PPPOE provider and cause trouble. I have seen a number of similar boxes at the same Goodwill, presumably as people change their home networks to WiFi and can't think of anything to use the old unit for. The alarm panel, not a consumer product exactly, but still well documented online, had an account identifier both on a sticker inside and programmed in, and primary and backup numbers for the box to call. In my experience alarm companies will, not unreasonably, respond to alarms from even a closed or delinquent account, since the potential liability for them is very much higher if they fail in error to respond to a real call than if they notify the emergency services and let them attend at the last known address just in case. Risks: Try to give your old hardware a good home, and risk annoyance or worse.
"Computer equipment stolen from an administrative office in Clifton (a neighborhood in Staten Island, NYC) in December contained personal information from 88,000 patients that have been treated at Staten Island University Hospital. After four months with no arrests, hospital administrators are just now beginning the process of sending out letters to patients whose names, Social Security and health insurance numbers were contained in computer files on a desktop computer and a backup hard drive stolen Dec. 29 from the hospital's finance office at 1 Edgewater Plaza." http://www.silive.com/news/index.ssf/2008/04/stolen_computer_contained_info.html This case is a bit different from the standard RISKS story, inasmuch as it's based on a traditional physical theft, and from inside a working office, rather than a car. But it does go to show that the old risks are still around. (There's a side issue of the hospital taking four months before notifying the public, which may actually be in violation of NYS law and federal regs.)
[From Dave Farber's IP distribution, in response to Frode Hegland,
U.K. turns CCTV, terrorism laws on pooping dogs
"The United Kingdom has the most surveillance cameras per capita in the
world. With the recent news that CCTV cameras do not actually deter
crime, how can the local town councils justify the massive surveillance
program? By going after pooping dogs."]
I don't know what is going on with the UK, it's like they're using 1984 as
an installation guide.
In case anyone missed this clever turning of the tables, however, here's the
story of a music band who not being able to afford to produce their video,
performed in front of 80 of the estimated 13 million (public) surveillance
cameras in UK, and then got the footage by filing a request under UK's Data
Protection Act.
http://www.arsgeek.com/?p=3961
Link includes the finished video.
"The Get Out Clause are an upcoming UK band who are currently unsigned.
They took a brilliant and I'm sure soon to be much copied method to
producing their own video. Unable to hire a production crew for a standard
1980's era MTV music video, they performed their music in front of 80 of the
13 million CCTV "security" cameras available in England, including one on a
bus.
They then used Britain's Data Protection Act to request the footage that was
shot of them. Grab some decent and inexpensive video editing tools
(say. . . an iMac) and presto! They got themselves a unique and in my
opinion quite interesting music video."
[From Dan Farmer's list. PGN] My laptop is on its way to decrepitude, so I've been thinking about looking around for a replacement. I always figured I should just buy a big company's machine, as they're a commodity, and just look for the cheapest price for what I want, since they're all basically the same. Apparently this logic is flawed. Apparently Dell has just released a laptop in which the arrangement of keys on the keyboard is mistaken: http://www.flickr.com/photos/jacobgordon/2455618195/in/photostream/ Fortunately for us in the US, this just affects their European models. But still, it's kind of amazing.
The US Postal Service has changed the address of 100 people in San Francisco. According to the story, the problem arises because at one end of the street in question, the name is "La Playa", and at the other it is "Great Highway"—and where the split is between them depends on whose map you are looking at. The article does a pretty good job of diving into the implications of this, and the risks, including the technical problems that can happen such as GPS units not being updated with the "latest" decision about what name this street has. A Post Office spokesperson was quoted as saying that the decision to eliminate one of the ambiguous street names for these addresses was based on a database upgrade: "The legal address of the area in question is La Playa. We are required to deliver to the legal address. We understand that some residents have been using the Great Highway address for decades, but at some point we updated our database and (La Playa) is what is in our database."
My street address is 40 Needlepoint Lane. When I tried to use it on the Amtrak web site as a mailing address, it was rejected as being a post office box. Discussion with Amtrak's Internet Help Desk revealed that this is a known problem: the software that detects/disallows post office boxes simply looks for an adjacent "po" in the address! UGH!
H D Moore, Metasploit The Bug On May 13th, 2008 the Debian project announced that Luciano Bello found an interesting vulnerability in the OpenSSL package they were distributing. The bug in question was caused by the removal of the following line of code from md_rand.c MD_Update(&m,buf,j); [ .. ] MD_Update(&m,buf,j); /* purify complains */ These lines were removed because they caused the Valgrind and Purify tools to produce warnings about the use of uninitialized data in any code that was linked to OpenSSL. You can see one such report to the OpenSSL team here. Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG. Instead of mixing in random data for the initial seed, the only "random" value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations. The Impact All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected. In the case of SSL keys, all generated certificates will be need to recreated and sent off to the Certificate Authority to sign. Any Certificate Authority keys generated on a Debian-based system will need be regenerated and revoked. All system administrators that allow users to access their servers with SSH and public key authentication need to audit those keys to see if any of them were created on a vulnerable system. Any tools that relied on OpenSSL's PRNG to secure the data they transferred may be vulnerable to an offline attack. Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system. The Debian and Ubuntu projects have released a set of tools for identifying vulnerable keys. You can find these listed in the references section below. ... http://metasploit.com/users/hdm/tools/debian-openssl/
DSA-1571-1 openssl—predictable random number generator Date Reported: 13 May 2008 Affected Packages: openssl Vulnerable: Yes Security database references: In Mitre's CVE dictionary: CVE-2008-0166. More information: Luciano Bello discovered that the random number generator in Debian's openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable. This is a Debian-specific vulnerability which does not affect other operating systems which are not based on Debian. However, other systems can be indirectly affected if weak keys are imported into them. It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems is recreated from scratch. Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation. ... http://www.debian.org/security/2008/dsa-1571
I fly to Paris next week. A couple of days ago I booked a shuttle into the city itself. This is a company I have used before and I was happy to use them again. They must have a manual reservations process, because although one can "book" and pay on the web, the confirmation e-mail doesn't arrive until up to 24 hours later. Because of this I like to keep the confirmation webpage loaded in my browser until the e-mail arrives. This time around, I had to restart my machine before I got the e-mail. So I went back into my browser history on the off-chance that reloading the page would show enough details about the transaction. This worked better than I'd expected. There was my name, my confirmation num-...hey, hang on...isn't that a different confirmation number from the original one? Yup, I was right. What the heck? I immediately went to the URL...and found to my utter amazement, that after the "https://" and the domain name, were the entire details of my transaction, including my credit card number, expiry date, and the 3 digits off the back of the card. sigh... Of course I was charged a second time with the page reload, but this is obviously not the first time this has happened and the folks handled the situation very well. But way to go to completely defeat the point of SSL!
Mocmex, an insidious computer virus that collects passwords for online games, recognizes and blocks antivirus activity from over 100 vendors, and also evades Microsoft security and firewalls. It hides itself in photo frames. [Source: Deborah Gage, *San Francisco Chronicle*, 15 Feb 2008] http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&type=business [Old item, but we had not noted it before. PGN]
I'll bet someone figures out countermeasures to this real fast... Source: 'Peel and Stick' Tasers Electrify Riot Control Company's New Converter Kit Turns Shields into Shockers Noah Shachtman, WiReD BLOG Network, 14 May 2008 [PGN-ed] http://blog.wired.com/defense/2008/05/pretty-soon-cop.html Pretty soon, cops won't just be packing stun guns. They'll be carrying electrically-charged riot shields, zapping their unruly without unholstering their weapons. That is, if the folks at Taser International have their way. The company just introduced the "Taser Shield Conversion Kit featuring the Taser Repel Laminate Film Technology." The kit "features a peel and stick perforated film, power supply and necessary conversion equipment. This laminate becomes electrified providing a powerful deterrent to protect officers and keep suspects or rioters at bay." What could possibly go wrong? [See Noah's blog for the Rest of the Story. PGN]
So I received a phish mail...my (non-existent) account at the Bank of Montreal has been suspended... yada yada nada... Obviously a phish from a Microsoft script-kiddy as the entire URL is visible in text ******************** For your safety we have decided to suspend your access. You will need to verify your identity. http://www.simforce.net.au/helen_peng/REN/administrator/includes/js/bmologon.php? Customer Service, Bank of Montreal. ******************** So I decided to visit the root system. Turns out, they design and build websites. All Microsoft websites. Lotsa flash and flashy motion and loud audio. And no e-mail address for a contact, only a flash (in the old sense of the word) web-contact page. Which of course, does not work with Firefox and Fedora. Same thing for the client system which lives further down the URL chain. Wanna see a directory listing of Helen Peng's directory. Go right ahead. So I can't tell them they have been screwed, in more ways than once. Maybe they will notice the extra server load and the high traffic levels serving one particular page which they don't actually know about? Ya think? Geoff
BKGKNMCS.RVW 20080207 "Geekonomics: The Real Cost of Insecure Software", David Rice, 2008, 0-321-47789-8, U$29.99/C$32.99 %A David Rice david@geekonomicsbook.com %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2008 %G 0-321-47789-8 978-0-321-47789-7 %I Addison-Wesley Publishing Co. %O U$29.99/C$32.99 416-447-5101 800-822-6339 bkexpress@aw.com %O http://www.amazon.com/exec/obidos/ASIN/0321477898/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321477898/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321477898/robsladesin03-20 %O Audience n+ Tech 2 Writing 3 (see revfaq.htm for explanation) %P 362 p. %T "Geekonomics: The Real Cost of Insecure Software" In the preface, the author states that the only pre-requisite for reading the book is a "hint of curiosity." This is because the work explores the issue of insecure and unreliable software from a sociological and economic perspective, rather than giving the topic a purely technical examination. Rice's book is readable, informative, and makes important points. I enjoyed it. Normally such an assessment comes at the end of the review, but I want to state this up front, because, in the remainder of the commentary contains a number of critical comments. For the most part, though, these apply to components that Rice has not included, and which would tend to support his contention, rather than detract from it. Chapter one repeats a lot of the material in the preface, sometimes in greater detail. Rice compares software with cement, in terms of the infrastructure of modern society, and also introduces the economic concepts of incentives and utility. The emphasis, in the analysis of software flaws, is on intrusions and networking, but the examples cited concentrate on concerns of reliability, rather than intrusions, somewhat weakening the overall argument. The lack of software standards, and the fact that unregulated markets militate against quality and safety, are addressed in chapter two. The text also specifically explores the problems involved in the ubiquitous practice of patching software faults. Rice's reasoning on the matters, while generally sound and extremely convincing, does have some odd quirks. For example, he repeats the widely held belief that building secure software in the first place must necessarily be more expensive, or companies would be doing it. (A relevant counter-example in the world of non-computer technology would be that of refrigerator doors. For years fridge door latches were a danger to children when old fridges were abandoned. Children playing around the fridges could enter them, and then become locked inside. It was only after appliance companies were forced to change the door locking mechanisms that they turned to magnetic closures--and found that not only were those mechanisms safer, but also cheaper and more energy efficient. Thus, companies may sometimes need to be forced into practices that may actually be to their advantage. Overall, consideration of such additional elements only serve to strengthen Rice's basic premise that insecure software is unnecessarily costly.) In chapter three, Rice notes the extremely low rate of prosecution for computer crimes, and moves from there to the statement that professional cybercrime is not just a criminal matter, but that the issue of software unreliability is of concern for national, and even international, economic security. He concentrates, again, on software vulnerabilities, failing to fully assess investigative weaknesses (and the economic pressures preventing law enforcement agencies from hiring and retaining trained forensic staff), the inherent risks of information warfare (to the attacker as well as the target), and the difficulty of establishing and validating trust relationships. He correctly identifies the problem with paying bounties for vulnerabilities (which many have forgotten). Noting the deleterious effect of allowing visible dilapidation to go unrepaired, he asserts that the invisible imperfections of software are even more important, but his argument appears incomplete. After reiterating the point that speed of innovation and time-to- market is important to software developers, chapter four appears to lose focus, finally seeming to make the point that we need some kind of licensing for software development. Chapter five's review of tort law tends to overshadow the more significant message that software developers enjoy an unparalleled immunity from lawsuits, and thus have no motivation to produce software of high quality. Various characteristics of open source software, and related development processes, are used to point out, in chapter six, differing economic forces both for and against software reliability. Near the beginning of chapter seven Rice admits that he proposes no ultimate answers to the question of code quality. He does, however, list arguments that can be used to start further discussion on the possible approaches to revise the incentive environment in order to promote quality software. The list of potential approaches includes allowing the "free market" to deal with the problem (in other words, do nothing), promote litigation, license software engineers, create standards, or impose some form of vulnerability tax on developers. Towards the end of chapter seven, the author states that "[t]his book has argued, no matter how imperfectly, that incentives are key to changing the story of software." Despite my minor quibbles, Rice's case is solid, and his thesis is important. This work should be required reading for all involved in matters of technology policy, from managers and security professionals responsible for application development, to politicians. If this publication is successful enough, the publisher might have an incentive to ask the author to update his text for a second edition, at which time Rice might tighten up his arguments and include some of the missing bits. Then this book should be required reading for all developers and programming students. copyright Robert M. Slade, 2008 BKGKNMCS.RVW 20080207 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer