Siemens PLC vulnerabilities: it just gets worse

My optimism regarding Siemens and its approach to SCADA/ICS security has just taken another big hit. There are major security problems at Siemens and they are not close to fixing them.

I am embarrassed I gave them such high marks in my previous blogs.

Beresford Reveals Serious S7-300 Vulnerabilities

On 3 August, Dillon Beresford presented his much anticipated demonstration of eight S7-300 vulnerabilities at Black Hat 2011. The fact he was going to do this presentation was well known, as Dillon had provided the details to both Siemens and ICS-CERT over a month ago.

Unfortunately, the vulnerabilities were far worse than I ever imagined. They also apply to a significant portion of the Siemens installed base of S7-300 controllers – not just a few “older versions” of the product as many have implied (to see if your product is affected go to the Siemens support site).

To me the most serious and inexcusable security hole is a hardcoded username (Basisk) and password (Basisk) that Siemens engineers had left in many versions of firmware on the S7-300 PLC. The credentials allow login to a telnet and http server that were unnecessarily left on the PLC.

According to Dillon:

“I was able to log in via telnet and http, which allowed me to dump memory, delete files and execute commands.”

Letting unnecessary services run on a PLC and the use of hardcoded passwords are both basic security errors. This should have never been allowed through the Siemens development and Quality Assurance process.

Dillon outlined other serious vulnerabilities as well, most of which is well documented in Beresford @ Black Hat, Part I: Details.

Siemens’ Commitment to their Customers’ Security is Abominable

What is really sad is that Siemens clearly knew of the hard coded password vulnerability at least a year ago. Yet they did nothing to address it.

They did not create a patch for their users. They did not advise their customers in any way. They did not modify the architecture in their Security Concept guidance document to even make it feasible for users to block http and telnet commands from getting to the vulnerable PLC.

Even knowing that the bad news was going to come out, they have done little. Their current advisory provides no useful guidance.

There are simple mitigations such as placing a firewall (even their firewall) in front of the PLCs to block the http and telnet. Setting up a basic IDS to check for the string “Basisk” would also be a simple solution. None are proposed by Siemens.

Dale Peterson put it well: "My view is Siemens has a complete lack of an SDL based on the other vulnerabilities Dillon and others have identified. Control of the engineers is not even close to the biggest problem."

In case you are not familiar with the term SDL, it stands for Security Development Lifecycle and is a process where companies design security into their products from the very start, not bolt it on when trouble strikes.

Siemens has not served its customers well. Hiding known vulnerabilities from your customers for a year and then not preparing even a basic patch or mitigation plan is inexcusable. I had hoped for better from them.

It’s Time for Customers to Demand Better Security

Now it is time for customers to demand better via purchasing specifications. Customers need to insist that companies have their development processes certified by ISASecure. They need to see clear evidence of an SDL process in place and they need to see in writing exactly what notification process vendors will provide when they discover a vulnerability.

As Dillon clearly showed this week, vendors doing nothing and then hoping no one will find their product issues is no longer an option. You can count on ICS and SCADA vulnerabilities being publicly exposed.

Both vendors and the end-users need to be prepared when it happens, but the vendor needs to lead the charge.

This commentary originally appeared at www.tofinosecurity.com