It looks like Luigi Auriemma did only a quick check of SCADA systems before he came up with a giant list of flaws. He has decided to post his initial findings to Bugtraq:

The following are almost all the vulnerabilities I found for a quick experiment some months ago in certain well known server-side SCADA softwares still vulnerable in this moment.

He points out in his post that he did not know anything about SCADA systems before the tests. Obviously that did not stop him from quickly finding many weaknesses.

Full-disclosure advisories and proof-of-concepts:
Siemens Tecnomatix FactoryLink:
http://aluigi.org/adv/factorylink_1-adv.txt
http://aluigi.org/adv/factorylink_2-adv.txt
http://aluigi.org/adv/factorylink_3-adv.txt
http://aluigi.org/adv/factorylink_4-adv.txt
http://aluigi.org/adv/factorylink_5-adv.txt
[…]

Open up factorylink_2-adv.txt and you will see the vulnerability levels can be very high — remote exploit.

CSService is a Windows service listening on port 7580.

All the file operations used by the service (opcodes 6, 8 and 10) allow to specify arbitrary files and directories (absolute paths) and it’s possible for an attacker to download any remote file on the server. Obviously it’s possible also to specify directory traversal paths.

First, to be fair, SCADA systems are often intended to live in a different world than other systems — single-user, single-role, etc. There may be a defense-in-depth or compensating control design to be considered that encapsulates a SCADA system. Langner talks about this some in his interview on Stuxnet. An unprotected CSService thus may have been built that way by design, to do one thing and do it well.

Second, I have found that critical infrastructure management can be dominated by a culture of data analysis. Staff are often told to punch holes into closed systems and environments to mine details needed for calculations. It can feel more like a financial firm trying to make real-time investment decisions than an engineering operation. Closed environments are under pressure to be opened in order for spreadsheets to run.

Third, the financially-focused managers boast about their speculation and risk-management skills. Yet they seem to rely more on faith than data analysis when it comes to risk relative to security controls. They raise defense-in-depth as a theory sufficient on its own instead of as a measured and managed practice to deploy controls more thoroughly. That usually means when you find a vulnerability like factorylink_2-adv someone will always emphasize my first point above and say “I believe that’s handled elsewhere.”

Putting the three above points together, the worlds of IT and SCADA are not nearly as separate and distinct as many want to believe. They must be managed to reflect this convergence or there is a risk of leaving gaps for attackers to exploit. Even worse, the depth of defense can go unmeasured and leave basic systems unprotected in environments exposed to high-risk multi-user threats.

That’s why Auriemma’s list should be taken seriously. Vendors need to secure their products, or at the very least test them for hostile scenarios and provide security warnings/guidance. The demand, however, really has to come from SCADA application consumers. I suspect that these full-disclosure vulnerability announcements will help improve the industry’s risk calculations — prove the value of paying for better security from the SCADA vendors. On the other hand, if management still does not get it, then regulations will probably have to tighten.