Archive for the 'ICS' Category
Monday, March 23rd, 2015
Last week, ICS-CERT released an advisory on a set of Johnson Control MetaSys vulnerabilities I reported. You can find the advisory here: https://ics-cert.us-cert.gov/advisories/ICSA-14-350-02
It’s interesting to note that my initial email describing the vulnerabilities was sent on November 22nd, 2013. So, 1 year, 3 months, and 23 days later… we finally get a public advisory. The vulnerabilities are extremely simple to exploit (as we’ll see in the post below), but they are also extremely easy to defend/detect. If you are a owner of one of these devices, the facility for which this device supports has been exposed for over a year. If you find these timelines unacceptable, you should call or email your Johnson Controls representative. Let them know that this is unacceptable and their security engineering practices need to be more agile. They obviously don’t care about security researchers, but maybe they’ll listen to their customers.
The Johnson Control NAE is a typical embedded device that you’ll find supporting Building Automation Systems. Here’s a picture of a NAE55.
The NAE55 runs Microsoft embedded standard on an Intel x86 Atom processor. Typically there is a flashdisk which can be accessed at /flashdisk. On the flashdisk, there is a large amount of web related code. Given that web interfaces are almost always remotely accessible, this is an excellent place to find impactful security issues. Some components created by Johnson Controls are written in .NET. While I didn’t find much raw source code, MetaSys makes use of precompiled binaries (dlls) on the NAE55. We can find these precompiled binaries on the flashdisk at: /flashdisk/Storage/Metasys/wwwroot/metasysIII/WS/bin
A quick note to device vendors, shipping .NET code, even in precompiled dlls, is the same as shipping raw source. But your code is tight… so you have nothing to worry about… right?.
There are a large number of binaries here, so where should we start? We’ll break out .NET reflector and we’ll look into a DLL named, “WebServices.Common.dll”. A screenshot of the WebService.Common.dll metadata is shown below.
WebServices.common refers to a number of interesting namespaces. The screenshot below shows the various namespaces.
“Security” is always interesting, so looking at the JohnsonControls.MetasysIII.Security namespace, we see the following:
“AdministationService” exposes several methods including a public method called, “getUserProperty()” getUserProperty accepts an INT value representing the userID and returns a XmlNode.
The implementation of “getUserProperty” is located in the Subsystems.Common assembly:
The Subsystems.Common code can be found in the “Subsystems.Common.dll”. Inside Subsystems.Common is a variety of namespaces including another namespace reference of “JohnsonControls.MetasysIII.Security”
Inside the “JohnsonControls.MetasysIII.Security” namespace is a class named “PrincipalStore”. A screenshot for “PrincipalStore” is shown below:
Inside the “PrincipalStore” class is the actual code for “getUserProperty()”
As you can see, the “getUserProperty()” method exposes user passwords (password hashes). If we can call this method remotely, we should be able to retrieve the password hash for any user on the device (along with a bunch of other user data).
It turns out, we can call this method as an unauthenticated user by making the following web service request (in the example below, we retrieve the details for the all powerful METASYSAGENT account, which is always userID = 1):
POST /MetasysIII/WS/Security/AdminService.asmx HTTP/1.1
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
This POST request should return something like this:
HTTP/1.1 200 OK
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><GetUserPropertyResponse xmlns="http://johnsoncontrols.com/MetasysIII/WebServices/Security/"><GetUserPropertyResult><Stuff><MetasysUser id="1"><userName>MetasysSysAgent</userName><password>MD5-PASSWORDHASH</password><fullName>Metasys System Agent</fullName><emailAddress /><description>Metasys System Administrator</description><singleAccessUser>false</singleAccessUser><temporaryUser>false</temporaryUser><userExpiresDate>2099-02-01</userExpiresDate><passwordExpiresDate>ExpirationDate</passwordExpiresDate><mustChangePassword>false</mustChangePassword><cannotChangePassword>false</cannotChangePassword><accountDisabled>false</accountDisabled><accountLockedOut>false</accountLockedOut><modifyOwnProfile>true</modifyOwnProfile><canViewNavTree>true</canViewNavTree><userDefined>false</userDefined><Roles><Role id="4" /><Role id="1" /></Roles></MetasysUser></Stuff></GetUserPropertyResult></GetUserPropertyResponse></soap:Body></soap:Envelope>
We can increment the “userID” value and retrieve the password hashes for all users on the device. It’s a good thing that integrators always use really strong passwords, otherwise these would be easily cracked
Here is an interesting exercise… if you have MetaSys in your facilities, ask your integrator if you have any devices that are affected by this bug. If you do have vulnerable devices, ask your integrator to install the latest patches. I would also suggest reviewing your web logs to see if anyone suspicious has called the “AdminService.asmx” web service. Given that this bug allows someone to capture password hashes, it’s a good idea to ask your integrator to reset all the user passwords on the device after you’ve installed the security patches… unless of course changing one of the device passwords breaks inter-operability your integrator setup with other devices, in which case your integrator will be stuck with a pretty major project on their hands… but that would never happen
Probably more relevant for the next post, but for those trying to do last mile supply chain verification or forensics on the NAE, I’ve uploaded my MetaSys bins to WhiteScope.
Monday, November 26th, 2012
In July of this year, I wrote about some of the frustrations I encountered when working with Tridium and trying to get them to fix various issues with their Niagara framework. The Niagara framework is the most prevalent Industrial Control System (ICS) in the world; it links together various ICS technologies and protocols. Looking at Eireann Leverett’s research on Internet accessible ICS, we see that Tridium Niagara is the prevalent ICS system available from the Internet. I didn’t talk much about the details of the issues I reported to DHS, but considering the patch has been out for nearly six months, I figure now is a good time.
The initial issue I reported to Tridum was a directory traversal issue that allowed remote, authenticated users to access files outside of the webroot. “Authenticated” includes demo and low privileged accounts. The directory traversal is very simple. Most web application security specialists know the classic “../../” style directory traversal, however Tridium was a bit different. Tridium makes use of “ordinals” to enable various functionalities within Niagara. For example, here is a URL for a Niagara deployment that uses the “station” ordinal:
The Niagara framework supports a large number of ordinals. One of these ordinals is the “file” ordinal, which is used to retrieve files from the Niagara framework server. The “file” ordinal followed by the path and filename to some file located within the webroot of the Niagara framework server. The Tridium Niagara framework isn’t susceptible to “../../” style traversal attacks, instead the Niagara framework uses the “^” character to traverse directories. Knowing this, we can specify a “^” character immediately following the file ordinal to traverse outside of the webroot. There are several files just outside of the webroot, however there is one file that is particularly interesting, a file named “config.bog”. The config.bog file is the configuration file for the entire Tridium Niagara deployment. The config.bog file contains all the configuration settings including username and encrapted (yes, I said encrapted… not encrypted) passwords for all accounts enabled on the system. Knowing this, we have a simple, reliable form of privilege escalation for any Tridium Niagara device. The exploit is very simple:
When you make the request above, you’ll download a compressed file. Unzip the compressed file and you’ll find the clear text config.bog for the Niagara server. Inside the config.bog, you’ll see the entire, detailed configuration for the Tridium device along with the username and passwords (protected with encraption). That’s it, it’s that simple. When I reported this issue to Tridium, I sent them a copy of their config.bog file for their marketing demo deployment.
Let’s ignore the fact that demo, default, and guest accounts are fairly common on these devices. In addition to the directory traversal, I also reported a weak session issue and insecure storage of user credentials issue. The Tridium Niagara framework generates sessionids that have about 9 bits of strength. This makes brute force attacks completely feasible and allows a remote attacker to quickly gain access to an authenticated state. Once authenticated, they are free to utilize the directory traversal to escalate privilege to Administrator. If that weren’t enough, the Tridium Niagara framework also stores a copy of the current username and password (base64’d) in the cookie giving any XSS bug the potential to divulge the clear text username and password.
There is a shining light to this story. When I first reported this issue to Tridium, the initial response was horrid. 6 months after the initial report, Tridium’s leadership attempted to pass these vulnerabilities off as “by-design”. Eventually, the folks at Honeywell (Tridium’s parent company) found about these issues and took over the response process. Three weeks later, they had a patch ready to go. Honeywell made the patch available to me a few days in advance of the release so I could take a look and verify the issues were fixed. They even gave me credentials to the new demo site so I could see the new features and security changes. It was welcoming to see an ICS vendor take such a stance towards security researchers, I hope other ICS vendors take note and follow suit. I’d like to personally thank Kevin Staggs for driving the renewed focus on security for Tridium Niagara, if you’re a Tridum customer, you should thank Kevin too. If you are a Tridium customer, you can learn more about the patch here:
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