On security - SCADA sofware defect (Siemens' WinCC)

[Christopher Browne]

On Thu, Sep 23, 2010 at 10:34 PM, Lennart Sorensen
<lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org> wrote:
> On Thu, Sep 23, 2010 at 10:14:19PM -0400, Mel Wilson wrote:
>> On 10-09-23 11:32 AM, William Muriithi wrote:
>>> Morning pal
>>>
>>> Just came to learn about this virus - Stuxnet.  If you google more on
>>> it, look like work from a well financed organization which make it
>>> petty interesting.
>>>
>>> Now, what though is surprising is that changing the default password
>>> impact the operation of the whole system.  How the f**k is that
>>> acceptable in current times.  That would be like a good reason to
>>> automatically eliminate it from consideration during sourcing I would
>>> think.
>>>
>>> http://en.wikipedia.org/wiki/Stuxnet
>>>
>>> http://www.bbc.co.uk/news/technology-11388018
>>>
>>> Really, am I over reacting a bit by stating an enterprise product
>>> should at least allow password reset?
>>
>> One theory is that it's targeting one specific system:
>>
>> <http://motherjones.com/kevin-drum/2010/09/living-jack-bauers-world>
>
> It sounds to me like someone designed a system where a hardcoded "secret,
> no one will ever know what it is" password is used for devices to talk
> to each other, and the "real" passwords that users set are only used
> by humans to talk to the devices, and if you try changing the "secret"
> passwords, the devices can't talk to each other anymore.
>
> Any system where changing the passwords isn't part of normal setup before
> deployment and is in fact discouraged is clearly broken by design.

I've got a brother who works for Omron, one of the significant vendors
of PLC hardware, and thru his purview of some of the competitive
behaviour that takes place, there's an extra "stack" of complexity
that makes this harder, I suppose to the point of perhaps being
"inherently broken by design."

The vendors are pretty notorious for being mighty proprietary,  They
may have some layer of "interoperable stuff," to satisfy some
requirements, but they want you to buy into Their Stuff, so there's
liable to be really cool interfaces intended to allure you via
improved performance and improved functionality to use Omron-only, or
Siemens-only, or Fanuc, or whomever's lineup.

In a big, hairy, complex system like a nuclear reactor, it's not
unlikely that there's enough subsystems that you're forced to buy into
multiple of these vendors.  Considerable risk of there being weird
islands of different proprietaryness within the same overall system.

And if there are lots of pieces talking to each other, any one
component's password may have to get copied over to dozens of other
components that legitimately need to speak to it.

Now, you've got a significant "security information" management
problem.  Hundreds of devices, talking various protocols, not
uniformly "TCP/IP everywhere," and if you set a different name or
password for a particular component, propagating that to the diverse
set of places where it needs to go is a non-trivial matter.

On "24", they'd make up tech talk about "we're changing the
authentication info and reconfiguring the network."  Which isn't
nonsensical.  (And then talk nonsense about "I need a socket opened
for this."  I don't think they ever knew what a socket actually is...)

That communications process might take minutes or more to work, and
mightn't necessarily be of comfortable reliability.  If it's a
time-sensitive system, trouble could readily come up during those
"minutes or more."

With that as context, I can readily see process engineers, that aren't
forcibly security wonks by interest, training or practice, not being
terribly interested in securing this with highly-localized
authentication data.  It could cause them reliability heartburn on the
average day.

You don't rewrite your whole network's DNS configuration on the fly
just because it's Tuesday; you're as likely to drop a big chunk of the
network on the floor as you are to fix security holes.  And I suspect
that's something like the relevant analogy.

Certainly, there's a grand problem here that there's a lot of
not-very-secure infrastructure.  I don't think it's as easily solved
as "oh, just change some passwords."
-- 
http://linuxfinances.info/info/linuxdistributions.html
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists