Re: Vulnerabilities in some SCADA server softwares

[Jamie Riden <jamie.riden () gmail com>]

The correct time for vendors to do their own homework on SCADA was
2003 - that was the wakeup call. Anyone who has programmed for SCADA
has always wondered what would happen if they started poking
undocumented values into undocumented registers, but may not have the
luxury of trying it out.

Having been a security/network admin, there are many things that can
be done when you know of a vulnerability - snort sigs, snort flexible
response (thanks Jeff!), firewall configs, etc. I've done them before
when vulns have been published before patches, and it is much better
knowing that something is up than not. Do not rely on your vendor to
keep you up to date on security issues.

cheers,
 Jamie

On 23 March 2011 18:36, J. Oquendo <sil () infiltrated net> wrote:
> On 3/23/2011 2:13 PM, Theo de Raadt wrote:
> > > If *any* threat exists,
> > > that threat is increased by public exposure of unmitigated attack
> > > methodology
> > I think you have it wrong.
> >
> > Public exposure increases the visibility, and therefore customers
> > install the patches quicker.
> >
> > Without public visibility, they will keep running the old code.
>
> You're flawed in your response: "Public exposure increases the
> visibility, and therefore customersinstall the patches quicker." ...
> When someone "full discloses" a vulnerability, there is no patch to
> install quicker. This is obvious because there is no patch until either
> the vendor releases one, or staff using the product are capable of
> creating a work-around. In the case of the SCADA environment, we (again)
> are not talking about the potential of a defacement, blue screen, silly
> shell, we're talking about sensor, gears and often so much automation
> that it would be absurd for a SCADA engineer to "go it alone" and try
> create their own patch. Many of these systems don't have the option of
> failing or being taken offline. You also state: "Without public
> visibility, they will keep running the old code" the reality is, no one
> is going to outright replace some of these systems in these
> environments. These are not applications and or systems one can plop
> onto donated boxes. They have no choice BUT to run the code.

-- 
Jamie Riden / jamie () honeynet org / jamie.riden () gmail com
http://uk.linkedin.com/in/jamieriden