About a week ago I asked my co-worker if she’d be prepared to use a Personal Health Record for her data.  Surprisingly, she said no.  Her answer was that she didn’t trust the security of the company handling the data and applications.

A week passed and I thought about a topic for this week’s blog. For some reason I couldn’t quite get the prior conversation out of my head.  I use the Caresync PHR and I trust its security because I took a very close look at their controls before I was prepared to sign up.

Trust is the issue.  We are used to pulling an app from the App Store and just installing it. If it turns out to be boring, we uninstall and our data just goes away, right?

Ah no.  The data you are putting in these apps may well be being stored for much longer than you think, and we probably shouldn’t treat it like we’re playing Clash of Clans.

There are at least twenty PHRs on the app store as well as twenty more that are very closely related to a health record. Many have decent reviews and look legitimate, but when you dig in and take a closer look some are decidedly dubious on the security front.

Disclaimer:  Before we continue, the names of the guilty and innocent are nowhere to be found in this article, and I’ve gone out of my way to stress the journalistic intent of this endeavor.  I am not endorsing your attempting to hack medical data, nor do I think that’s ethical.  No actual PHI was accessed, nor was an attempt made to access other people’s PHI.

It was Saturday morning so I decided to try an experiment.  I picked one well rated PHR app and did a quick security review to see how well it protects information.

The app in question is designed to hold your whole chart.  It stores personal health data in the cloud and displays it on your phone.  Apparently nothing is stored on the device, though I haven’t had time to do the forensics yet to prove that.

The feature set of the app is pretty tidy.  It contains;

  • A nice little health summary
  • Access to records pulled in by fax and Blue Button
  • Messaging
  • Med refills
  • Telehealth
  • Education
  • Urgent Care Locator
  • the ability to give your physician access via a code.

Ah ha.  The last item caught my eye.  I’ve seen this tried before and it’s usually not done well at all.  Let’s take a closer look.

The idea is simple.  Give your physician a URL and a eight letter code and they can access your entire chart.  It’s simple for the doc, easy for you, and not at all secure.

So, let’s see how we might hack such a system.

If we consider the information space of the passcode we’re attacking it’s not that large. My code was NGNY-4LKR so I’m going to assume they are probably using no passcode complexity rules and simple uppercase alphabetic characters with 27 possibilities.

That means we have around 27^8 possible passcodes.  While this might seem like a large number, it’s not so big when you consider that there would, ideally, be a couple of million customers with individual chart access codes.

Worse still the algorithm for generating codes might not be all that random.  There are countless examples of code generation schemes in cryptography that have proved to be embarrassingly easy to attack and were much more complex in nature.

Let’s put these points aside for a period and take a more pedestrian approach.

If we did tried one attack per second it would take 9000 years to generate all valid codes; assuming the app has no mechanism for slowing down attacks.  That’s a big assumption though, and it’s surprising how often programmers forget this obvious feature.

Sure enough, twenty attempts later I had confirmed that the web site has no problems with me sending more than one request per second, and from multiple destinations to boot.  So, the odds are now in my favor, because all I need is a decent size botnet and I can crack this thing like a walnut.

But wait .. they have captcha.

Except they don’t. It’s not a real captcha, but an addition problem that is rendered in text on the web page.

Seriously?

All I needed to do was scrape the numbers out of the web page, add ’em up and submit them with the request.  Here’s the offending HTML I used to do my “captcha” calculation.
Screen Shot 2016-02-27 at 1.36.58 PM.png

Oh good lord.  Why bother?

Having collected these two weaknesses I carried out a little experiment to see if I could write a decent script to brute force this captcha and the access code.  It turned out to be amazingly easy.

The page structure itself was just an HTML form with txtCode1 .. txtCode8 as the fields to enter the “secure” access code into, and then our hideous captcha attempt stuck in a paragraph element.

In about sixty minutes I used python and mechanize to build the script and tested it with my access code.  Sure enough, it worked.

I discontinued my account ten minutes later. On Monday I’ll be apologizing to my co-worker.

One thought

  1. Scary read, but so true. Also disturbing, many of these apps run on public clouds that teams blindly trust to be secure. So many times, “secure cloud” only refers to the baseline infrastructure and cloud customers incorrectly assume data is safe further up the stack. Doing a study on this now… let me know if you’re interested in the results.

    FYI, ran across your blog on CDW’s top 50 health IT blogs – congrats!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s