Thursday, July 12th, 2012
We are happy to see Robert O’Harrrow is shining a light on the vulnerabilities associated with Industrial Control Systems (ICS). The ICS software community is light years behind modern software security. Sadly, we can honestly say that the security of iTunes is more robust than most ICS software. Terry and I plan on releasing some technical details about what we’ve found in the near future, but for now we wanted to talk about some of our experiences with this particular issue.
First, ICS-CERT has done a great job tracking this issue. It’s been months since we first reported the issue to ICS-CERT. Following up with an unresponsive vendor is extremely frustrating. It was apparent that ICS-CERT was making every effort to follow-up with Tridium and they kept us well informed throughout the entire process. We especially want to thank those ICS-CERT analysts who kept us apprised of developments despite the lack of response and unwillingness of Tridium to accept responsibility for the issue.
We are disappointed that it took so long for the public to become aware of this issue. According to the Washington Post article, Tridium became aware of this vulnerability “almost a year ago, when a Niagara customer that uses the software to manage Pentagon facilities turned up issues in an audit”. We are disappointed that even after discovering critical, remotely exploitable vulnerabilities in Tridium software… our government chose to purchase and implement the software anyway. We are disappointed that our tax payer money paid for the ignored security audit, paid for the acquisition, and paid for the implementation/deployment of known vulnerable software. We’d like to challenge our nation’s leadership to evaluate the failures in our current processes surrounding the acquisition of software that support Critical Infrastructure and Industrial Control Systems.
At times, we felt like ICS-CERT had their hands tied. We realize when you are working with vulnerabilities that could affect critical infrastructure, a delicate balance between disclosure and timely notification of affected organizations must be maintained. However, when a vendor is unresponsive or refuses to accept responsibility for an issue, ICS-CERT should have the authority to inform those customers who are vulnerable in a timely manner. DHS and ICS-CERT work for us, the American people… they do not work for the PR departments of ICS companies. ICS-CERT should be able to take the appropriate actions to ensure that we’re safe and to ensure ICS customers have the right information to mitigate and control risk. The PR damage done to any individual company should never be part of this equation. If a vendor is unresponsive or unwilling to accept responsibility for a security issue, ICS-CERT should have the option of disclosing issues (45) days after initial notification from external researchers (this is consistent with CERT/CC’s disclosure timelines). Of course, special circumstances require special handling, but we’re sure the folks at ICS-CERT can make those determinations when needed.
Probably the most disappointing part of the whole ordeal is Tridium’s eagerness to blame the customer. We’ve seen this from other ICS vendors as well. It should never be the customer’s responsibility to have to compensate for poor design. Many ICS vendors expect customers to ensure their product is implemented securely, yet provide zero (or extremely vague) guidance on how to do so. In many cases, secure deployment is simply impossible due to the extremely poor security design. Notification, automatic patching, and secure implementation guidelines in the ICS world are light years behind modern software. We don’t understand Tridium’s claims that, “The firm also is doing more to train customers about security” when the root cause of these issues is poor design and coding practices from Tridium itself. Maybe Tridium should invest in training their developers about security first…
If you would like to contact us about our experiences, please email us at: help – at – fixicssecurity.com
Billy Rios @xssniper and Terry McCorkle @0psys
Tuesday, December 20th, 2011
I have been working with ICS-CERT and various vendors over the last year, finding bugs and “responsibly” reporting nearly 1000 bugs… all for free and in my spare time. Overall, its been a great experience. Most of the vendors have been great to work with and ICS-CERT has done a great job managing all the bugs I’ve given them. In May of this year, I reported an authentication bypass for Siemens SIMATIC systems. These systems are used to manage Industrial Control Systems and Critical Infrastructure. I’ve been patiently waiting for a fix for the issue which affects pretty much every Siemens SIMATIC customer. Today, I was forwarded the following from Siemens PR (Alex Machowetz) via a Reuters reporter that made an inquiry about the bugs we reported:
“I contacted our IT Security experts today who know Billy Rios…. They told me that there are no open issues regarding authentication bypass bugs at Siemens.”
For all the other vendors out there, please use this as a lesson on how NOT to treat security researchers who have been freely providing you security advice and have been quietly sitting for half a year on remote authentication bypasses for your products.
Since Siemens has “no open issues regarding authentication bypass bugs”, I guess it’s OK to talk about the issues we reported in May. Either that or Siemens just blatantly lied to the press about the existence of security issues that could be used to damage critical infrastructure…. but Siemens wouldn’t lie… so I guess there is no authentication bypass.
These aren't the Auth Bypasses you're looking for
First, the default password for Siemens SIMATIC is “100”. There are three different services that are exposed when Siemens SIMATIC is installed; Web, VNC, and Telnet. The default creds for the Web interface is “Administrator:100”
and the VNC service only requires the user enter the password of “100”
(there is no user name). This is likely the vector pr0f used to gain access to South Houston
(but only he can say for sure). All the services maintain their credentials separately, so changing the default password for the web interface doesn’t change the VNC password (and vice versa). I’ve found MANY of these services listening on the Internet… in fact you can find a couple here: http://www.shodanhq.com/search?q=simatic+HMI
But WAIT, there's MORE!
But WAIT… there’s MORE! If a user changes their password to a new password that includes a special character, the password may automatically be reset to “100”. Yes, you read that correctly… if a user has any special characters in their password, it may be reset to “100”. You can read about these awesome design decisions (and many others) in the Siemens user manuals.
But WAIT… there’s MORE! So I took a look at what happens when an Administrator logs into the Web HMI. Upon a successful login, the web application returns a session cookie that looks something like this:
Looks pretty secure… right? Well, I harvested sessions from repeated, successful logins and this is what I saw:
Not so random huh…. If you decode these values, you’ll see something like this:
Totally predictable. For those non-techies reading this… what can someone do with this non-existent bug? They can use this to gain remote access to a SIMATIC HMI which runs various control systems and critical infrastructure around the world… aka they can take over a control system without knowing the username or password. No need to worry though, as there are “no open issues regarding authentication bypass bugs at Siemens.”
Next time, Siemens should think twice before lying to the press about security bugs that could affect the critical infrastructure….to everyone else, Merry Christmas
Friday, June 10th, 2011
I’m posting some of the research I’ve been working on over the last few months. I planned on submitting some of this research to the Blackhat/DEFCON CFP, but it looks like I’ll be tied up for most of the summer and I won’t be able to make it out to Vegas for BH or DEFCON this year (pour some out and “make it rain” for me). The gist of the research is this: I’ve collected of number of malware C&C software packages. I set up these C&Cs in a virtual network and audited the applications and source code (when available) for bugs. The results were surprising; most of the C&C software audited has pretty crappy security.
This week’s sample is an auth bypass and SQL injection on a BlackEnergy C&C page. The first of the samples can be found here: http://software-security.sans.org/blog/2011/06/10/spot-the-vuln-rabbit-authbypass-and-sqli
I’ll post more samples in the coming weeks.
Attacking malware C&C is an interesting proposition. Exploiting a single host can result in the transfer of hundreds or even thousands of hosts from one individual to another. I’m not the first to note that malware and C&C software is evolving. Gone are the days of simple IRC bots receiving clear text commands from an IRC server. Today’s C&C’s are full fledged, feature rich applications with much complexity. Complexity is the enemy of security, even malware authors cannot escape this. There is no magic bullet, even malware authors face the difficulties of writing secure code. This is especially so if their customers are paying money for C&C software and demand newer features and robust interfaces. Today’s malware landscape looks much like a typical software enterprise with paying customers, regularly scheduled feature updates, marketing, and a sprinkling of PR. Who knows, maybe in the near future these malware enterprises will have dedicated, on-call security engineering teams and a formal SDL process