[SCADASEC] Implications of SuiteLink's flaw

[Matthew Franz]

Jake,

Inline. I didn't explicitly call them out but I have my own IS's vs.
SHOULD BE's as well :)

> Here is my take on the SuiteLink flaw:  This isn't just a denial of
> service.  It's a denial of service that can be perpetrated through
> firewalls using well crafted packets designed so that the slssvc process
> will fault.  So we're not just talking about clogging a WAN or LAN with
> a broadcast storm, we're talking about something that even at low
> bandwidths will be significant because it will cause the process to fall
> on the floor.

Agree. This is what we used to call "single packet killers" (and the
same could be said for the COTP/ICCP vulns, BTW)

>
> What we have here is an argument of what IS versus what SHOULD BE.
> Industry SHOULD BE watching these public notice places, but they don't.
> Unless we're dealing with a large organization, it's unlikely they'll
> have anyone who knows how to read these things, knows what products are
> in use, and knows what to do with them.
>
> Another point: even if the ISAC organizations are just news clipping
> services, they SHOULD BE screaming this at the industry from the
> rooftops.  I just checked WaterISAC-BASIC and they had NOTHING about
> this disclosure.  This is still more reason why industrial users aren't
> going to find out about this stuff.

So you are saying that in the organizations in question that don't
have this awareness and are not tracking vulnerabilities in
traditional  IT platforms. Microsoft, Cisco, Oracle, etc?

It is different problem if some folks are already managing
vulnerabilities and have appropriate workflow in place for *some*
platforms vs. nobody knowing anything about *any* of their platforms.

This particular vuln showed up in secunia and securityfocus so if
these organizations already have subscriptions to these sorts of
services already (which I'm assuming you would say the IT Security or
Compliance functions don't in your experience) they it is just a
question of knowing which platforms need (yeah, I know not as simple
as it sounds). Then this isn't (entirely) the fault of the Operations
guys. Security/Compliance organizations have a responsibility to know
what is running on their networks. And is a more fundamental issue
above and beyond their control systems.

> How in the world is anyone going to act on this if they don't know to
> look for it?  Why are we publishing this?  To make it easier for red
> teams to look up this flaw and write software for it?

If they know what their hardware assets and software assets are and
they are tracking public disclosures, then what is the problem?

My problem with public disclosure is that if vulnerabilities are only
disclosed through customer support channels (which the compliance
organizations don't have access to, right?) then there is no way they
can monitor compliance or make risk decision (with the input from the
platform owners). There is no oversight. When I ran product, I was
*GLAD* to get that little note/ticket for a vuln that had been
disclosed. I usually knew about them myself, but if I only have access
to vuln data on the products I run (and the compliance org doesn't)
this is a case of the fox watching the henhouse.

> Most of the arguments on the merits for public disclosure seem
> predicated on the notion that there are sufficient people out there who
> will see this notice and to make a difference.  With nothing more than
> my personal experience on the inside of this business, I have serious
> doubts that this case for public disclosure is a reality.  Again, this
> is not what SHOULD BE; this is what IS.
>
> It would have been nice if we could have flagged this software as
> Control System specific in some way.  If we could build a list of major
> industrial control systems users, engineers, IT managers, etcetera, then
> we could quietly disclose this flaw with the provision that after one
> year it will go public.  That will give the industry time to react to it
> without giving the high school kids or the news media something to play
> with.

I would agree that the advisories didn't have much background
information in particular. Probably because the finders didn't have
experience. I would guess that if the vuln had been submitted to
US-CERT (or a control system CERT, which I generally oppose) and it
had been *their* advisory it might have had more explicit information.
But this came from the finder.

This is a great idea for those in the club. But those that aren't in
the club aren't going to play by the rules.

> The reason I use a one year time frame is because some installations may
> take a month to validate a patch in their environment, and several more
> months schedule an update.  We want to make sure that there is
> sufficient opportunity for users/asset owners to get around to updating
> their critical assets.  Initially, a year seems appropriate.  Later it
> might be shortened to as little as six months.  Anything less than that
> could expose major SCADA systems to attack.

The problem is the cat is out of the bag. It isn't just control
systems researchers, consultants finding and filing and disclosing
bugs anymore. It is now more mainstream IT vendors & consulting firms.
And they are going to use the same policies and practices for any
other vulns they report & disclose.

>
> Going public also works better if you have a patch distribution system
> in your infrastructure.  That does not exist in most control systems
> either.  I guess once again, we can argue that it SHOULD BE.  However,
> there isn't a safe way to do this.  Restoring a backup of the previous
> version isn't going to clean up the threat to life and limb or the
> physical mess this could make on the factory floor.

I would guess that the patch distribution mechanisms now available on
the IT side did not predate public disclosure but came about as a
result of public disclosures and the mayhem that resulted :)

But It isn't a question of the vendor or the community or even a
coordination center. Its about the finders, unless somehow it becomes
illegal to disclose. CORE (and others so far) have been relatively
reputable and responsible.  Others might not be.

- mdf
-- 
Matthew Franz
http://www.threatmind.net/