Hospital Sends Legal Threats To Researcher, Then Asks For Her Help Identifying Breach Victims

from the sooooo-sorry-about-the-bullets... dept

Shooting the messenger is the most popular response to reported data breach, making the job of security researcher far more dangerous than it should ever be. The twist in the latest "shoot the messenger" story is the shooter coming back around to ask the shooting victim for help. Bad idea. Even if the body is still warm and breathing, it's probably not in the best of moods.

Dissent Doe runs databreaches.net, a site that covers all sorts of exposed data stories. Sometimes, Doe is asked by those discovering security holes to disclose the information to the affected parties. (See above paragraph for why.) In early May, Doe tried to alert the Bronx-Lebanon Hospital Center about confidential patient records left exposed by a contractor. The stuff exposed was deeply personal, containing write-ups of patients' substance abuse problems or mental illnesses.

This didn't go well. The hospital didn't want to talk about it or explain why a third-party had so much access to confidential health records, much less why it hadn't bothered to properly secure the hospital's database. One day after these mostly futile phone calls, someone (not specified in the post) contacted Dissent Doe to let her know the databases had been secured and thanking her for notifying them.

That should have been the end of the story. But it wasn't.

It was a brief honeymoon. On May 9, Kromtech published their report and I published my first report on the incident without any statement from the hospital or vendor, neither of whom had provided a promised statement.

Then on May 12, coordinated threat letters arrived via email from external counsel for both iHealth and Bronx-Lebanon Hospital. DataBreaches.net understands that Kromtech Security also received similar letters.

I’ll let that sink in for a minute: they threatened a person who went out of her way to alert them they were leaking protected health information. Instead of saying, “Thank you so much, and can we also ask you to please securely destroy any data you might have in your possession?” they sent me threat letters.

The stupid, angry letters contained stupid, angry threats. First, the letters accused Doe of improper access. Then they went on to demand she and everyone else in possession of this data delete it and send a certified letter (or something) back to the hospital and vendor confirming the destruction of the data. They also demanded she reveal her sources and not post anything further about the breach.

Doe didn't think much of the demands, but she did retain counsel just in case. An angry, non-stupid response letter from her legal rep changed the tone of the demands into more polite requests. Not that the change in tone won Doe over. A bridge only needs to be burnt once to render it useless. And, in one sense, the angry, stupid threat letter did work: while Doe didn't cave, it appeared that Kromtech did delete the data it had discovered. That resulted in a problem.

Apparently, the hospital and vendor forgot about their earlier bridge-torching efforts. They approached Doe again, this time asking for help identifying which patients had had their personal info exposed in order to notify them.

Now the entities could just notify everyone who had PHI/PII on the server, of course, but it seemed like they were trying to narrow the universe to only those whose data wound up in Kromtech’s hands – or this site’s – or NBC News’ hands. And now Kromtech could not tell them which patients had data in the 500 mb of data they had downloaded and then destroyed.

But Kromtech had sent a subset of that data to DataBreaches.net, who had not destroyed the data it possessed. If DataBreaches.net wanted to be helpful, it could go through all the data and let the entities know which patients had data in there, right?

But why should Doe do this? The two affected entities had already expressed their gratitude using legal threats, not exactly the best foundation for future collaborative efforts.

I might have been able to spare the vendor and hospital some notifications if I was willing to donate my time to going through files to compile information for them, but I’m not willing.

I’m not willing, in part, because I do not want to be going through PHI if it’s not for my reporting purposes. And I’m not willing because why should I have to spend my valuable time compiling information for entities that tried to bully me and who now need my help to help them clean up their mess??

Shooting the messenger kills potential allies. But far too many entities think it's better to shoot first and live with their regrets later. Security researchers aren't the enemy of privacy, but they're often treated as criminals and malcontents by entities who have screwed up their own security efforts.

Filed Under: dissent doe, leaks, reporting, security, shoot the messenger, threats
Companies: bronx-lebanon hospital center, kromtech

Child-Monitoring Company Responds To Notification Of Security Breach By Publicly Disparaging Researcher Who Reported It

from the got-a-full-clip-of-'thank-yous'-with-your-name-on-it dept

"Thanks for letting us know about this! We'll get it fixed immediately!" said almost no company ever.

There's a long, but definitely not proud, tradition of companies shooting the messenger when informed of security flaws or possible breaches. The tradition continues.

uKnowKids is monitoring software parents can install on their children's cell phones that allows them to track their child's location, as well as social media activity, text messages and created media. As such, it collects quite a bit of info.

The information on your child collected includes:

• the online profile/screen names, mobile telephone numbers and email addresses associated with the Linked Accounts and the people communicating with the Linked Accounts and devices and in certain situations, the text of the online or mobile phone SMS or MMS conversations themselves;
• the geographic location and time and date associated with a specific geographic location of your Linked Account mobile device;
• your Linked Accounts’ social networking activity and contacts;
• photographs sent, received or uploaded by your Linked Account;
• the websites visited from your Linked Account mobile device; and
• the applications installed on your Linked Account mobile device.

That's a lot of data, all related to children. This should be kept locked up tight. Unfortunately, it wasn't.

Chris Vickery, who now blogs about security over on MacKeeper, alerted this site that a misconfigured MongoDB installation exposed over 6.8 million private child text messages, 1.8 million images (many depicting children, according to Chris), and over 1700 in-depth child profiles.

The data reportedly included full names, email addresses, GPS coordinates, dates of birth, and much more, although Chris tells DataBreaches.net that he did not see payment info or parent details exposed.

Vickery did the right thing and notified uKnowKids. The security hole was closed. But the company wasn't interested in thanking Vickery for his efforts. Instead, as the Office of Inadequate Security notes, the company decided to notify its customers in a rather unusual fashion. A post at the company's site completely misconstrues the chain of events.

Here's the BS headline.


And here's the BS text:

It is with significant personal regret that I share with you the news that uKnow had a private database repeatedly breached by a hacker using two different IP addresses on February 16, 2016 and February 17, 2016.

The hacker claims to be a "white-hat" hacker a "security researcher" or "white hat hacker" or "ethical hacker" which means he tries to obtain unauthorized access into private systems for the benefit of the "public good". Although we do not approve of his methods because it unnecessarily puts customer data and intellectual property at risk, we appreciate his proactive, quick notification as it was helpful to our team.

The passive aggression continues later in the post.

The first IP address that obtained unauthorized access to uKnow's private database was 65.36.124.81. We believe this IP address is associated with Mr. Christopher Vickery in Austin, Texas, but we don't have confirmation of that fact yet.

Mr. Vickery claims to work at a prominent law firm by day and exploit vulnerable technology systems at night. We do not have any additional background information on Mr. Vickery, but we are doing our best to fully identify Mr. Vickery in order to validate his stated "benign" intentions.

The second IP address (209.144.254.123) that accesed uKnow's private database in an unauthorized manner is reportedly associated with Mr. Vickery's full-time employer in Austin, Texas. Again, we don't yet have confirmation on who owns this IP address or the IP address owner's official connection with Mr. Vickery, but this is the early information we have been able to determine so far.

The post goes on to insinuate that Vickery has some sort of malignant interest in holding onto uKnow's code.

The database also included uKnow's proprietary natural language processing engine technology and data including our proprietary algorithms that power uKnow's technology.

We have repeatedly requested that Mr. Vickery permanently delete any and all copies of uKnow's intellectual property including iits proprietary customer data, business data, database schemas and field names, trade secrets, curated data dictionaries and algorithms.

After initial resistance, Mr. Vickery claims to have deleted the downloaded database in its entirety. However, he has reportedly retained an uknown number of screenshot copies of uKnow's intellectual property, and is so far unwilling to permanently delete this information. In an effort to protect our customers and stakeholders, we contine to request the destruction of any and all copies of uKnow's database including screenshots which are, in fact, copies of uKnow's database.

It also suggests Vickery's possession of screenshots might somehow violate COPPA (a law ensuring the privacy of data generated by children) and has apparently reported him to the FTC.

We have contacted the Federal Trade Commission for guidance and to report the breach. uKnow goes to great effort and expense to fully comply with the FTC's COPPA regulations, and we beleive we are in full compliance at this time.

uKnow's demand for Mr. Vickery to delete ALL copies of uKnow's database was obviously driven by our desire to protect our uKnowKids customers, but also to fully comply with COPPA requirements that we do not knowingly allow any third parties access to child data without first having affirmative, verifiable permission from parents. Mr. Vickery obviously did not and does not have authorization to explore, copy, or control this private child data (or uKnow's intellectual property), and we expect him to comply with our requests immediately.

Nowhere in this long statement questioning Vickery's intent is there an apology for the breach. There are no unqualified statements of gratitude. Vickery's history of finding misconfigured databases is well-documented, as is his standard operating procedure of notifying affected companies immediately and destroying any data he obtained while investigating these leaky databases.

Instead of simply fixing the hole and informing affected customers, uKnow decided to publicly disparage the person who alerted it of the issue. It's responses like these -- along with continual abuse of computer security laws -- that make security researchers leery of informing affected parties. Informing someone of a security hole shouldn't be greeted with antagonism and legal threats. But that's the default operating mode, one that only ensures security holes discovered in the future are less likely to be reported.

Filed Under: chris vickery, disclosure, ethical hacking, security research, shoot the messenger, vulnerability, white hat hacking
Companies: uknowkids