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 New York Times* had the following editorial on line on 31 Jan 2004, at http://www.nytimes.com/2004/01/31/opinion/31SAT1.html - they conclude with the remark "Given the growing body of evidence, it is clear that electronic voting machines cannot be trusted until more safeguards are in place." I wonder what safeguards they envision that would allow us to trust electronic voting. How to Hack an Election Concerned citizens have been warning that new electronic voting technology being rolled out nationwide can be used to steal elections. Now there is proof. When the State of Maryland hired a computer security firm to test its new machines, these paid hackers had little trouble casting multiple votes and taking over the machines' vote-recording mechanisms. The Maryland study shows convincingly that more security is needed for electronic voting, starting with voter-verified paper trails. [...] They were disturbingly successful. It was an "easy matter," they reported, to reprogram the access cards used by voters and vote multiple times. They were able to attach a keyboard to a voting terminal and change its vote count. And by exploiting a software flaw and using a modem, they were able to change votes from a remote location. [...]
[I wonder if these are the same forensic experts who couldn't figure out how the Bank of England scam software worked?] Vital e-crime evidence often destroyed; National High Tech Crime Unit warns firms to leave computer forensics to the experts By Iain Thomson, vnunet, 29 Jan 2004, http://www.vnunet.com/News/1152379 Companies that fall victim to computer crime may be inadvertently destroying evidence in their efforts to find the perpetrators. Detective Chief Superintendent Len Hynds, of the National High Tech Crime Unit (NHTCU), said that its Confidentiality Charter, launched in December 2002, was encouraging more businesses than ever to report computer crime. But there are sometimes problems with gathering evidence if preliminary investigations have been carried out before the police are called in. Speaking at the Homeland and Corporate Security Summit in London DCS Hynds said: "There are examples of companies which wrestle with problems for months without calling us and that can lead to problems in the evidential trail. The private sector is going to be key to being even more effective in solving crimes. However, we need to develop common standards in terms of dealing with high-tech crime between the private and public sectors." Cyber-criminals are becoming ever more sophisticated in their activities. Tactics include hiding files that are disguised as bad sectors on a hard drive, and using other PCs as mail servers to shield illegal activities. Michael Colao, senior consultant at Dresdner Kleinwort Wassertein, said: "What we see is well-meaning IT professionals going in and doing what you see on every bad crime film: they muddy the waters. You only have one opportunity to collect the evidence you need to prove your case. Human resources send in well-meaning IT help desk staff who don't know what they are doing and ruin the evidence. You need a professional computer forensic team in there as soon as possible."
CDT (http://www.cdt.org/) has issued a report entitled "Unlicensed Fraud" (http://www.cdt.org/privacy/20040200dmv.pdf) documenting rampant internal fraud and lax security at state motor vehicle administration offices across the country placing the reliability of all driver's license at risk. While heavy public attention has been placed on new national standards and new technologies for driver's licenses, studying local news reports from throughout 2003 CDT finds that basic management processes to stop bribery and theft are lacking. In the report, CDT offers policy recommendations to address this dire issue. February 2, 2004
The following article describes an attack against the web images (so-called "CAPTCHAS") that are used to prevent robots from using certain web applications such as the creation of free e-mail accounts. The images are a form of "Turing Test", easy for a human user of normal ability to process, but difficult for a piece of software. The attack involves routing the CAPTCHA image to a page that advertises free porn. Users have to decode the CAPTCHA to get the advertised images and in doing so, unwitting assist spammers in creating bogus e-mail addresses. "But at least one potential spammer managed to crack the CAPTCHA test. Someone designed a software robot that would fill out a registration form and, when confronted with a CAPTCHA test, would post it on a free porn site. Visitors to the porn site would be asked to complete the test before they could view more pornography, and the software robot would use their answer to complete the e-mail registration." http://www.post-gazette.com/pg/03278/228349.stm (Relevant section is near the end) One poster to a related thread in Slashdot (http://slashdot.org/article.pl?sid=04/01/28/1344207) reported that his site shut down its (CAPTCHA-protected) free e-mail service recently due to a sharp increase in spammer-generated accounts. Robin Burke, Associate Professor, School of Computer Science, Telecommunications, and Information Systems, DePaul University http://josquin.cti.depaul.edu/~rburke/
Buy something, get whatever you can stuff into your parka free! That's right, go into a <name of big home-improvement store deleted to protect the guilty> when the outside temperature is a little cold (say, 10 degrees F). Pick up a $2 screwdriver and a $100 multimeter. Pay for the $2 screwdriver, but stuff the $100 multimeter in your jacket. When the fancy schmancy EAS (Electronic Article Surveillance) system goes off as you are walking out the door, don't worry, the clerks will ignore it and yell to you "you're fine - that thing always goes off when its cold". I saw this happen about a dozen times while waiting in line at <big home improvement store>. I have no idea if the customer had a $100 multimeter in their jacket, but then again, neither did the employees of the store! I couldn't find technical details on Checkpoint EAS systems <http://www.checkpointsystems.com/content/eas/default.aspx>, but Sensormatic <http://www.sensormatic.com/EAS/default.asp> provided details such as <http://www.sensormatic.com/EAS/EASGetDocument.asp?FileName=Digital Pro-Max DS NUS.pdf>, which states "Ambient Temperature: 0 C to 50 C (32 F to 122 F)" This particular problem would likely only affect stores with sensors near very large outside doors, such as home improvement and warehouse stores.
I'm so disappointed that PGN didn't go with the obvious pun -- that Spirit was willing, but its flash was weak... [Thanks, but I didn't think Rover's park was worse than its plight. PGN]
I just had a scary thing happen to me. I got the following e-mail: Return-path: <remind@newman.newman-grt.oscar.aol.com> Date: Wed, 28 Jan 2004 20:12:08 -0500 (EST) From: Netscape Registration <remind@newman.newman-grt.oscar.aol.com> Subject: Information you requested To: gat@jpl.nasa.gov Original-recipient: rfc822;gat@jpl.nasa.gov Dear User, The information that you requested from Netscape is below: ****** Thank you, Netscape Registration http://home.netscape.com/ except that where the ******* is there was a password that I often use for low security applications. Trick is, I have never to my recollection signed up with Netscape. To say nothing of the fact that the e-mail didn't come from Netscape (none of the received headers were from netscape).
RISKS 23.16 mentioned phishing with URLs of the form http://reasonable.site.name @criminal.site.ip.address/index.html which use the username:password@hostname format of URL for social engineering. Microsoft has just released a security update for Internet Explorer which deals with vulnerabilities caused by some special characters preventing the entire URL from being displayed in the browser's address bar and status line. That vulnerability has been used with phishing URLs like the above to suppress display the portion of the URL starting from the '@'. They went one step further, however, and eliminated all support for the username:password@hostname syntax in http URLs in the Internet Explorer browser, with optional registry entries to allow or remove the support from programs that embed IE as an object. The Microsoft Knowledge Base article about the security update is at http://support.microsoft.com/default.aspx?kbid=834489 It refers to information about the URL syntax at "INFO: URL Syntax for Authentication Without Dialog Prompt" http://support.microsoft.com/default.aspx?kbid=200351 I have seen some objections to Microsoft unilaterally dropping support for a URI syntax allowed in RFC 2396, thereby breaking websites that use this form of URL for user logins. I think in this case Microsoft did the Right Thing for security. RFC 2396 applies to the generalized URI, which includes, for example http:// and 2616, etc.) do not use that syntax, while ftp: does. Username password syntax in an http URL was always a nonstandard extension that introduced various security vulnerabilities.
Writing on Feb. 2, it's very hard to assess what the real impact of the MyDoom-generate denial of service was on SCO. We do know that, notwithstanding the hype and heavy breathing from anti-virus companies, that it had little or no impact on the performance of the Internet as a whole. It's very hard to assess what is going on at SCO, because www.sco.com <http://www.sco.com/> was mostly inaccessible from Wednesday, Jan. 28 on (I'm indebted to Netcraft <http://www.netscraft.com/> for their site-performance reporting.). Darting on Wednesday, my efforts to reach the SCO site variously generated forbidden access (403) errors, time outs, or sporadic availability. At some point on Sunday, DNS entries for ww.sco.com were removed; later traffic to the site was directed to a Google search page. On Monday, SCO transferred the site to www.thescogroup.com <http://www.thescogroup.com/> . According to Netcraft, that server lies within the same IP address space as www.sco.com <http://www.sco.com/> , so it would appear that whatever is happening to the server, SCO's network is holding up fine. Netcraft also reported on the afternoon of Feb. 2 that in anticipation of the MyDoom.B phase of the attack, Microsoft has shortened the TTL for www.microsoft.com <http://www.microsoft.com/> to 60. MyDoom.B appears to have gotten significantly less distribution than the A variant. I think the real untold story of MyDoom is that network administrators, especially at the big ISPs, have gotten much better at containing the damage from these attacks. MyDoom may have been the fastest spreading virus ever, but it seemed much less disruptive than SoBig.F last summer. After the first few hours, the main virus-related traffic I saw was the continuing stream of spurious bounce messages and the phony "you have sent a virus" alerts. It wouldn't be hard to eliminate those messages completely-turn off the virus alert feature, which has been rendered worthless by return address spoofing, and don't sent bounce messages in reply to messages bearing known signatures, like the MyDoom generated ones. Steve Wildstrom, BusinessWeek Technology & You columnist 1200 G St NW Suite 1100, Washington, DC 20005
I note that you had 2528 new e-mails between Jan 27 and Feb 2, under a week. Over the week beginning 26 Jan at 3PM, I *personally* received over 30,000 e-mails involving MyDoom. That's just me — I'm not an ISP or anything. I haven't kept really close tabs, but I estimate this is between 700 and 1000 megabytes. There are two reasons for this. The first is subtle. As finally detailed at the bottom of Symantec's info page on MyDoom at http://securityresponse.symantec.com/avcenter/venc/data/w32.novarg.a@mm.html one of the lesser known behaviours of MyDoom is the key. After finding an e-mail address by searching locally on the infected machine, MyDoom then also uses a combination of the domain and a list of common usernames. Almost all of the names are common given names - except mine: smith I maintain an address at a popular freemail/webmail site, using this username. Thus whenever an instance of MyDoom finds any e-mail from this site, there is a chance it has found me as well. This isn't even one of the REALLY BIG webmail sites. Although I've got lots, I expect anyone at hotmail or aol with a name on the MyDoom list has even more. The second reason everyone knows - bounces back to spoofed From: addresses. I estimate that between 1/3 and 1/2 of my e-mails are of this variety. The volume of bounces and directs together makes clear that MyDoom uses these made-up addresses both for From: and To: addresses. It is worth noting that the vast majority of MyDoom traffic contains spoofed From: and From_ (sender) information. Implementation of something like Sender Permitted From (SPF) could have stopped most of these in their tracks. MyDoom has effectively converted me into an SPF evangelist - because if the history of worms has shown us anything, it's that once a technique is shown to be useful to worms, it isn't RISK that it will show up again - it is pretty much certain. Anyone who argues that there are too many RISKs with something like SPF will have to provide me with a good alternative. Even after all this, I refuse to accept that my name is a RISK.
> Why are the good guys trying to teach people to click on attachments? I would think antivirus software companies would seem to have a very large incentive to keep users doing the stupid things that get them infected. If people stopped clicking on attachments, the AV companies would be out of business overnight. Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/
> Why are the good guys trying to teach people to click on attachments? But opening "attachments" is a fact of ms-win life. The commonest text-like file format is the Microsoft Word (.doc) format. When people turn ms-word files into e-mail messages, they generally do so by "attaching" them. So ms-win users are used to opening attachments, routinely. I don't think it's useful to tell people not to open attachments, because this is simply infeasible. They _are_ going to open attachments. In fact, the message to all telling them not to open attachments is likely to be a .doc file attachment (unless it's powerpoint, or a flash animation). I think that what ms-win needs is a clearer separation between data and program. There need to be file formats which are not programmable, which can be viewed safely. Assuming that plain text is (for no real reason) not an option, Microsoft could lead the way by releasing a version of its office suite which does not implement "macros". Very few users will miss them, and everyone else will be impressed by Microsoft's technical mastery in producing word processors which are incapable of transmitting viruses.
R. de Bath R. Debath R. Bath R. De'ath And thats in ONE language! (The 'proper' surname is "de Bath") Rob (Robert de Bath <robert$ @ debath.co.uk>) <http://www.cix.co.uk/~mayday> [In addition, Arabic names seem to have many variants. PGN]
I own a 1999 Sonoma and a 2000 Chevy Venture, both built by General Motors. The combination ignition/pass key is interchangeable to open either vehicle's door but will not start the other vehicle, presumably due to the chipped key required by the newer model (the Sonoma does not have it). One hopes that, even though the mechanical door locks are being shared, the chips would have a 1:1 mapping of keys to ignitions. Incidentally, my dealer didn't think of it as a RISK when I first brought it to their attention. They felt I should consider it a feature since so many others pay to have this done. D. Joseph Creighton [ESTP] | Systems Analyst, Database Technologies, IST Joe_Creighton@UManitoba.CA | University of Manitoba Winnipeg, MB, Canada, eh?
Forget keys, one time I was on a business trip to St. John's, Newfoundland. I rented a maroon Oldsmobile Alero from the National Car Rental at the airport. The car was equipped with a keyless entry system on the key-ring. I rent so many cars that most of the time I forget what kind of car I'm driving on any given trip. One day, I went into a local supermarket, leaving my rental parked in a spot near the entrance after locking it remotely. Upon exiting the store, I walked over to my Alero, pressed the unlock button on the keychain, and hopped in. I inserted the key and started the engine. At this point I noticed that my briefcase was not on the passenger seat where I had left it. After a moment of panic, it took about three seconds to realize that I was in somebody else's car. I turned it off, got out, and pressed the lock button on the remote. The car locked itself and I went looking for my rental, which was in a spot two rows over behind a big pickup truck. What are the odds of having not only a matching door/ignition key, but also the keyless entry remote? David W. Brunberg
This story SOUNDS quite apocryphal [, like urban legends noted in] http://www.snopes.com/autos/law/copcar.asp. In fact, things might be much worse than this story indicates, and I have a personal example to demonstrate. Last year I took a train out to my parent's from the city; in the parking lot they left me a car complete with a magnetic hide-a-key box for the car key which I did not have. Upon opening the box, I found there was a house key instead! After fruitlessly searching for another key I decided to try the house key on a lark, and to my great surprise it actually OPENED the driver's-side door of the car (which was a 1991 Jeep Cherokee). Sadly for me this key did not actually start the car. However, since I was in an extremely out-of-the-box frame of mind, I jammed a paperclip in the ignition, heard the distinctive buzzing, turned the "key" and STARTED THE CAR! (See photo - http://daiv.ods.org/sockimages/display/1526.jpg). The blade on a friend's pocketknife later accomplished the same trick. NB0: This was actually my dad's system of security through obscurity. Since putting the car key in a hide-a-key box is very insecure he would leave a house key which he knew would open the door, and then would hide the ignition key inside the car. The flaw? Not telling me this in advance! NB1: Getting into the car was never the primary concern anyway, since on a Cherokee you can grip the rubber of the rear window and easily pull the window out of the door, then climb into the trunk. Useful if you lock your keys in. NB2: On a Grand Cherokee (at least models from the late 90s) you can *always* open the rear window using the button on the door. This will set off the alarm if locked, but it opens regardless!
I was recently the executor of a relative's estate and was shocked to discover that I was able to cancel his private health insurance, his veteran's health benefits, one dozen credit cards, and all of his retirement direct deposit payments with simple phone calls. At no time did anyone ask me to prove that I was who I said I was or whether I had executor power over his estate. I simply presented a plausible sounding story, knew his social security number and his account numbers and was able to close his accounts over the phone. To make it even more interesting our last names are not even the same! The possibility for mischief should be obvious with such an insecure system. Not exactly computer-related but very scary indeed.
BKKRBSDG.RVW 20031018 "Kerberos: The Definitive Guide", Jason Garman, 2003, 0-596-00403-6, U$34.95/C$54.95 %A Jason Garman %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 2003 %G 0-596-00403-6 %I O'Reilly & Associates, Inc. %O U$34.95/C$54.95 800-998-9938 fax: 707-829-0104 nuts@ora.com %O http://www.amazon.com/exec/obidos/ASIN/0596004036/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0596004036/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0596004036/robsladesin03-20 %P 253 p. %T "Kerberos: The Definitive Guide" Kerberos is not flashy, but it is a venerable and mature technology. Yes, it has limited scalability, but most of the "successful" PKI (Public Key Infrastructure) projects are small enough that they could easily have been accomplished with Kerberos technology: an eminently elegant solution to the problem of communicating and authenticating over any channel that is, or must be, assumed to be insecure. Chapter one provides a history, base concepts, and variants of Kerberos. Terms and components are given in chapter two. The Needham-Schroeder work, and the idea of ticket-granting, is in chapter three. Implementation, in chapter four, reviews design, UNIX and Windows servers, and special considerations for a mixed environment. The troubleshooting chapter, five, for once comes early enough in a book to be of use. Security aspects external to Kerberos, and specific settings for different implementations, are covered in chapter six. Chapter seven looks at some generic support for applications, as well as some specific programs that already have Kerberos support built in. Cross realm trust is one of the advanced topics, but most of chapter eight concentrates on special requirements for Windows. Chapter nine is a kind of review of the book, involving the various topics that have been discussed in a sample Kerberos installation. Chapter ten looks at the future of Kerberos, with possible public key additions, Web applications, and smartcards. An appendix contains an administrative command list. While Kerberos may not be as highly regarded as the more mathematically complex asymmetric cryptographic systems, it still have many uses, and this book provides the outline, background, and details to help you take full advantage of them. copyright Robert M. Slade, 2003 BKKRBSDG.RVW 20031018 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