Siemens PLC Security Vulnerabilities – It Just Gets Worse

Submitted by Eric Byres on Thu, 2011-08-04 15:07

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

Yesterday (August 3rd) 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 been publically exposed.

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

Related Links

Information about Developing Software that is Cyber Secure:

Other Practical SCADA Security Articles on Siemens Vulnerabilities:

Media Coverage of this Blog Article:

 

RSS Feed Subscribe to the "Practical SCADA Security" news feed

Comments

6
Submitted by Andy Robinson (not verified) on Fri, 2011-08-05 11:10

Obviously Siemens had a target placed squarely on it's back with the discovery of Stuxnet and subsequent spin control. Is it a little unfair that it seems everyone is piling on? Maybe.

My real question is are we going to be hearing something about the Modicon, Allen Bradley, or some of the other major platforms? We all know many of the A-B platforms have a built in HTTP server. Is the reason we haven't heard anything is not for lack of trying but maybe the A-B stuff is put together well enough that the hackers have had a really hard time getting super juicy stuff like Dillon is getting out of the S7-300's. As you've stated many times before the out of the box insecure nature of PLC's makes pretty much every one of them vulnerable but I'm just wondering when and if the flood gates are going to open for the next vendor like they have been for Siemens?

Submitted by Eric Byres on Fri, 2011-08-05 17:07

Excellent point - It is very likely that the other PLC, DCS and SCADA products are just as flawed. In fact, I know a number of vulnerabilities in other vendor products exactly like what you describe - the web server built into the PLC as a gaping security issue. And as for dumb back doors into PLCs and SIS, look no further than http://www.kb.cert.org/vuls/id/362332 . So the flood gates will open for the next vendor someday (I just hope they do a better job when faced with a vulnerability).

But the fact that Siemens product has vulnerabilities is not what upsets me. Every product has vulnerabilities, especially when security was never part of the design requirements.

What gets to me is the the fact that Siemens knew there was an issue last year and didn’t warn users. I can understand why they might not want to announce anything while they didn’t have a patch ready, but why weren’t they working on either a patch or even a mitigation report for their customers? And once they knew Dillon was going to release the information, why no patch or basic mitigations? I have spoken to Dillon and I think he would have held off if they had a patch in the works. So my guess is that they did not have anything planned to help their users. That is the sad part.

The end-users really need to step in and prevent this from happening again. And the best way is through the power of the RFP.

Submitted by Wynand Künkel (not verified) on Tue, 2012-01-03 22:44

Hi Eric,

I am one of the types that made the move from IT to Automation (I am not yet sure if I regret it :-) ) and I have something to add on this issue. The reason that the "power of the RFP" is not used is because in most cases the RFP is written by someone who is only interested and involved in the functional operation of the system (as I call then the technical illiterates). There is in 99.999% of the cases that I have been involved no involvement from the security teams literally until two weeks before the system goes live (and trust me this is also endemic in the IT industry, even with all the guarantees by the services providers) I have been told in my face that security of the devices is of no concern to the operation and that the "network" has to take care of the security. The sad situation is that until something big and terrible happens, NOTHING will be done by the vendors since they are raking in the money and could give the proverbial continental whether the system is secure of not. All we security minded types can do is to literally make sure our behinds are covered with documentation because the technical illirerates will immediately try to pawn off the responsibility to take the spotlight off of them.

Submitted by Eric Byres on Fri, 2012-01-06 12:16

I absolutely agree - typically the RFP writer just focuses on the functional operation and forgets security. But it doesn't always have to be this way. For example, Shell, Dow and BP now have security requirements in their control system RFPs. Unfortunately I only see this in the oil/gas and chemical sectors and only by the majors. This needs to migrate into the other sectors, particularly by the major players in those sectors.

Submitted by Egon Zeird (not verified) on Mon, 2011-08-08 10:59

What happens now is the kind of turnpoint that occurs following the mutation of a society in whole, what some use to call the 'Googlisation of society'.
Now everything has to be connected to the Internet and networks are everywhere. Even on what used to be 'production islands', the fact that the majority of Plant Control systems, HVAC systems and even Anti-intrustion systems where isolated.
The IT sensitive folks amongts us know too well the danger of just putting a system on the Net, but in the Industry World this is rather new. In the IT world security is now the way of living (ok, there are exceptions, a lot of them in fact): patching, upgrading, checking, again and again.But even in this area, the birth of 'vulnerabilities disclosure was painfull, with some arguing that this is giving hackers the information and tools they need. So what would it be for a world that is conservative by nature, as in this world, the objective if the resilience of the processes. But thing are changing, you can't just expect it to happens overnight.Since Stuxnet, new reflexes are coming, you may say that it is too slow, but we don't talk here about the new 'fruit' phone, right?
Siemens is not Microsoft, and in the PLC world you will never have an autoupdate.
But if I remember, if you're in charge of a plant, it is your role, with a team of specialists, either in house or externals, to supervise the maintenance of it, and to operate the necessary upgrade during the shutdown periods.
And if you hook your plant to an network, it's you responsability to securise it,or to hire the right people to do it.Yes, indeed, Siemens has not sent a personnal note to every S7-400's customers, but in the business, it is assumed that you work with profesionnals, not with the flash artist that you found on Facebook as it is too often in the PC's world.
I will never allow the deployement of a firmware if I have not receive the documentation in advance.

Again, what about the other companies, will you publish a comparative beetwen GE, Siemens, Schneider and the others? Will you really compare the numbers of updates, the speed of reaction of the companies? I think it would make a great article and this is the right place to do it, and the right time.

Understand me, we are talking of a 180° degrees shift in the ways of doing things wich will require a lot of us to rethink our work and our lives as Automation Engineers.

And security experts will have more work than ever dreamed about :)

Submitted by Anonymous (not verified) on Mon, 2011-11-21 14:49

Just think of the money we could save if we just completely isolated the controls systems from the business systems. There is no need for control systems data to be floating outside a secure network in the plant , pr for that matter to have access points on the netwrk that are accessable in the business. If there is a need for "close to real time data" at the business level, then only a oneway data flow from the control system to a DMZ should be permitted.

Add new comment