precedence: bulk Subject: Risks Digest 26.47 RISKS-LIST: Risks-Forum Digest Monday 6 June 2011 Volume 26 : Issue 47 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at as The current issue can be found at Contents: 99% of Android phones leak secret account credentials (Dan Goodin via Monty Solomon) SCADA Holes Allowed Remote Takedown of Siemens Systems (Paul Roberts via Jeremy Epstein) Canada Post Strike (Nestor E. Arellano via Gene Wirchenko) "InfraGard" passwords/logins exposed (Danny Burstein) Risks of comp.risks resolved: new USENIX feed (PGN) RISKS-related Slashdot items (Werner U) Re: Russian Company Cracks IOS 4 Hardware Encryption (John Beattie) Re: "Automatic Updates" considered Zombieware (Martin Ward, Peter Houppermans, Dimitri Maziuk) Re: Car Talk and Talk and... (Ben Kamen) Cars that drive themselves (Jonathan Kamens) `A Google Oddity' is not a Y2K bug (Sidney Markowitz) Re: Virtual slave labor in China (Geoffrey Brent) Re: Study Sees Way to Win Spam Fight (Kevin Fu) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 18 May 2011 10:04:11 -0400 From: Monty Solomon Subject: 99% of Android phones leak secret account credentials (Dan Goodin) Dan Goodin in San Francisco: 'Impersonation attacks' target Google services Posted in Security, 16 May 2011 The vast majority of devices running Google's Android operating system are vulnerable to attacks that allow adversaries to steal the digital credentials used to access calendars, contacts, and other sensitive data stored on the search giant's servers, university researchers have warned. The weakness stems from the improper implementation of an authentication protocol known as ClientLogin [1] in Android versions 2.3.3 and earlier, the researchers from Germany's University of Ulm said. After a user submits valid credentials for Google Calendar, Contacts and possibly other accounts, the programming interface retrieves an authentication token that is sent in cleartext. Because the authToken can be used for up to 14 days in any subsequent requests on the service, attackers can exploit them to gain unauthorized access to accounts. ... http://www.theregister.co.uk/2011/05/16/android_impersonation_attacks/ ------------------------------ Date: Fri, 20 May 2011 12:40:38 -0400 From: Jeremy Epstein Subject: SCADA Holes Allowed Remote Takedown of Siemens Systems (Paul Roberts) Paul Roberts http://threatpost.com/en_us/blogs/scada-holes-allowed-remote-takedown-siemens-systems-051911 Security researcher Dillon Beresford decided not to present a talk at the TakedownCon in Dallas on Thursday, citing concerns about mayhem that could have resulted. But in an e-mail, he told Threatpost that the vulnerabilities could allow remote attackers to start or stop Siemens Programmable Logic Controllers (PLCs) and harvest information from the devices. Beresford, who works for security testing firm NSS Labs, told Threatpost that he found "multiple vulnerabilities in the Simatic S7 PLC controllers" and had developed proof of concept code to take advantage of the holes using the Metasploit Framework, a free penetration testing tool. The holes in question could allow remote attackers to "put the PLC CPU into STOP mode," "put the PLC CPU into RUN mode" as well as dump the memory and scrape device information from the PLC, including the model, firmware version, serial number and PLC name. Beresford said he had already submitted the exploits to Metasploit, and notified both the U.S. Computer Emergency Response Team (CERT) and Siemens of the holes on May 8. A Siemens spokeswoman on Thursday said she was unaware of the vulnerabilities or the suspended TakeDownCon controversy. However, a company spokesman told Wired.com that Siemens is aware of the vulnerabilities in its PLCs and appreciates the disclosure by NSS Labs. Speaking to Wired.com, Beresford said that the U.S. Department of Homeland Security had expressed concern about publicizing the holes, but that the decision to pull the talk was his own. "Based on my own understanding of the seriousness behind this, I decided to refrain from disclosing any information due to safety concerns for the consumers that are affected by the vulnerabilities," Beresford told Threat Level, adding that "DHS in no way tried to censor the presentation," he told Wired. In a blog post on Wednesday, NSS Labs chief Rick Moy acknowledged that Beresford had discovered "significant, additional vulnerabilities in industrial control systems" and responsibly disclosed those to the affected parties. "Due to the serious physical, financial impact these issues could have on a worldwide basis, further details will be made available at the appropriate time," he wrote. The Siemens Simatic is a line of programmable logic controllers that are used to provide programmatic access to a wide range of physical devices, including industries such as water distribution and treatment, electricity generation, manufacturing and so on. Simatic PLCs were one of the targets of the Stuxnet worm, which was used to disable Iran's uranium enrichment facilities at Nantaz. Beresford has been researching the Siemens vulnerabilities since March and finished his work in early May. In recent months, he has published information about holes in other SCADA products at use both here and abroad. In January, he disclosed a critical hole in a SCADA application, KingView, from the Beijing based firm Wellintech. http://threatpost.com/en_us/blogs/researcher-holes-abound-chinese-scada-011111 He has also publicized his research on vulnerabilities in Chinese government systems, which he say are woefully underprotected . Jeremy Epstein, Senior Computer Scientist, SRI International 1100 Wilson Blvd, Suite 2800, Arlington VA 22209 jeremy.epstein@sri.com ------------------------------ Date: Mon, 06 Jun 2011 11:53:37 -0700 From: Gene Wirchenko Subject: Canada Post Strike (Nestor E. Arellano) http://www.itbusiness.ca/it/client/en/home/News.asp?id=62782 Postal strike pain avoided by well-wired businesses While small businesses can expect delays and disruptions to hamper their operations, businesses can use a combination of technology and no-tech alternatives to lessen impact of the postal strike. Here's how. Nestor E. Arellano, *IT Business*, Jun 2011 opening text: "The cheque is in the mail," will probably be among the most dreaded phrases for many small and medium sized businesses (SMBs) as Canada's postal workers continue their rotating strikes. The Canadian Federation of Independent Business (CFIB) estimates that the strike may cost many SMBs in the country as much as $250 a day as they anticipate widespread instances of delayed invoices and deliveries. The article relates difficulties that could be faced. We are not as wired as we might be. ------------------------------ Date: Mon, 6 Jun 2011 00:03:10 -0400 (EDT) From: danny burstein Subject: "InfraGard" passwords/logins exposed "InfraGard" is that "public-private partnership" between utilities, similar public agencies, and.. the FBI. It's a clearinghouse of sorts, with chapters all over the country. Further discussions about the politics are best left elsewhere. It seems that the Atlanta chapter was a bit careless with their online security, and... [Atlanta Journal] The FBI announced Sunday it shut down an Atlanta-based website that tracks cyber-crime after the site was compromised by a mysterious, yet increasingly audacious group of hackers. InfraGard Atlanta, a nonprofit partnership between local business, government and academic security experts and the FBI, was hacked late last week by Lulz Security. LulzSec, as it's known on-line in cybersecurity channels, hijacked the InfraGard site and published the email addresses, usernames and passwords of its 180 members. rest: http://www.ajc.com/news/hackers-hit-atlanta-fbi-968059.html info about InfraGard: http://infragard.org/ https://secure.wikimedia.org/wikipedia/en/wiki/InfraGard ------------------------------ Date: Sun, 5 Jun 2011 4:58:22 PDT From: "Peter G. Neumann" Subject: Risks of comp.risks resolved: new USENIX feed I owe enormous thanks to Ed Ravin, who has created a new USENIX gateway for RISKS at panix.com, which should resolve the problem of missing issues. The old gateway at UC Berkeley has become disfunctional, and Michael Sinatra -- who helped keep RISKS running through it for many years -- is no longer at UCB. I am very grateful to him for his past help. In addition, thanks to you who have been reading RISKS as comp.risks and goading me often enough about the sporadic absence of comp.risks issues that I was suitably encouraged into finding another avenue -- which Ed Ravin has now seamlessly provided. ------------------------------ Date: Wed, 1 Jun 2011 09:39:50 +0200 From: Werner U Subject: RISKS-related Slashdot items [Source: Slashdot Daily Newsletter, Copyright 1997-2010, Geeknet, Inc. All Rights Reserved. Comments owned by the poster. 2011 All Rights Reserved. Geeknet, Inc. http://geek.net/] In this issue: * Chinese Military Admits Existence of Cyberwarfare Unit * China Censors Web To Curb Inner Mongolia Protests * The Next Phase of Intelligent TVs Will Observe You * PBS Web Sites and Databases Hacked * US Nuclear Power Enters the Digital Age * Germany To End Nuclear Power By 2022 * Activists Destroy Scientific GMO Experiment * What's Killing Your Wi-Fi? ------------------------------ Date: Mon, 6 Jun 2011 13:14:54 +0100 From: "john.beattie" Subject: Re: Russian Company Cracks IOS 4 Hardware Encryption (RISKS-26.46) "ElcomSoft has not explained how it hacked the hardware-stored key system in detail for commercial reasons..." What commercial reasons? Is ElcomSoft intending to make money from this knowledge? More generally, "Smith declined to for reasons" leaves open a great deal of space for an adjective just before . Here are some examples, specialised to the above case: ... lousy commercial reasons... ... non-existent commercial reasons... ... unreasonable commercial reasons... ------------------------------ Date: Mon, 6 Jun 2011 11:55:48 +0100 From: Martin Ward Subject: Re: "Automatic Updates" considered Zombieware (Baker, RISKS-26.45) I use Linux on my work machine, but occasionally need to run a Windows program. So I set up a virtual machine to install a "vanilla" copy of Windows XP with no other programs installed. The system requirements page for XP suggests that 1.2GB of disk space is required. I was only going to install a couple of extra programs, so I decided to be generous and give it 4GB of virtual hard drive to play with. (http://support.microsoft.com/kb/947311 says "1230 MB peak usage during installation" for the total hard disk space required for the latest version of XP). After nursing it through the install process, with its endless cycle of "click OK", "reboot" etc. I ended up with a complete installation which indeed used about 1.2GB of hard drive space. Then the message popped up: "There are 83 critical security patches to download"! The virtual machine started downloading and installing critical security patches. Eventually, another message popped up: "Hard drive space exhausted". So I started again, from scratch, this time with an 8GB virtual hard drive. After installing all the "critical security patches" and no other programs, the machine was using a total of 6.5GB of hard drive space. So the *real* system requirements for Windows XP are: 1.2GB for the operating system, plus 5.3GB for critical security patches! I recently installed the new Linux distribution Mageia Linux: this includes the operating system plus thousands of packages, including Office, Internet, sound and video programs, even a collection of games. Total disk space used is just 4.2GB. STRL Reader in Software Engineering and Royal Society Industry Fellow http://www.cse.dmu.ac.uk/~mward/ ------------------------------ Date: Sun, 05 Jun 2011 09:56:43 +0200 From: Peter Houppermans Subject: Re: ""Automatic Updates" considered Zombieware" (Baker. Loughran) I have never been a fan of automatic updates, especially not since the Microsoft "Windows Genuine Advantage" spyware - I like to see what gets installed. However, there are not just backdoor infection risks to consider regarding uncontrolled update/patch/renew/monitoring behaviour. Anyone who travels knows how precious bandwidth can get. Especially when traveling abroad, the mobile phone companies start rubbing their hands in anticipation of fat profits.. What happens when you go online? Every application with its own updater jumps on the feeble mobile link and effectively absorbs most of the bandwidth, not to mention anti-virus products which have never quite worked out the idea of diff files (on that topic, why does a Mac anti-virus product need a massive database of Windows problems?). The consequential cost is thus very high - the cost of bandwidth and the time you are prevented from doing your work. On the Mac, I use HandsOff to keep an eye on what talks to who (and where it writes). Given its habits, the Adobe Updater has received a permanent network ban, but it would be unfair to state it's the only one with unsavory habits.. ------------------------------ Date: Sun, 05 Jun 2011 11:27:36 -0500 From: Dimitri Maziuk Subject: Re: "Automatic Updates" considered Zombieware (Loughran, RISKS-26.46) > Date: Wed, 25 May 2011 10:38:47 +0100 > From: Steve Loughran > Subject: Re: "Automatic Updates" considered Zombieware > ... Who knew that Excel spreadsheets could host Flash content with 0-day > exploits until RSA got owned that way? Who knew that Acroread had > JavaScript support until exploits for it started appearing in the > wild. Keeping every Internet-connected application is essential -- which > means every application you have installed. This may sound reasonable until you ask yourself why you'd need a JavaScript interpreter inside an image viewer. Or a Flash player built into a spreadsheet. Sure featuritis and bloat didn't start with automatic updates. That doesn't make automatic updates any less of a zombieware. > ... At least on linux, the updater tools, apt and yum, do keep everything > up to date in one go, even if there is a potential lag between a > vendor-released patch and the new binaries getting into the Linux > repositories. Most major Linux players have been playing "catch up and overtake [windows, enterprise, osx, google, whatever comes next] (pick any five)", so would it surprise you if told you that the latest FermiLab rebuild of RedHat (and presumably RHEL6 as well) by default updates itself in the background whenever the scheduler feels like it? (Except for a couple of packages that require a reboot -- no idea what it does with those since I disabled the whole thing the moment I found it.) ------------------------------ Date: Sun, 05 Jun 2011 15:40:28 -0500 From: Ben Kamen Subject: Re: Car Talk and Talk and... (White, RISKS-26.45) > Any feature in cars that allows drivers to pay less attention to the road > isn't going to increase road safety; it will become another risk > compensation feature, especially in cities: "now you can check in to > facebook while driving!" I have to emphatically agree here. Facebook in the car? I'm surprised insurance industries haven't gotten involved on this or better yet, the liability divisions of the car companies haven't said, "you want to add WHAT!?!?" Sigh -- Technology. Awesome when it actually does something that improves our lives more than just shortening the response time for Generation I.G. (Instant Gratification) ------------------------------ Date: Mon, 06 Jun 2011 13:48:56 -0400 From: Jonathan Kamens Subject: Cars that drive themselves (Re: Loughran out of band communication) On 6/5/2011 8:29 AM, Steve Loughran wrote: > I don't disagree that drivers are inattentive, I'm just not convinced > that people who make cars care about not hitting people. Take for > example, the European safety tests of the Jeep Cherokee, which scored > zero out of five on pedestrian safety I do not see an obvious correlation between whether car manufacturers choose to build pedestrian safety features into the exterior design of their vehicles, and whether they are capable of building self-driving cars which don't hit pedestrians. Cars don't hit pedestrians; drivers hit pedestrians. Once the car is doing the driving, it's a whole different ballgame, and I think it would be inadvisable, at best, to attempt to draw lessons about one from the other. Consider, for example, that no matter how dangerous a car's exterior design is to pedestrians in an accident, the car's manufacturer rarely gets sued if the driver hits a pedestrian; the driver does. In contrast, when self-driving cars are introduced, you can bet that the first time a self-driving car hits a pedestrian, there'll be a big honkin' lawsuit. Car manufacturers have much deeper pockets than individual drivers. In short, there is a great deal of financial pressure on them to make the self-driving cars safe, and almost no financial pressure on them to make their cars' exterior designs safer for pedestrians (exactly the opposite, in fact, since car buyers can find pedestrian safety features unattractive). > We've seen from the various RISKS-reported GPS navigation disasters > that having your vehicle tell you which route to take allows them to > abdicate navigation and introduce the "car drives off a cliff" story; Again, you are comparing apples to oranges. Yes, I'm aware of all the funny and scary GPS stories, but there are two stark differences between those and what we're discussing there, differences which make parallels between the two all but meaningless: * With GPS, there's still a human in the loop. The point of self-driving cars is to have computers doing things that they're, frankly, better at than people. * GPS navigation systems rely on the accuracy of remotely maintained databases which are known to have accuracy issues, whereas the self-driving cars currently under development of which I'm aware rely only on local sensors for safety-related decision making. > Anything which does the same for road safety increases the risk that > people will trust the technology to be 100% reliable, when that's not > going to be the case. You are, frankly, still missing the point. The question is not whether self-driving cars will always avoid hitting pedestrians, but rather whether they can be more successful at doing so than people, and the research and empirical results would seem to suggest that the answer to that question is yes. > While I am confident the software will improve over time, I'm not sure > when we are going to reach a point where we can trust the vehicles and > their embedded systems to work. This is an obvious question and a reasonable one to ask. It is not, however, the question you raised in your RISKS posting. You made the unqualified assertion, "Any feature in cars that allows drivers to pay less attention to the road isn't going to increase road safety." This assertion shows a fundamental misunderstanding of what the researchers into self-driving cars are trying to accomplish; it is in my opinion excessively alarmist; and it is completely unsupportable. ------------------------------ Date: Mon, 06 Jun 2011 00:08:26 +1200 From: Sidney Markowitz Subject: `A Google Oddity' is not a Y2K bug (Re: Loughry, RISKS-26.46) You can see the actual cause of the "Google Oddity" going to the Google Books advanced search at http://books.google.com/advanced_book_search and searching for one of the example phrases such as nanotechnology or ribosome, selecting "Return content published between" 1890 and 1930. That will find a number of books whose publication date is entered incorrectly in Google's database. The Google Ngram search results appear to be a simple case of GIGO, not a Y2K problem. Sidney Markowitz http://sidney.com ------------------------------ Date: Sun, 05 Jun 2011 20:01:36 +1000 From: Geoffrey Brent Subject: Re: Virtual slave labor in China (Thorson, RISKS-26.46) Mark Thorson writes: "The article claims that the trade in virtual gold is outside the control of the proprietors of World of Warcraft, but how can that be possible? They control every aspect of their virtual world. If they don't control it, it is because they have decided not to control it." Omnipotent is not omniscient. If Alex the Paladin puts a dozen bars of khorium ore up on the auction house, and Bob the Warlock buys them for ten thousand gold... is Bob a gold seller using the transaction as a way to pass gold to Arthur? Or just a schmuck with more money than sense? Blizzard has plenty of reason to want gold sellers gone. They annoy legit players by spamming and distorting the game economy, and when they're not farming they make gold by stealing accounts and selling people's goods. As a result, Blizzard have to hire more admins to restore hacked accounts. But catching money-launderers is a hard problem; I think it's unduly harsh to claim that Blizzard just don't care. ------------------------------ Date: Sun, 5 Jun 2011 22:32:06 -0400 From: Kevin Fu Subject: Re: Study Sees Way to Win Spam Fight (PGN, RISKS-26.46) > [Nick Weaver presented their paper at the IEEE Symposium on Security > and Privacy in May 2011. PGN] Actually, the presenter was Kirill Levchenko from UCSD. I know, because I was the session chair. [Thanks, Kevin, I was misinformed (to quote Humphrey Bogart). I tried to register for SSP 2011 on the final day of preregistration, but they were *already sold out*. Therefore, I missed the talk (even though I am the only person left who was registered for both the first SSP in 1980 and the most recent previous one in 2010). To set the record straight, the paper to which John Markoff referred in the cited article was actually the best paper of SSP 2011 -- Click Trajectories: End-to_End Analysis of the Spam Value Chain, authored by Kirill Levchenko, Neha Chachra, Brandon Enright, Mark Felegyhazi, Chris Grier, Tristan Halvorson, Chris Kanich, He Liu, Damon McCoy, Andreas Pitsillidis, Nick Weaver, Vern Paxson, Geoffrey Voelker, and Stefan Savage -- assuming that the printed program had no msipelingz. PGN] ------------------------------ Date: Thu, 29 May 2008 07:53:46 -0900 From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman Web interface can be used directly to subscribe and unsubscribe: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request@csl.sri.com containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe@csl.sri.com or risks-unsubscribe@csl.sri.com depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. The full info file may appear now and then in RISKS issues. *** Contributors are assumed to have read the full info file for guidelines. => .UK users should contact . => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. *** NOTE: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks for current volume or ftp://ftp.sri.com/VL/risks for previous VoLume redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: for browsing, or .ps for printing ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: ------------------------------ End of RISKS-FORUM Digest 26.47 ************************