bugtraq - Re: Vulnerabilities in some SCADA server softwares

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 23 Mar 2011 11:27:46 -0400
From: Kent Borg <kentborg@...g.org>
To: "J. Oquendo" <sil@...iltrated.net>
Cc: Luigi Auriemma <aluigi@...istici.org>, bugtraq@...urityfocus.com
Subject: Re: Vulnerabilities in some SCADA server softwares

J. Oquendo wrote:
> At what point in time did you try contacting any of the vendors for 
> these issues?

SCADA systems are infamous for being terribly insecure.  (You can search 
the internet for demonstration video of equipment catching fire because 
of such bugs.)  SCADA manufacturers seem to have a firewall mentality 
that excuses them from needing to be secure. 

I am not at all surprised to see these bugs, though I do cringe at how 
embarrassing they are.  Heaping some embarrassment on the vendors seems 
well deserved.

The downside to doing it publicly: Just because SCADA systems 
communicate with the public internet and so are directly or indirectly 
vulnerable doesn't mean the people who run them *intended* to hook them 
up to the internet nor are aware what wire got plugged in or thumbdrive 
transferred that made the bridge.  They probably think they are 
invulnerable, I bet the Iranians thought so.  The manufacturers might 
release a bug fix and customers (who discovered they have some equipment 
for which there is an upgrade), maybe won't think they need them.

Also, once I have my clothespin factory, or nuclear plant, up and 
running smoothly, how attractive is it to start applying "upgrades"?  
Should I validate them first on my testbed nuclear power plant?  It is 
hard to test a SCRAM adequately.  And if my vendor is so incompetent as 
to write so many security holes into the software in the first place, 
how much faith should I have in a different programmer, maybe years 
later, patching code s/he probably doesn't understand as well as the 
first sloppy programmer did.  And who gets this thankless task?  The 
senior programmer who is working on the new project that is already 
behind schedule, or the new guy?  Does the new guy fully understand the 
build procedure to even make all the parts correctly?  Do they even have 
good source code control to be sure they know what sources the old (and 
largely working version) was built from?  Are the upgrade procedures 
reliable and understood by the vendor and by the worker the customer 
will send out on the factory floor with a CD-ROM in hand?  (Will that 
worker stick the CD-ROM in the right slot and reboot the right box?) 

Maybe. 

Would I install a stack of SCADA upgrades to *my* functioning factory?  
Maybe not.

Scary, scary stuff.

Security needs to be designed in, implemented carefully each step along 
the way, and reviewed.  Instead people with "security" in their job 
title so often seem to think security is firewalls, buying anti-virus 
support contracts, and requiring use of MS Outlook and Internet Explorer.

-kb, the Kent who will shut up now.