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 passive aggression continues later in the post.
The hacker claims to be a"white-hat" hackera "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 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.The post goes on to insinuate that Vickery has some sort of malignant interest in holding onto uKnow's code.
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 database also included uKnow's proprietary natural language processing engine technology and data including our proprietary algorithms that power uKnow's technology.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 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.
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.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.
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.
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.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: chris vickery, disclosure, ethical hacking, security research, shoot the messenger, vulnerability, white hat hacking
Companies: uknowkids
Reader Comments
Subscribe: RSS
View by: Time | Thread
When will they learn...
Given reactions like this are not overly rare(though I must admit this company went above and beyond in shooting the messenger in the CYoA attempt), notifying a company of a security flaw is just asking for trouble. Make the flaw public, do so anonymously, and let the company deal with the fallout.
[ link to this | view in chronology ]
Re: When will they learn...
[ link to this | view in chronology ]
Re: Re: When will they learn...
Those damages would hit first those on the front line; researchers who find this stuff.
It used to be when you found a small child wiping its eyes calling for its mother, you'd take it under your wing and help it find her. This encourages you to run away instead, lest you be accused of molesting a child.
Stupid century.
[ link to this | view in chronology ]
Re: When will they learn...
[ link to this | view in chronology ]
Re: Re: When will they learn...
1. Ignore it. If the vulnerability is serious enough, and you use the service, distance yourself from it as quickly as possible.
2. Inform the company privately. While the 'polite' option, this also carries the chance that the company will react in a fashion similar to that displayed in this example, and prioritize shooting the messenger and CYoA over fixing the problem.
3. Inform the public anonymously. The safer option for the one disclosing the vulnerability, this however is much more painful to the company and it's customers, as they're finding out about the vulnerability at the same time as those who might take the opportunity to exploit it, which means they have to scramble like mad to find a fix.
If so many companies didn't have a penchant for shooting the messenger, then #2 would be the clear 'best' option for everyone involved, but as it stands #3 and #1 are much safer for those that stumble upon problems, with #3 being painful for the company in the short term, while #1 has the potential to be even worse long-term when the vulnerability is found by someone more interested in making use of it for their own gain.
While it's possible that someone that goes with #3 could still be found out the odds are drastically less than #2, and at least it ensures that something will be done with regards to the vulnerability.
[ link to this | view in chronology ]
#4 trade it to the hacker sites.
[ link to this | view in chronology ]
Re: #4 trade it to the hacker sites.
Let them be the intermediary between you and an the unknown vulnerable provider.
[ link to this | view in chronology ]
I'll take the same approach I do with his laptop: Set some ground rules about social media, check in on him every now and then, explain why those are the rules, and check in on what he's doing regularly.
It's amazing what some trust and communication can do. Of course, I'll readily say I'm very lucky he's pretty responsible.
[ link to this | view in chronology ]
Re:
That's how that sentence should have read... love it when I rethink a thought and fail to correct the whole sentence.
[ link to this | view in chronology ]
Re: Re:
Granted this wouldn't work well with a troubled kid, as I was particularly vanilla about my rebelliousness, but it does get the best of both worlds in my opinion.
[ link to this | view in chronology ]
Re: Re: Re:
I've only used it once or twice, just to keep them honest.
But they are good kids and I really haven't needed to spy on them.
[ link to this | view in chronology ]
Re:
That's preposterous- this is 2016! Everyone knows parenting should be outsourced to government agencies and private monitoring companies.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Well...
But I think the public deserved to know, because when someone pulled these guys pants down... we found children!
I think a "for the children" response should be warranted here and start pulling the pants down on several other organizations saying we keep shit secure!
[ link to this | view in chronology ]
Re: Well...
More like someone pointed out that the Kings clothes were illusionary, and they are too embarrassed to admit they were conned, and so claim the messenger stole them.
[ link to this | view in chronology ]
Re: Re: Well...
[ link to this | view in chronology ]
One oddity noticed
Red flag there.
[ link to this | view in chronology ]
Re: One oddity noticed
A lot of organizations pay good money to people able to misdirect anger so that the real dirt bags do not get the focus. This company is going to do its best to spin this like they are an honest company that did their best until some scumbag came along, broke in, and then stole shit like a common criminal. Please feel sorry for us and will will now expend effort in trying to keep these meanies away from your precious kids...
[ link to this | view in chronology ]
Re: Re: One oddity noticed
Just short of that, how about noticing that someone was playing in their playpen? It doesn't appear that they did notice, until told.
[ link to this | view in chronology ]
Or, in other words, we have made sure that IF the appropriate authorities finally pull the finger out of their ass and start investigating who else may have downloaded private data, they will find no evidence at all.
Obstruction of justice or compliance with COPPA?
[ link to this | view in chronology ]
i believe we have to hold our hands up, here in the USA, dont we? let's face it, it's on par with the attitude that no one should ever have the audacity to think there is anything wrong with anything in the USA and to actually prove it when there is, is committing the cardinal sin! the fact that those who are affected by the failing of something are supposed to say nothing and do nothing other than be proud that they were among those when as much as could be gleaned from the companies concerned, was gleaned! that doesn't normally affect anyone at the company because they manage to keep their information separate from customers, but when it becomes known that was something that could have been done to have prevented the problem, that's when the company starts throwing hand grenades at those who found the breakdown in the first place and told the company!!
[ link to this | view in chronology ]
Proposal, YWS
1. A person voluntarily gives information over which he has control to a corporation or government organization.
2. That information is not public, that is, he wouldn't publish it in a newspaper or on a blog.
3. That information is leaked, sold, or otherwise transferred.
4. The person who originally gave the information complains.
The proper and reasonable answer, after these twenty years of global network access, is simply YWS. Note that stupid, in this context, indicates both an intellectual and moral failing.
As for shooting the messenger, does anyone honestly expect anything else?
*Note that YWS applies also to other circumstances. One that hops to mind is purchasing DRM protected content which needs to be authorized over the network and then having either network access or the authorizer fail/refuse to authorize.
[ link to this | view in chronology ]
A different approach
[ link to this | view in chronology ]
Nice people
Classy company; I'd trust them. With nothing at all.
[ link to this | view in chronology ]
Re: Nice people
I thought you were just using British instead of English.
Head of law firm: "What do you do in your spare time?"
You: "I break into child monitoring software databases."
Aaron Swartz was only freeing scientific papers.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Moral Fortitutude
[ link to this | view in chronology ]
[ link to this | view in chronology ]
If these morons "white hat" security researchers were smart, they would just post the information online and let these companies run around like chickens with their heads cut off and play damage control.
If I discovered a security hole, I would never inform the company of it. I would post it online, everywhere I could, and sit back and watch the company fall over themselves with the reality that they couldn't blame me after I informed them of it.
How many times are these idiot security researchers going to learn that companies do not want you informing them of glitches in their software or their devices. They fix the holes and then blame you for "hacking" into their systems.
[ link to this | view in chronology ]
None of My kids will ever use their crap now
[ link to this | view in chronology ]
Trust?
[ link to this | view in chronology ]
Re: Trust?
[ link to this | view in chronology ]
This is why "responsible disclosure" is a fairy tale
Given this environment, the best course of action is to anonymously disclose security bug/breach information with no advance warning. That at least avoids (c), (e), (f), (g), and (h).
Oh, and avoid this company like the plague, because if they've made one mistake this enormous, they've probably made more. And the next person who finds one of them is extremely unlikely to be so kind and generous.
[ link to this | view in chronology ]
Unauthorized Access?
[ link to this | view in chronology ]
[ link to this | view in chronology ]
"private database"
Look over there at the very bad man who told us that we fucked up & violated all of our customers trust. Do not question how we might be using this data to make more money, burn the bad man who exposed we are incapable of protecting our most important data...
They can't protect a database, and you pay them to protect your kids... perhaps you should focus on that.
[ link to this | view in chronology ]
Defamation suit time
No vagueness needed here at all...just all those specific, FALSE insinuations not based on what is known publicly about the researcher.
[ link to this | view in chronology ]