nGenuity Information Services – Security Advisory

 Application: Encompass Web PACS
      Vendor: AGFA Heartlab
      Author: Adam Baldwin (adam_baldwin@ngenuity-is.com)
      CVE-ID: (PENDING CERT NOTIFIED)

  I. BACKGROUND
     Heartlab Encompass Web PACS is a web application used to remotely access
     and manage echocardiogram patient data. To conform with HIPAA regulations
     access to this data should be password protected.

 II. DESCRIPTION
     Authentication to PACS patient information can be bypassed by navigating
     to the SessionStart.asp page. This page sets up an anonymous user session
     and gives access to all patient records. 

III. DETAILS
     Patient data and records are available by navigating to URL similar to

https://pacs.example.com/thinclient/SessionStart.asp

     no authentication is required.

 IV. VENDOR
     The vendor has been notified and there is a patch available to address this vulnerability.

Copyright (c) 2008 nGenuity Information Services, LLC

This is continuation of Part 1: Cross-Road With Responsible Disclosure.

Out of the 5 institutions I located running the medical software publicly online, only two of them contacted me back for more information. As an aside I discovered that most organizations do not have an easy way for outsiders to contact them regarding issues such as this. Every company / site should have a privacy policy detailing how it details with information handling. Your privacy policy is a great place to put in this process and contact information. A security@example.com would also be a big help for us researchers.

One of the institutions was kind (and responsible) enough to contact me back and let me know that the vendor (after 6 months) had finally released a patch for this vulnerability.

Here are some lessons learned from the process.

The Vendor: If you are a vendor or service provider of software products and services take note. You need to be proactive and take security seriously. You should have a documented public process that researchers and your customers can follow to notify you and get notified about security updates in your product. Companies are feeling the pressures of regulatory compliance and the need for stability and security and will start to demand this. Start now before you fall behind to a wiser competitor.

The Customer: Pressure your vendors into providing quantifiable proof that they have put significant effort into securing the products you purchase from them. For missions critical software ask if they have had a third party security audit. Ask to find out if they keep track of metrics such as; how long does it take to fix a security issue from first report to customer notification. If they keep those metrics, as for them. Find out what they are doing to lower that number. Ask them if they provide proactive notification to their customers on security issues (or if you have to hunt for the info in the sparse content they call the README).

The final post on this series will be the advisory so you can see just how silly, but dangerous this vulnerability was.

This is the first in a three part series on responsible disclosure, taking over where the vendor leaves off and the release of the advisory.

I subscribe to the school of thought that responsible disclosure is the way to handle critical vulnerabilities. The kind of issues that place the privacy, welfare or money of people or businesses at risk need to be handled in such a way that it reduces the risk of all parties involved and everyone wins (before somebody gets owned).

Months back nGenuity found that commercial and really expensive healthcare application exposed patient information through a forced browsing vulnerability. (there will be a follow-up on this soon about how I found this vuln) This web application’s purpose and design is to provide doctors access to these records over the web in a secure fashion. We proceeded to write up the vulnerability details and provided them to the vendor, trying to be as responsible as we could. We notified our client, which immediately blocked application access from the Internet. The only one left to play nice was the vendor, but the vendor response was less than adequate.

Now I’m at a cross-road with responsible disclosure. If the vendor does not play ball, fix the vulnerability and notify their customer deployments then I am left with the burden of contacting those other deployments. Should this really fall on me? Yes if I’m going to follow through with my pact with responsible disclosure. I don’t have any other option if I want any of my clients to trust that I would do right by them with their confidential information. I’m also sure that somewhere in the fine print of my ISC2 and Certified Ethical Hacker ethics agreements it says I shouldn’t do that.

If you are an organization that makes software (yes this includes all you web developers), please make sure you make it easy for researchers to contact you about security issues in your products. When (not if) an issue is found in your software, coordinate with the finder and address the issue as quickly as possible. I have a rule about developers.

Stay tuned in to find out what our experience is notifying all of the medical organizations out there on the Internet running this application.