A tale of three leaks, Wednesday edition

On December 6, DataBreaches.net was contacted by researchers who requested help notifying two entities that they were exposing health information due to misconfigured AWS S3 buckets.  They would turn out to be a delight to deal with, unlike a third entity that was also leaking information from a misconfigured S3 bucket. So let’s start with that one.

On December 1, this site had received an email from a researcher who had found a bucket leaking “Social Security Numbers, Date of Birth, and Drivers License Numbers.” The researcher asked DataBreaches.net if we could find and notify the bucket owner and let those affected know about the leak.

The database in question appeared to be an inactive database containing automobile loan financing applications completed in 2013. The files contained a wealth of personal information, including name, address, date of birth, Social Security number, employer and salary information, etc. The consumers all appeared to be dealing with a Texas dealership and firm, and the forms had “Rhodes Auto Sales (dba of H.G. Rhodes, Inc.)” at the top of the applications. A google search revealed that there was a Rhodes Auto Sales in Texas, and this site sent a message to them via their web site. Days later, having received no response, we sent another notification. And then when there was still no response, we called and left a voicemail. Still no response.

Eventually, I would reach someone by phone who acknowledged receiving the messages, but said that it wasn’t their company, but another company named Rhodes in Houston that I needed to call. When I asked why they weren’t polite enough to respond to the first message so that I wouldn’t waste more time and days, the owner’s answer was ….. less than helpful. Since it wasn’t his problem, it seems, he hadn’t responded to let us know that we were trying to reach the wrong party. If there’s any karma in this world, some day he will experience what a delay in notification can mean.

But because that Rhodes Auto Sales wasn’t the source of the leak, this site started researching again. Eventually, I reached a firm in Texas whose employee acknowledged that they were related to the Rhodes on the exposed applications. She transferred me to another extension. After quite a while on hold, I was disconnected.

I’d had quite enough.

And so I contacted the Texas Attorney General’s Office consumer protection division and eventually reached someone who understood what I was trying to accomplish. I received a call back from one of their attorneys and we discussed the leak. We agreed that his office would follow-up to try to get the leak secured, and if that didn’t work, they would get back to me so I could try contacting Amazon to ask them to secure the bucket or reach their customer.

A few days later, when I checked again, the leak was now secured.

Were those loan applicants notified of the breach? If not, will they ever be notified?

Did criminals ever access and download their information? This is likely one of those cases where I’ll never find out the follow-up.

Does the firm know I have files with their customers’ personal and financial information? Do they care? Certainly no one from Rhodes has contacted this site to inquire what data we might have acquired and whether we would destroy it.

Meanwhile, in the health care sector

Unlike Rhodes, EpiSource was easy to reach and immediately responsive to notification. Within minutes of getting my message, they secured their database and had someone call me. And when they learned that researchers had uncovered the problem, they asked me to put them in touch with the researchers so they could thank them and get more information.

Episource’s investigation confirmed that their database had been encrypted, but one bucket had been misconfigured, which enabled researchers to bypass the encryption. Files with protected health information on approximately 500 unique patients from various providers or payers were accessed and acquired by the researchers, who subsequently deleted all their files and gave Episource an attestation to that effect. DataBreaches.net is also deleting all files that were acquired in the process of verifying and reporting on the leak.

According to a spokesperson, their investigation revealed that the misconfiguration existed for a few weeks before researchers happened to discover it, and there was no evidence that anyone other than the researchers accessed it.

Although EpiSource did not indicate how many clients would need to be notified of the exposure, they did make all notifications within a matter of days. When asked whether they would be notifying HHS, they replied that the clients would be making that decision. Because each client likely had less than 500 patients or members affected, we probably will not see this incident on HHS’s public breach tool, although the covered entities may report it to HHS.

In a statement to DataBreaches.net, a spokesperson for Episource writes:

Robust security is vital to our operations. We appreciate the work of the white-hat security researchers who identified the vulnerability and notified us. Their information allowed us to address the issue within minutes of notification and bring this single bucket’s security in line to protect the privacy of records in our database and quickly notify affected clients.

How nice to see appreciation instead of shoot-the-messenger. From Day 1, EpiSource has been cordial, appreciative, and responsive. And it didn’t even cost them a dime or bug bounty — just the simple courtesy of promptly acknowledging a notification and treating the parties like whitehats instead of criminals.

A third firm that I notified that week, also a business associate under HIPAA, will be named in the near future. DataBreaches.net is just giving them a bit more time to complete their notifications to clients and to provide this site with a statement. Like EpiSource, this other firm also provides services to HIPAA-covered entities and was also immediately responsive to notification, securing their bucket promptly and calling this site back promptly to let us know what was going on.   This post will be updated when their statement is received or by December 31, whichever comes first, as the incident is part of our December reporting.

Update:  The third entity, ArroHealth (now acquired by Ciox Health) has now also provided this site with a statement. ArroHealth is an insurance risk adjuster:

Please be assured that ArroHealth is committed to safeguarding the privacy and security of its clients’ information. Upon being notified that the Amazon Web Services Simple Storage Service (“S3”) bucket used by a secondary fax vendor was improperly configured, we immediately took action to ensure the bucket was properly configured. We can confirm that the bucket, which was identified by security researchers using scanning software specifically designed to find misconfigured S3 buckets, was properly configured the same day. We have subsequently terminated use of the fax vendor.

We understand from the vendor that the bucket was used for more than one of the vendor’s clients, and we are investigating the number of documents in that bucket that were or may have been associated with our faxes. We are not aware of any actual or potential adverse impact on any individuals as a result of the misconfigured bucket. None of the documents known to be accessed contained highly sensitive information, social security numbers, financial account numbers or other financial information, or medical records.

So it sounds like ArroHealth is still investigating, and it is not clear whether we will see this one on HHS’s public breach tool.  The files that DataBreaches.net had seen included patients’ names, chart numbers, dates of birth, and providers’ names, but no diagnostic codes or any specific medical, insurance, or identity information.

As with EpiSource, DataBreaches.net will be providing ArroHealth with an attestation of data destruction.