As more information continues to come out about the Stuxnet worm and the vulnerabilities that it exploits, it’s becoming increasingly clear that this kind of attack may be a preview of the attacks that are likely to become commonplace in the months and years ahead.

There are several interesting pieces to the Stuxnet puzzle: its use of a zero-day flaw in the Windows shell to spread; the fact that it has drivers and a separate binary signed by two separate digital certificates belonging to legitimate technology vendors; and its use of pre-owned USB drives to infect PCs. But perhaps the most troubling aspect of the Stuxnet attack is that it appears to have been designed specifically to exploit a weakness in a particular SCADA control software package.

The vulnerability itself is as elementary as it comes: a hard-code password built into the WinCC SCADA control system produced by Siemens. The problem is a design flaw that’s common in many purpose-built software packages, and Siemens officials have said that they are advising customer not to change the password, because it could affect the system’s stability and operation. Once the malware is on a WinCC system, it tries to establish a
connection to a remote server and then tries to exfiltrate sensitive
data.

“Changing the access data would impede communication between WinCC and
the database and is therefore not recommended. Tightening up
authentication procedures is being examined,” the company said in an advisory to customers about the Stuxnet attack.

As Chris Wysopal, CTO of Veracode, points out in his analysis of the Stuxnet attack, this all being done the wrong way.

“Siemens has put their customers at risk with this egregious
vulnerability in their software. Worse, in my book however, is all the
customers who purchased the software not knowing of its risk. Software
customers that are operating SCADA systems on critical infrastructure or
their factories with the WinCC Software had a duty to their customers
and shareholders to not purchase this software without proper security
testing,” Wysopal wrote. “We should ask the question, ‘Why didn’t Siemens fix the hard coded
password vulnerability when it was first publicly disclosed?’ They
waited 2+ years and started to fix it only after a worm exploited it. We
should also ask the question, ‘Is it negligence when you don’t fix a
critical known vulnerability and wait for your customers to get
exploited?’”

[block:block=47]

However, the most interesting aspect of all of this is the fact that the attackers behind Stuxnet clearly knew about the vulnerability in the Siemens WinCC system before the malware was written. That implies that the malware authors had some advance intelligence about the configuration of the Siemens software and knew exactly where there was a weakness.

That’s a serious problem, and it’s one that we may be seeing quite a bit more of in the near future. Targeted attacks, with some serious research and planning behind them, are now the order of the day, and as the Stuxnet attack shows, the attackers are most definitely doing their homework.

Categories: Malware, Vulnerabilities

Comments (6)

  1. Anonymous
    1

    As everyone already knows, knowing about a vulnerability in advance is how ALL malware works. The interesting part is that the author of this article doesn’t know that.

  2. Anonymous
    3

    More to the point, most of these SCADA type systems should all be standalone anyway. If they are connected to the net, they are going to get hit sooner or later.

    If they get infected, but cannot send any info out, mostly, who cares?

  3. Anonymous
    4

    These SCADA systems usually are stand-alone.  All of the systems that I work on only use the internet through secure VPN connections and have normal internet access shut completely off via dedicated hardware firewalls.  The real danger here is that these worms can introduce unsafe operating conditions or even disable SCADA systems, causing all sorts of problems.

    If something like this were to get into our electrical grid, there could be real problems.  (Fortunately, most of our grid still uses antiquated technology that really isn’t susceptible to this sort of disruption.  Just wait for the “smart grid” though.  Wheee!!)

     

  4. Anonymous
    6

    “SCADA should be standalone” is no excuse for negligent practice.  Rigorous and proper engineering practices are followed in the construction of industrial facilities from the civil engineering in the foundations to the mechanical engineering to the protective relaying for power systems and critical instrumentation hardware.  These systems have to be thoroughly tested and once in service rigorously maintained, and if negligence is found engineers must bear the full brunt of responsibility.

    However, when it comes to the SOFTWARE, well, if it fails it’s someone else’s fault.  “You aren’t supposed to put it on the internet”, “you need proper perimiter security”, “you need to keep anti-virus up-to-date”.  Those are all definitely essential best practices, but it doesn’t excuse the developer of the application software itself of their portion of responsibility, and from what I’ve seen of most industrial automation software, they are probably about a DECADE behind the times.  Siemens is not alone–almost every other DCS and SCADA vendor out there pukes out garbage code.  I’ve seen a few exceptions, but when the architecture and code  are sound the design is lacking in usability (difficult to configure and insecure-by-default).

    Sure, SCADA systems have pre-commercial-internet origins and such connectivity was not anticipated, but it’s not like we haven’t had time to adjust, and it’s not like SCADA customers haven’t been gradually asking for such capability for the TWO DECADES that the internet has been widely accessible to the public? (gee, could we get our data from all our remote sites into a process historian server at head office, so we can make jazzy reports’n'stuff for the guv’mint and our shareholders?).  Why did software developers so cavalierly approach these requirements for networking and distributed systems and such, especially in the conservative culture of the industrial automation business?

    And forget about whether the SCADA system was stand-alone or not.  Remember viruses pre-date widespread networking by quite a while.  This one and most others still have an old-school portable-media attack vector.  Someone, perhaps on the advice of Siemens themselves to install updates, used a USB drive on one of the SCADA computers, where it could’ve spread to other computers on the stand-alone system, until it got onto a workstation where reports are produced and distributed via email or even USB drive again.

    I know it has been years in the making already but this incident demonstrated the need to further establish software engineering as a true and proper engineering discipline.  When software is involved in industrial control, automotive systems, financial data processing, electoral systems and so on it cannot be developed and deployed under the same standards as the latest video game for your XBox.  Testing has to be thorough, regulations and standards established and followed and every implementation beeds to be reviewed for suitability (and I mean to the level at which disclosure of source code to the implementors and end users is mandatory).

Comments are closed.