My point: we have multiple Siemens vulnerabilities affecting multiple Siemens products and little clarity from ICS-CERT or Siemens on the totality of the vulns, the impact or the affected products — or what is queued up and ready to come next as soon as Wednesday!
Dillon Beresford has identified and partially disclosing a number of different Siemens vulnerabilities over the past three months. We hope that the Black Hat presentation this week will bring clarity to how many vulnerabilities there are, what the detail and impact of each vuln is, and what products are affected by the vulnerability. As well as what automated attack tools he has developed and will release.
To date, Siemens and ICS-CERT have really added little clarity to the situation. Siemens is taking the approach of denying everything until it can no longer be denied, and then issuing bulletins that “Siemens identified” a security problem and letting the marketing machine take over with “proactive holistic” recommendations and the impression that the problems have been fixed.
Why ICS-CERT has not issued more timely and helpful bulletins is a mystery.
Let’s look at the two vulnerabilities that are being conflated and confused. Dillon discovered what orginally was being called a “replay vulnerability” related to a password that can be set for S7 functions communicating with the PLC. Even this feature has been a bit confusing.
- Not all functions use this feature. Importantly, write commands do not use this password feature. So an attacker with logical access doesn’t need the “replay vulnerability” to change the process.
- Very few owner/operators actually use this feature. Ralph Langner demonstrated at WeissCon 2009 his iOpener tool that manipulated all sorts of thing in S7 PLC’s – sometimes subltly by randomly changing least significant bits and sometimes causing a crude crash. For a non-directed attacker, a Metasploit automated iOpener tool would be devastating to most S7 systems it could gain logical access to.
- The password feature, when implemented, is used to protect changes to the ladder logic / process and some other nasty functions that could be misused by the attacker.
- The replay attack, I believe, captures the encrypted password, using Wireshark or similar, and uses the encrypted password to get through the security feature. It is not the exact message/request/command that has to be replayed. Any password protected command can be replayed. This is not news to Siemens; it has been known since 2008. Dillon may have found more here, and it will be interesting to see if/how he automated this attack.
- The password is small in size, and it is stored in the project file. If you have access to the project file, it is easy to exhaust the space and recover the password in minutes.
Dillon was right on in the May podcast that this security feature adds minimal security, is easily bypassed and could give the owner/operator a false sense of security. Where is this kind of information from Siemens or ICS-CERT so owner/operators can determine the impact.
Back to the politics, when this vulnerability came out, Siemens wrote in a carefully worded statement that some of Dillon’s findings did not affect the S7 300 and 400 models and that they were investigating others. It is a huge stretch of credibility that Siemens did not know immediately, and certainly weeks later, that this attack would be successful on other models.
Later Dillon got his hands on an S7 300, quickly verified this product was vulnerable, and tweeted the news. ICS-CERT put out a new bulletin and Siemens put out their Siemens identified statement. Embarrassingly for Siemens, Dillon got the S7 300 about the same time as the Siemens Automation Summit and put out his news the week after Siemens stated strongly their new security commitment and there were no known security issues in the 300 and 400 — and implying the Beresford vulns had all been addressed.
ICS-CERT is now calling the “replay vulnerability” a “password protection vulnerability”. The new Beresford identified vulnerability is called by ICS-CERT a “S7 300 Hard-coded Credentials” vulnerability. ICS-CERT, working with Siemens, quickly identified what products are affected and what are not. Most notably, the S7 400 PLC’s are not.
The danger is to the average engineer, non-ICS-security-obsessed type it might be very easy to get the message that the S7 400 are unaffected by the Beresford vulnerabilities. The two bulletins are separate security issues.
The bulletin and Siemens site says the hard coded passwords allow “an access method to internal diagnostic functions in the S7-300 PLCs”. I have a bit more information from Dillon, but it is his to disclose at Black Hat. But why do we have to wait until Black Hat to get this information that will help owner/operators determine what the risk is to their SCADA or DCS? That description could be innocuous information requiring an update at the next planned outage or something that puts the whole DCS at risk. Why does ICS-CERT and Siemens continue to wait for Dillon to put out his findings before they inform the owner/operators?
Conclusions
Customers expect to get clear, honest and helpful information from their vendor. To be kind, let me just say Siemens has chosen a different approach. In fact, the confusion is helping the marketing folks because they can put out very positive carefully worded statements.
ICS-CERT should be putting out better descriptions of the vulnerability and even more importantly the impact so owner/operators can make an informed risk decision.
ICS-CERT should be putting out summary documents when multiple vulnerabilities affect a single vendor. The accurate information will not be gathered by most in this space from multiple technical documents with overlapping language and product coverage.
Note: Patrick Coyle raises a good point in his blog that if Siemens fixed this problem in 2009, they must have known about the vulnerability and chose not to tell their customers. Siemens admits this, “as a result of the continuous test and improvement of S7 PLCs (including security related functions), Siemens had previously identified this method of access to the functions.” This is a prime example of the dangerous silent fix.
Up Next: Protocol Vulnerabilities vs. Vendor Implementation Vulnerabilities
Imageby Assembled Chemical Weapons Alternatives