September 22, 2016 | 7 min read
30 Breaches in One
A company known as EMR4All is responsible for placing these files in an open Amazon S3 repository (known as a bucket). This bucket was located at http://emr57.s3.amazonaws.com as recently as two weeks ago. Tech-savvy readers will know that Amazon S3 buckets tend to include the “s3.amazonaws.com” part of that URL by default. That means, in order to find these files, all you had to do was guess the phrase “emr57”.
So, how did I find it? Well, after noticing a separate, properly-secured, company using the Electronic Medical Record acronym (EMR) in their S3 bucket title, I theorized that it might be worth checking to see if any unsecured emr-titled buckets existed.
Using a simple URL fuzzing program, I began looking for publicly exposed repositories beginning with “emr”. It took milliseconds to hit on the phrase “emr57”. Literally. Milliseconds.
In one of the images above this post, you’ll see a full listing of directories which were displayed to me without so much as a username or password being requested. You’ll also see an image containing a collage of medical practice logos found within the S3 bucket.
The folder that immediately grabbed my attention is the one titled EMR4allMaster. Past experience has shown that when you find a vast array of seemingly private data exposed, anything marked with the word “master” is worth investigating in order to identify the overall responsible party.
Googling the phrase “EMR4all” pointed me in the right direction, but unfortunately the company’s homepage did not have any readily identifiable contact information. It was just a login portal for their clients with no contact phone number or email address to be seen.
If there’s one piece of advice I could impart to all holders of healthcare data, it’s this: Make sure you prominently display some method of contact on your homepage. When someone notices you are leaking data, you want that person to be able to contact you directly. Things get exponentially more complicated with each additional person that has to be contacted before the breach is secured.
Fortunately for me, I have a good working relationship with the administrator of databreaches.net (she goes by the name Dissent). After I could not quickly contact someone at EMR4All, she became instrumental in getting the breach secured. Dissent has high-level insurance industry contacts. One of them was able to get Amazon’s attention, who, in turn, notified EMR4All of the security issue. You can read Dissent’s side of the story here: https://www.databreaches.net/dozens-of-clinics-thousands-of-patients-impacted-by-third-party-data-leak
You may now be wondering what EMR4All has to say about the whole situation. They were kind enough to contact me with the following statement:
EMR4all, a service provider of Rehab Billing Solutions, was notified by its vendor, Amazon Web Services, on Sunday, September 11th that its “S3” storage account containing practice information of the customers of our companies, including patient information, was vulnerable because it was accessible to persons outside of our organization. We were also informed that a data researcher discovered the vulnerability.
We took immediate steps to investigate and determine the source and extent of any access of practice information and the kind of information that might have been accessed. We can report that the vulnerability has been identified and closed, and updated access controls are now in place to secure the S3 account.
We have also notified all our customers and former customers of this unfortunate situation involving our Amazon Web Service S3 account and are working with them to provide information to their patients. Over the last few months, we have been in the process of moving our customers to new platforms as we were phasing out the company’s operations. We have always taken our customers’ information security very seriously, and we deeply regret any inconvenience this may have caused. We continue to monitor the situation closely, and work with our customers on transitioning practice data and following up with further notifications and appropriate steps. As required, we will inform proper authorities to ensure that this situation is resolved.
Follow-up questions from Dissent also revealed that, according to the company, no more than 30,000 total patients could have been affected by this breach (and it is likely a subset of that total). It’s difficult for me to verify this number due to the heterogeneous nature of the .txt and .edi transmittal files included in the data dump. I can’t even show you a screenshot of those files because they would have to be completely blacked out. They are simply massive chunks of private medical data strings. What a mess.
Ultimately I’m left with one overriding question here-- Why did nobody involved with EMR4All ask me if I downloaded the data? The answer is yes, as I nearly always do… (and it will soon be purged) But, seriously, why didn’t anyone bother to ask? That’s usually one of the first questions I get.
Attention - Portions of this article may be used for publication if properly referenced and credit is given to MacKeeper Security Researcher, Chris Vickery.
Stay tuned to the latest security news by visiting MacKeeper Security Watch blog with Chris Vickery.