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…
Reality matters, but perceptions can matter even more. The juxtaposition of Google's stance on the Feds' search query log COPA data demand and Google's decision to cooperate with China's censorship does not realistically represent "hypocrisy" as is being erroneously suggested by various media articles. The two issues are very different in many key aspects. However, this is not to minimize the enormous risks to Google — and other Internet services — if they're perceived to be making "inconsistent" policy decisions that directly affect important issues (often relating to essentially non-technical impacts) about which many people are very concerned, and often very emotional. Now, as was completely predictable, Congress is getting involved. Congressman Tim Ryan has announced a hearing of the Congressional Human Rights Caucus (16 Feb is the date that I've heard) to explore the potential drafting of laws that would limit or otherwise control U.S.-based Internet companies from complying with the censorship demands of foreign countries. Emotions were clearly exasperated by Google's launching of the "dot-cn" Chinese version of Google search that blocks links as per Chinese government directives, though Google is not alone in this regard among U.S.-based Internet companies. Ryan also specifically tied this to the COPA case, directly and dramatically suggesting that Google was more willing to obey Chinese law than U.S. law. This is an example of the perception risk I described above crystalized in a very potent way. The situation highlights the minefield of issues that Google and other Internet companies now face, and the desperate need for proactive approaches to dealing with the ways that these technologies affect individuals and society. Google's participation in the Chinese censorship program (which I consider to be extremely problematic) creates a perception that is undermining what I view as Google's correct decision regarding the search query COPA case, with the sorts of reactions we're now seeing. Coincidentally, I spent a very pleasant afternoon two days ago at Google's Los Angeles (actually Santa Monica) facilities giving a talk regarding exactly these and other issues. This included (among other topics) discussion both regarding those areas where I feel that Google is doing a terrific job, and their policies and operations about which I've been (sometimes highly) critical — where I feel that changes would be of benefit to Google, their users, and society at large. (Google invited me and we scheduled this talk prior to the breaking of the COPA search query story -- talk about timing...) I much appreciated the opportunity to address such issues directly at Google and meeting a bunch of nice folks at the site. The talk was taped and I hope that the video will become publicly available in the near future — I'll let you know. Lauren Weinstein +1-818-225-2800 http://www.pfir.org/lauren http://lauren.vortex.com http://daythink.vortex.com lauren@pfir.org
There have been numerous cases in past RISKS issues where information has been leaked via electronic documents. This includes mainly the history included with Word files and "redacted" PDF files. It seems that this has finally caught the attention of the US National Security Agency (from [1]): Section 2: Procedures to Sanitize a Word Document The following steps were tested with MS Word 2000 and Acrobat 5.0 and 6.0. Other recent versions should work similarly. While time-consuming, these steps give the highest confidence that sensitive information is not hidden in the released document. Copying the text and images into a blank document is a good way to manually review a sensitive document, since sections can be copied over one at a time as they are reviewed. Found via Boing Boing [2]. [1] http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf (670 KB) [2] http://www.boingboing.net/2006/01/21/nsa_howto_sanitize_w.html
The NTSB has reported on the cause of the Southwest Airlines crash in Chicago: http://www.cnn.com/2006/TRAVEL/01/27/airplane.landings/ http://www.chicagotribune.com/news/local/chi-060127midwayaccident,1,3064315.story?coll=chi-news-hed Executive summary: the thrust reversers did not deploy properly, causing the plane to overshoot the end of the runway. A point of contention right after the accident was that the pilots had apparently activated the automatic brake system in violation of Southwest policy, but the NTSB concluded the crucial factor was the unanticipated 18-second delay in the thrust-reversers deploying. As a result, NTSB is urging the FAA to to prohibit allowing for thrust-reversers in onboard stopping-distance calculations. (Before landing, the crew had used the onboard computer to calculate stopping distance for "wet-poor" conditions; those calculations assumed the thrust reversers would deploy normally.) The risks here appear to be two of the most common ones: trusting an automatic system to activate within specification 100% of the time, and allowing that trusted system to be the critical margin between success and catastrophic failure — even in the successful-landing scenario represented by the onboard computer's figures, the plane was anticipated to stop within 30 feet of the end of the runway after a rollout of over 4000 feet, a margin of error of less than 1%. — Joe Joe Thompson | joe@orion-com.com
More than reservations was affected. I was on a United flight at Dulles waiting to take off at the time the reservation system went down. I was listening to air traffic control when the pilot of my flight and another UAL plane told the tower they couldn't take off because they didn't "have their numbers." Later, our pilot came on the PA and said that because of a computer outage, UAL operations was having to do load and balance computations manually. Steve Wildstrom, Technology & You columnist, BusinessWeek
Happy New Year, 234-56-7890! Trust us and our software to protect your confidential tax information! http://netscape.com.com/H38R+Block+blunder+exposes+consumer+data/2100-1029_3-6016720.html > Some consumers may be dismayed to find their Social Security numbers > printed on unsolicited packages from H&R Block, the result of a recent > labeling blunder at the company. > > The packages, which H&R Block mailed in December, contained free copies of > the company's tax preparation software, TaxCut. By mistake, some of the > packages also displayed recipients' Social Security numbers, which were > embedded in 47-digit tracking codes above mailing labels. IP Archives at: http://www.interesting-people.org/archives/interesting-people/
[First seen on the Telecom Digest]: http://htdaw.blogsource.com/post.mhtml?post_id=198659 Monday January 23, 2006 by Ed Felten If you've been reading here lately, you know that I'm no fan of the Sensenbrenner/Conyers analog hole bill. The bill would require almost all analog video devices to implement two technologies called CGMS-A and VEIL. CGMS-A is reasonably well known, but the VEIL content protection technology is relatively new. I wanted to learn more about it. So I e-mailed the company that sells VEIL and asked for a copy of the specification. I figured I would be able to get it. After all, the bill would make compliance with the VEIL spec mandatory — the spec would in effect be part of the law. Surely, I thought, they're not proposing passing a secret law. Surely they're not going to say that the citizenry isn't allowed to know what's in the law that Congress is considering. We're talking about television here, not national security. After some discussion, the company helpfully explained that I could get the spec, if I first signed their license agreement. The agreement requires me (a) to pay them $10,000, and (b) to promise not to talk to anybody about what is in the spec. In other words, I can know the contents of the bill Congress is debating, but only if I pay $10k to a private party, and only if I promise not to tell anybody what is in the bill or engage in public debate about it. Worse yet, this license covers only half of the technology: the VEIL decoder, which detects VEIL signals. There is no way you or I can find out about the encoder technology that puts VEIL signals into video. The details of this technology are important for evaluating this bill. How much would the proposed law increase the cost of televisions? How much would it limit the future development of TV technology? How likely is the technology to mistakenly block authorized copying? How adaptable is the technology to the future? All of these questions are important in debating the bill. And none of them can be answered if the technology part of the bill is secret. Which brings us to the most interesting question of all: Are the members of Congress themselves, and their staffers, allowed to see the spec and talk about it openly? Are they allowed to consult experts for advice? Or are the full contents of this bill secret even from the lawmakers who are considering it? http://www.freedom-to-tinker.com/?p=958 Archives at: http://www.interesting-people.org/archives/interesting-people/
Subject: NSA explains how to redact documents electronically (via Dave Farber) http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf One wonders how long it will be till someone finds an error... --Steven M. Bellovin, http://www.cs.columbia.edu/~smb Archives at: http://www.interesting-people.org/archives/interesting-people/
FBI Agent's Cell Phone Records For Sale Locatecell.com seems to have a good thing going. According to this Chicago Sun Times story: To test the service, the FBI paid Locatecell.com $160 to buy the records for an agent's cell phone and received the list within three hours, the police bulletin said. Representatives of Data Find Solutions Inc., the Tennessee-based operator of Locatecell.com, could not be reached for comment. Frank Bochte, a spokesman for the FBI in Chicago, said he was aware of the Web site. "Not only in Chicago, but nationwide, the FBI notified its field offices of this potential threat to the security of our agents, and especially our undercover agents," Bochte said. Funny how the FBI's first reaction is to go on the defensive. Funny how this is a big surprise to the FBI. The Chicago Sun-Times paid $110 to Locatecell.com to purchase a one-month record of calls for this reporter's company cell phone. It was as simple as e-mailing the telephone number to the service along with a credit card number. Locatecell.com e-mailed a list of 78 telephone numbers this reporter called on his cell phone between Nov. 19 and Dec. 17. The list included calls to law enforcement sources, story subjects and other Sun-Times reporters and editors. Cheating spouse? Disloyal employees? Need to find out what your competition is doing? Hey, no problem. Telecom services are just information services these days. Fortunately friend Chris Hoofnagle, of Electronic Privacy Information Center, is on the case. Thanks to Steve Crandall, who spotted this story first!
Of course, not answered [nor likely to be answered] is why the security even could be breached at a facility that handles nuclear submarines. RsH An 18-year-old suspected Spanish hacker who allegedly breached the top-secret computer security of a U.S. Navy base in San Diego has been arrested in his home town of Malaga, Spain, according to the Spanish Civil Guard. He reportedly "seriously compromised the correct operations and security of a maintenance dry dock for nuclear submarines." [Source: CNN Madrid Bureau Chief Al Goodman, 16 Jan 2006; PGN-ed]
By John Christoffersen, AP Business Writer | January 11, 2006 STAMFORD, Conn. --A tape containing the Social Security numbers and other confidential data of 90,000 People's Bank customers was lost recently while en route to a credit reporting bureau, state and bank officials said Wednesday. Millions of people around the country have been affected by a recent string of data losses and thefts involving major financial institutions and businesses including Citigroup Inc., Time Warner Inc. and Ameritrade Holding Corp. People's has no reason to believe the data has been used inappropriately and has received no reports of unauthorized activity, officials said. Customers do not need to close accounts because the information is not sufficient to allow unauthorized access, the bank said. But consumer advocates say identity thieves could use Social Security numbers to open new accounts in the names of those affected. They say such data should be encrypted so it cannot be illegally accessed and they advocate new laws that would allow consumers to place fraud or security alerts on their credit reports to prevent thieves from creating accounts. ... http://www.boston.com/news/local/connecticut/articles/2006/01/11/bank_loses_tape_with_personal_information_on_90000_customers/
(From Dave Farber's IP) This actually happens all the time. The bank FedEx's or otherwise sends a tape, it get's lost. This happens. In a past life as a datacenter manager at Citibank we used to receive palettes of tapes by FedEx every morning from Sioux Falls, SD, where the credit card processing center was, a truck of tapes having better bandwidth at lower cost that any telco line. Occasionally tapes got lost, it was no big deal and no one thought much of it other than to request another copy. California, IIRC, was the first state to mandate that any lost customer records of any sort has to be reported, and other states have followed suit. Since such laws been enacted that it must be reported it's been getting recent press and what is actually a common occurence is now "news". The risk from this is considered very low. In most all cases the data is encrypted. Even if it wasn't other policies prevent keeping say account numbers and names, or other required pieces of information necessary to commit a fraud or identity theft with information together in the same place at once. Having names and Social Security numbers together is considered low risk since this information is readily available through numerous sources. Dan Shoop, Systems & Networks Architect 1-646-217-4725 http://www.iwiring.net/ http://www.ustsvs.com/ shoop@iwiring.net
A Japanese trader pushed the wrong button Friday and cost his brokerage house almost 500 million yen, or $5.1 million Cdn. The incident is the latest in a series of blunders and computer glitches on the Tokyo Stock Exchange, Japan's biggest bourse. In the latest case, a trader with Daiwa Securities SMBC apparently made a mistake just before the start of trading and sold 25,000 shares of the wrong company. Daiwa realized the error a few minutes later and issued a buy-back order, but investors had already snapped up 13,000 shares. The brokerage house repurchased all those shares by the end of the trading day, but lost almost 500 million yen ($5.1 million Cdn) in the process, according to Daiwa spokesman Daishu Nagata. [Source: Trader's typing error costs Japanese brokerage house millions CBC News, 13 Jan 2006; PGN-ed; see RISKS-24.12 for the earlier Mizuho screwup.] http://www.cbc.ca/story/business/national/2006/01/13/goof-060113.html
Here's a site RISKS users might be interested in. It appears to be a compendium of legal cases in which e-mails play a significant role. It includes several cases where deleting e-mail has cost companies large amounts of money, even when the e-mails were not recovered. http://arkfeld.blogs.com/ede/email/
In this (http://www.cisco.com/warp/public/707/cisco-sa-20060111-mars.shtml) recent Cisco advisory, the company alerts us to a security problem with Cisco MARS (Cisco Security Monitoring Analysis and Response System). The security issue is basically a user account on the system that will give you root when accessed. The account is: 1. Hidden. 2. Default. 3. With a pre-set password. In other words, this is a journey back 10 years when technicians would commonly have special keys (actual keys, electronics or passwords) to access a device if they have to troubleshoot it for anything, or say? the user lost his password. People used to trade these keys online and hidden accounts were a thing of common practice. Today people still trade commonly used default passwords but it is not as popular as it used to be, at least in the online world. On the other hand, the most common practice to hack routers today, is still to try and access the devices with the notoriously famous default login/password for Cisco devices: cisco/cisco. Cisco/cisco is the single most used default password of our time. It got more routers pwned than any exploit in history, and it still does. One would think that a company such as Cisco, especially with this history, would stay away from such "default" accounts? but the fact that this account is hidden makes it something different. It makes it a backdoor. One much like those used by the Bad Guys. Now... if Cisco knowingly put it there, shame on them. If somebody put it there without their knowledge... well, shame on them. This is indeed a vulnerability, as in a weakness. It is not however a software coding bug that may result in say... a buffer overflow. It is a part of the design of the system. Cisco disclosing this is very nice and commendable, but perhaps they should also let us know whether this was indeed a backdoor somebody put in their system or if it was part of the design? I love easter eggs. I just don't like surprises in system privileges or backdoors, especially not in a security monitoring and response product. I very much doubt it was anything else but a part of the design but that should be admitted to. As the advisory states: "No other Cisco products are currently known to be affected by this vulnerability." Okay, but how about other vulnerabilities of this type? Are there any more backdoors to other Cisco products? If not, why wouldn't they just come out and say that? "There are NO other such backdoors in our products." I'd even be happy with: "To our knowledge, there are no other vulnerabilities of this type in our products." This is not a bug. One can never be sure ALL bugs are eliminated - however hard one may try. One CAN admit to having no such features in other products, though. Once again we fall upon re-naming of a feature as a bug or a bug as a feature to make the problem sound less severe. In this case, the judgment is plain and simple: If Cisco were Bad Guys, this is a backdoor. As Cisco are Good Guys, this is a technician reset. Terminology? What's the difference? The difference is that Cisco are not Bad Guys. If they disclosure a problem they should do it fully, because as a client, I am now concerned. This reminds me of Ciscogate but not for obvious reasons. That was a bad event for everybody involved. It reminds me of the very issue Mike Lynn discussed: Remote exploitation for Cisco is possible, while so far Cisco disclosed all these problems as DoS vulnerabilities. I am not saying Cisco did that on purpose, but in THIS case they CAN set my mind at ease. Why don't they? Update: After writing this I've been made aware that this product was from a company Cisco bought not so long ago. This very same issue happened before (and more than once)... in one recent example with another company Cisco bought named Riverhead. Checking into new investments security-wise, especially with security products and external QA may help solve such issues in the future.
BKROOTKT.RVW 20051023 "Rootkits", Greg Hoglund/James Butler, 2006, 0-321-29431-9, U$44.99/C$62.99 %A Greg Hoglund %A James Butler %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2006 %G 0-321-29431-9 %I Addison-Wesley Publishing Co. %O U$44.99/C$62.99 416-447-5101 fax: 416-443-0948 bkexpress@aw.com %O http://www.amazon.com/exec/obidos/ASIN/0321294319/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321294319/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321294319/robsladesin03-20 %O Audience s+ Tech 3 Writing 2 (see revfaq.htm for explanation) %P 324 p. %T "Rootkits: Subverting the Windows Kernel" The preface (and therefore the book) begins with a definition of a rootkit. The authors proceed to outline their initial interest in the phenomenon, and any security professional who understands the centrality of system internals can begin to see the importance of the work. Chapter one addresses a major selling point (in the blackhat mindset) for rootkits: the evasion of detection. Concentrating on this aspect, the material outlines what a rootkit is, and is not, noting also that the programs need not be limited to illegal activities but do have legitimate uses. Subversion of the core of the operating system is examined in chapter two, although this is limited to the creation of device drivers. (This chapter again raises the issue of whether a book investigating the breaking of a system can provide valuable advice when it comes to protecting computers. While some works do; Hoglund, along with Gary McGraw, having created an example in "Exploiting Software" [cf. BKEXPLSW.RVW]; this particular material concentrates on items of interest in the process of producing rootkits. The limited sections dealing with more theoretical considerations would be those of greater interest to the security community.) Chapter three explores some hardware related items, although there are others that could be perused, and most of those surveyed may be initiated in hardware, but operate primarily in the software realm. Hooking of interrupts and functions is covered in chapter four, at both a kernel and user level. Chapter five reviews various means of directly patching software. (Much of this material should be familiar for those who have studied operations of older viruses.) The interception techniques addressed in chapter four are extended, in chapter six, to include adding new "layers" to existing device drivers. The operating system kernel uses data and other resources in order to perform properly, and chapter seven shows that manipulating these objects can modify the actions of the machine. Although nominally about hardware, chapter eight really concentrates on the patching of firmware. Chapter nine examines covert channels, but the explanation is quite poor, and most of the space is dedicated to listings of program code. Rootkit detection is discussed in chapter ten. It is interesting to note that analogies of antiviral change detection and activity monitoring are mentioned, but there is no consideration of signature scanning. "Rootkits" does raise a number of interesting topics, and much of the material could be of use to those charged with protecting systems. However, the content is not as valuable as that presented in "Exploiting Software." There is, of course, much that will be of assistance for those writing legitimate rootkits, but this would be a fairly limited audience. copyright Robert M. Slade, 2005 BKROOTKT.RVW 20051023 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