Siemens Faces Music at Black Hat

Friday, August 5, 2011 @ 03:08 PM gHale

Editor’s Note: This story is an excerpt from Eric Byres blog.
By Eric Byres
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 he provided the details to Siemens and ICS-CERT over a month ago.

Unfortunately, the vulnerabilities were far worse than 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. Click on the Siemens support site for more information on your product.

Stuxnet Effect: Iran Still Reeling
Feds Fear New Stuxnet Threats
Stuxnet Threat Lingers; Industry Slow to React
Summit: Analyzing Stuxnet with Siemens

One of the most serious security holes is a hardcoded username (Basisk) and password (Basisk) that Siemens engineers 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.
“I was able to log in via telnet and http, which allowed me to dump memory, delete files and execute commands,” Beresford said.

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.

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

Siemens 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. Siemens proposes none.

“My view is Siemens has a complete lack of an SDL based on the other vulnerabilities Dillon and others have identified,” said Dale Peterson of Digital Bond. “Control of the engineers is not even close to the biggest problem.” SDL 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.

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.
Eric Byres is chief technology officer at Byres Security. This was an excerpt from his blog. For the entire version, click here.

Leave a Reply

You must be logged in to post a comment.