The RISKS Digest
Volume 26 Issue 47

Monday, 6th June 2011

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

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…

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
Info on RISKS (comp.risks)

99% of Android phones leak secret account credentials (Dan Goodin)

Monty Solomon <monty@roscom.com>
Wed, 18 May 2011 10:04:11 -0400

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/


SCADA Holes Allowed Remote Takedown of Siemens Systems (Paul Roberts)

Jeremy Epstein <jeremy.epstein@sri.com>
Fri, 20 May 2011 12:40:38 -0400

Paul Roberts <http://threatpost.com/author/Paul%20Roberts>
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" <http://www.nsslabs.com/blog/>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
<https://threatpost.com/en_us/blogs/glass-dragon-chinas-cyber-offense-obscures-woeful-defense-042711>.

Jeremy Epstein, Senior Computer Scientist, SRI International
1100 Wilson Blvd, Suite 2800, Arlington VA  22209 jeremy.epstein@sri.com


Canada Post Strike (Nestor E. Arellano)

Gene Wirchenko <genew@ocis.net>
Mon, 06 Jun 2011 11:53:37 -0700

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.


"InfraGard" passwords/logins exposed

danny burstein <dannyb@panix.com>
Mon, 6 Jun 2011 00:03:10 -0400 (EDT)

"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


Risks of comp.risks resolved: new USENIX feed

"Peter G. Neumann" <neumann@csl.sri.com>
Sun, 5 Jun 2011 4:58:22 PDT

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.


RISKS-related Slashdot items

Werner U <werneru@gmail.com>
Wed, 1 Jun 2011 09:39:50 +0200

  [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?


Re: Russian Company Cracks IOS 4 Hardware Encryption (RISKS-26.46)

"john.beattie" <jkb@hignfy.demon.co.uk>
Mon, 6 Jun 2011 13:14:54 +0100

"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 <foo> for <bar> reasons" leaves open a great
deal of space for an adjective just before <bar>. Here are some examples,
specialised to the above case:

... lousy        commercial reasons...
... non-existent commercial reasons...
... unreasonable commercial reasons...


Re: "Automatic Updates" considered Zombieware (Baker, RISKS-26.45)

Martin Ward <martin@gkc.org.uk>
Mon, 6 Jun 2011 11:55:48 +0100

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/


Re: ""Automatic Updates" considered Zombieware" (Baker. Loughran)

Peter Houppermans <peter@houppermans.com>
Sun, 05 Jun 2011 09:56:43 +0200

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..


Re: "Automatic Updates" considered Zombieware (Loughran, RISKS-26.46)

Dimitri Maziuk <dmaziuk@bmrb.wisc.edu>
Sun, 05 Jun 2011 11:27:36 -0500

> Date: Wed, 25 May 2011 10:38:47 +0100
> From: Steve Loughran<steve.loughran@gmail.com>
> 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.)


Re: Car Talk and Talk and... (White, RISKS-26.45)

Ben Kamen <bkamen@benjammin.net>
Sun, 05 Jun 2011 15:40:28 -0500

> 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)


Cars that drive themselves (Re: Loughran out of band communication)

Jonathan Kamens <jik@kamens.us>
Mon, 06 Jun 2011 13:48:56 -0400

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.


`A Google Oddity' is not a Y2K bug (Re: Loughry, RISKS-26.46)

Sidney Markowitz <sidney@sidney.com>
Mon, 06 Jun 2011 00:08:26 +1200

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


Re: Virtual slave labor in China (Thorson, RISKS-26.46)

Geoffrey Brent <gpbrent@optusnet.com.au>
Sun, 05 Jun 2011 20:01:36 +1000

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.


Re: Study Sees Way to Win Spam Fight (PGN, RISKS-26.46)

Kevin Fu <kevinfu@cs.umass.edu>
Sun, 5 Jun 2011 22:32:06 -0400

>  [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]

Please report problems with the web pages to the maintainer

x
Top