[SCADASEC] Fwd: [Full-disclosure] CORE-2008-0129 - WonderwareSuiteLink Denial of Service vulnerability

[Marc Tritschler]

The most extreme risk here is "if this vulnerability is exploited someone
could die."  But there are a whole host of other risks, related to the
process of assessing and potentially addressing the vulnerability.

There is a risk that Suitelink users don't find out about this
vulnerability.
There is a risk that those users that do find out about this vulnerability
don't assess its potential impact on their business properly.
There is a risk that Suitelink users don't know that they are Suitelink
users (and therefore don't do anything about this vulnerability).
There is a risk that Suitelink users won't be in a position to patch their
system(s), because they don't have the support to do it.

One of my clients does indeed use Suitelink.  It's embedded in a control
system implementation, supplied by a major vendor, and located in an
unmanned facility (I am being deliberately vague here for confidentiality
reasons).  I made them aware of this vulnerability yesterday as soon as I
became aware that it had been disclosed.

The reason that I know that Suitelink is used in this application is that I
was working with the team that did a cyber security assessment of the
facility a couple of years ago, and we picked up that this was being used
when we were developing the asset register and architectural overview of the
system.  Note: much of this work was done by intensive questioning of the
vendor - the manuals didn't provide enough detail.

So I agree with Jake that many people won't even know that they use
Suitelink, but I don't agree that consultants won't know to look for it -
this one did!

Regards,

Marc Tritschler
KEMA

2008/5/6 Kevin Finisterre (lists) <kf_lists at digitalmunition.com>:

>
> On May 6, 2008, at 11:35 AM, Brodsky, Jake wrote:
> >
> > So Core Security publishes this as if it's just another IT bug.  It's
> > not.  This is going to kill someone some day.
>
> Sure it is... you can implement any software in a manor that someone's
> life can depend on it,
> your industries products aren't special just because everyone is so
> touchy about them. If this bug
> kills  someday thats because someone was not diligent in patching a
> known problem. More importantly
> if someone dies from this the cause is that the original vendor was
> not diligent enough to think about
> secure coding and QA testing before putting a product out into the
> market. As users of the products you
> too are at fault for just blindly expecting that your vendors products
> are rock solid and flawless. CORE is
> simply the messenger... don't shoot them... shoot the vendor... shoot
> the people that fail to fix the issue
> after its been disclosed. Shoot yourself in the foot once for not
> doing your own due diligence on the
> products you use.
>
> > And it's not just us asset owners, it's the engineering consultants
> > too.
> > How many of THEM will know to look for this?
>
> Well now that there is some visibility level with the bug... I would
> go out on a limb here and say
> a heck of a lot more of THEM than there would be had this bug been
> privately held from public
> eye.
>
> > I admit, we have a severe education problem here.  But even if there
> > were enough smarts in the field to patch this stuff in a timely
> > fashion,
> > we still have logistics of testing, deployment scheduling, and so
> > forth.
>
> Great... so get started... no you are armed with the information to
> get this testing underway...
>
> >
> > This is why you can't "just publish" the bugs.
>
> This is EXACTLY why you publish bugs... to get folks out of their
> comfort zone and to strongly
> encourage them to stop leaving things the way they are simply because
> they work or because its
> the easiest thing to do.
>
> >
> > If you're an asset owner, set your industrial network defense level to
> > Orange (no laptops on the ICS networks, no new software, halt
> > development) until you can verify the need for this patch.
>
> If you are an asset owner get some sort of processes in place to
> handle patches in a timely
> manor for ALL of your products , not just the ones that have the most
> public exposure. Don't just
> sit back and whimper because someone releases a bug. If you have to go
> into freak out mode every
> time a patch comes out ... there is a problem.
>
> Maybe the power industry has a different line of thinking but in my
> mind if a part of your infrastructure
> is so sensitive that if you breath on it wrong it breaks, now is a
> good time to start looking at making it a
> bit more robust and resistant to outside influences.
>
> Proactive vs. Reactive...
>
> -KF
>
>
> >
> > Jake Brodsky
> >
> >
>
> _______________________________________________
> To unsubscribe from this mailing list, please visit:
> http://news.infracritical.com/mailman/listinfo/scadasec
>
> To review our privacy statement, please visit:
> http://www.infracritical.com/privacy.html
>
> scadasec at news.infracritical.com
> http://news.infracritical.com/mailman/listinfo/scadasec
>