Capital One Gets In On The Data Breach Action, Coughs Up Info On 100 Million Customers To A Single Hacker

from the another-company-tells-customers-to-look-under-their-seats-for-free-credit-monito dept

Another day, another major data breach.

In one of the largest thefts of data from a bank, a software engineer in Seattle hacked into a server holding customer information for Capital One and stole millions of credit card applications, federal prosecutors said on Monday.

The suspect, Paige Thompson, left a trail online for investigators to follow, according to court documents in Seattle, where she was charged.

Let's go ahead and move on from the New York Times' use of the words "theft" and "stole" to refer to the exfiltration of a copy of data Capital One still holds and on to the fact that the only thing unusual about this breach is that a suspect has already been arrested and charged.

The timetable is pretty tight too, if Capital One is being honest about when it first discovered the breach.

Capital One Financial Corporation (NYSE: COF) announced today that on July 19, 2019, it determined there was unauthorized access by an outside individual who obtained certain types of personal information relating to people who had applied for its credit card products and to Capital One credit card customers.

That's a big "if" -- one that's certainly called into question by the swift apprehension of a suspect. Maybe this is all on the level. Even if it is, does it matter? Companies collecting massive amounts of data are still, on the whole, pretty cavalier about data security, even as breach after horrifying breach is announced.

Given the data obtained, it almost seems like it would have been far less labor-intensive to just scour the web for a copy of the Equifax breach and download that instead. The Venn diagram of the sensitive data likely has a significant overlap.

Then there's the press release by Capital One, which inadvertently shows how little it really cares what happens to customers' sensitive information.

No bank account numbers or Social Security numbers were compromised, other than:

About 140,000 Social Security numbers of our credit card customers

About 80,000 linked bank account numbers of our secured credit card customers

Wat.

Nothing was compromised but the stuff that was compromised. This is the laziest spin I've ever seen applied to a data breach. And I've seen the federal government in action.

And hooray for American exceptionalism?

For our Canadian credit card customers, approximately 1 million Social Insurance Numbers were compromised in this incident.

Let's not step up to congratulate the G-men for their swift apprehension of the suspect. It appears the person accused of hacking Capital One's data engaged in zero opsec, turning the difficulty level down to "Easy" for investigators.

“I’ve basically strapped myself with a bomb vest,” Ms. Thompson wrote in a Slack post, according to prosecutors, “dropping capital ones dox and admitting it.”

Online, she used the name “erratic,” investigators said, adding that they verified her identity after she posted a photograph of an invoice she had received from a veterinarian caring for one of her pets.

All told, more than 100 million people are affected by this breach. Some are more affected than others, but this puts the Capital One breach on par with the Equifax breach in terms of potential victims. Unlike Equifax, the exfiltrated information was voluntarily given to Capital One by its customers, rather than harvested en masse without explicit consent for the sole purpose of selling to creditors.

And while the data stores of Rome are burning, the US government fiddles. Meaningless settlements do nothing to encourage better security efforts and the head of the DOJ is spending his time arguing against strong encryption. It's time to retire the sunglasses. The future isn't all that bright after all.

Filed Under: credit cards, data breach, hacks, paige thompson, social security numbers
Companies: capitol one

Police Misconduct, Data Breaches, And The Ongoing Lack Of Accountability That Allows These To Continue

from the bad-cops-and-bad-corps dept

Data breaches occur daily, affecting thousands of people. And everyone shrugs and moves on with their lives, especially those running the affected companies. Why? Because nothing ever happens to companies which have carelessly exposed data, as Cory Doctorow points out:

Data breaches keep happening, they keep getting worse, and yet companies keep collecting our data in ever-more-invasive ways, subjecting it to ever-longer retention, and systematically underinvesting in security.

Why does this keep happening? Because it's affordable. In 2014, Home Depot breached more than 50,000,000 credit-cards; in 2016, they paid less than $0.34/customer in restitution.

There are longer-term reputational costs associated with breaches, but these are not generally factored into the quarterly-earnings-focused mindsets of corporate execs and strategists.

Two of the most damaging breaches in recent years involved millions of people who were given little or no choice in how much personal data of theirs was held by these entities. One was the Office of Personnel Management. Those seeking government jobs turn over a lot of info to the government, which then handles it carelessly.

The other -- Equifax -- was even worse, at least in terms of consent. There was none. No one voluntarily hands information to Equifax. It's gathered by Equifax which sells access to any number of companies seeking credit records. No one opts in and, more importantly, there's no way to opt out.

No one can hold these entities accountable, at least not to the extent it will deter future breaches. Because of that, the only thing we're guaranteed is more breaches. These companies and agencies will continue to exist, hoovering up even more personal data, and, eventually, leave it exposed where criminals can make the most of other people's finances.

From one wheelhouse to another, the same can be said for law enforcement agencies and police misconduct. In almost every case, a police officer sued for rights violations pays nothing for the wrongs committed. Neither does the agency employing the officer. This is from a study of police indemnification published by the New York University Law Review:

During the study period, governments paid approximately 99.98% of the dollars that plaintiffs recovered in lawsuits alleging civil rights violations by law enforcement. Law enforcement officers in my study never satisfied a punitive damages award entered against them and almost never contributed anything to settlements or judgments—even when indemnification was prohibited by law or policy, and even when officers were disciplined, terminated, or prosecuted for their conduct.

Officers are never made to personally feel the pain of a settlement. The officer often returns to work with only the minor black mark of a lost lawsuit on their record. Consequently, the violations continue because officers have nothing at stake. If they screw up, another government entity picks up the tab using taxpayer dollars.

The solution to this problem isn't as readily apparent as it might seem. Personal indemnification -- forcing officers to be held personally responsible for settlements stemming from rights violations -- seems like a good deterrent, but it has its downsides. Scott Greenfield has examined the issue and the flaws are right below the satisfying gloss covering the surface.

Often, the argument is that the solution to police violence is to make the cop personally liable for his conduct, shift the incentive system from the municipality, or more accurately its taxpayers, to the bad dude who did the dirty. Make him suffer.

The problem is that the cop may be judgment proof. If the cop has no wealth or assets, there is no fund from which to collect a judgment. You can’t get blood from a rock.

While this may be an effective deterrent, it doesn't do anything to make the plaintiff whole. Having a city cover the cost ensures the victim will be paid, but it lets the officer off the hook.

What's the solution? Perhaps it's a sharing of the burden. Officers could be made to carry their own litigation insurance. This would eliminate the free pass of outside indemnification by making every act of misconduct count. Get sued often enough and the insurance company will drop the officer. An officer without insurance is pretty much unemployable.

It's also a win for officers, who would no longer gripe about cities settling too easily with plaintiffs and other besmirching the barrel of apples by proxy. Sure, they won't be nearly as vocal about it when their own insurance coverage is on the line, but it will put their own insurance premiums where their mouths are, which would be small victory in and of itself.

Circling back outside to the original wheelhouse, what can be done to make companies actually care about data breaches? So far, nothing seems to be slowing the flow of carelessly exposed data. Doctorow has a suggestion, and it runs along the lines of the solution that (might!) work for law enforcement:

If companies were paying out damages commensurate with the social costs their data recklessness imposes on the rest of us, it would have a very clarifying effect on their behavior -- insurers would get involved, refusing to write E&O policies for board members without massive premium hikes, etc. A little would go a long way, here.

There are no perfect solutions. But we simply shouldn't settle for the status quo. Neither group will welcome increased accountability, but there's simply no reason we should continue to let them skate, either.

Filed Under: cybersecurity, data breach, police, police misconduct
Companies: equifax

Everything Wrong In One Story: Data Silos, Privacy, And Algorithmic Blocking

from the nerding-harder-won't-solve-complex-problems dept

Facebook is probably not having a very good week concerning its privacy practices. Just days after it came out that -- contrary to previous statements -- the company was using phone numbers that were submitted to Facebook for two-factor-authentication as keys for advertising, earlier this morning the company admitted a pretty massive data breach in which its "view as" tool was allowing users to grab tokens of other users and effectively take over their accounts (even if those users had two factor authentication enabled).

This is, as they say, "really, really bad." It turned the "view as" feature -- which lets you see how your own page looks to other users -- into a "take over someone else's account" feature. That's a pretty big mistake to make for a product used by approximately half of the entire population of the planet. I'm sure there will be much more on this, but a few hours after the announcement, Facebook had another headache to deal with: numerous reports said that people trying to post articles about this new security mess from either the Guardian or the AP, were getting that action blocked, with Facebook's systems saying that the action looked like spam:

If you can't read that, it says:

Action Blocked

Our security systems have detected that a lot of people are posting the same content, which could mean that it's spam. Please try a different post.

If you think this doesn't go against our Community Standards let us know.

It's not hard to see how this happened of course. Many times, when a ton of people all start linking to the exact same story, there's a decent chance that it might just be a spam attack. I think even our own spam filter for the Techdirt comments takes something similar into account. Thus, with so many people all posting that link to Facebook, it tripped an algorithmic alarm, leading it to block the posting as possible spam. It appears this practice only lasted for a little while, as currently both articles can be posted to Facebook again.

Obviously, given that the content was about a big Facebook security breach, this looks fishy, even if there's a perfectly "logical" explanation for how it happened. But this also gives us yet another opportunity to highlight how ridiculous it is for people to argue that algorithmic content moderation is a reasonable solution. It's always going to mess up, especially when used at scale, and sometimes will do so in incredibly embarrassing ways, such as here.

And, of course, it provides yet another opportunity to highlight the problems of having just a few giant silos collecting and keeping so much data about people. Even if they are very good at security -- and despite arguments to the contrary, Facebook has a strong security team -- there are always going to be vulnerabilities like this, and companies like Facebook are always going to represent huge targets. This seems like yet another reminder that we need to be looking for more solutions to decentralize the web, and move away from giant silos holding onto all of our data.

Tragically, the powers that be are often looking at this the other way: trying to magically "force" big companies to "lock down" data, which actually only increases the value and demands on the silo, while expecting magic algorithms to protect the data. If we're serious about protecting privacy, we need to start looking at very different solutions that don't mean letting the giant internet companies control all this data all the time. Move it out to the ends of the network, let individuals control their own data stores (or partner with smaller third parties who can help with security) and then let those users choose when, how and where to allow the large platforms access to that data (if at all). There are better solutions, but there seems to be little interest in actually making them work.

Filed Under: algorithms, blocking, centralization, content moderation, data breach, decentralization, privacy, silos, spam, tokens
Companies: facebook

Another Day, Another Pile Of Voter Data Left Laying Around On A Public Server

from the you'd-think-we'd-learn-something dept

Leaving private voter or customer data easily accessible on a public-facing server is the hot new fashion trend. You'll recall that it's a problem that has plagued the Defense Department, GOP data firm Deep Root Analytics (198 million voter records exposed), Verizon's marketing partners (6 million users impacted), Time Warner Cable (4 million users impacted), and countless other companies or partners that failed to implement even basic security practices. And it's a trend that shows no sign of slowing down despite repeated, similar stories (much of it thanks to analysis by security researcher Chris Vickery).

This week yet another pile of private voter data was left publicly accessible for anybody to peruse. According to analysis by Kromtech Security’s Bob Dianchenko, a Virginia-based political consulting and robocalling company by the name of Robocent publicly exposed 2,600 files, including voter file spreadsheets (including voter phone numbers, names, addresses, political affiliations, gender, voting districts and more) and audio recordings for a number of political campaigns.

When Diachenko contacted the firm, he was told that they were a "small shop" and that "keeping track of everything can be tough." In a statement to ZDNet, which first reported the latest exposure, Robocent co-founder Travis Trawick did his best to downplay the exposure by insisting the data was stale, and publicly-available anyway:

"In an emailed statement, Robocent co-founder Travis Trawick confirmed that the data had been secured, and claimed that the data was from "an old bucket from 2013-2016 that hasn't been used in the past two years." He confirmed that the company is investigating the scope of the data that was accessible. "All exposed data was publically available information," he said, adding that he will contact affected customers "if required by law."

The problem: what's deemed "publicly available" varies from state to state. While voter data is generally a matter of public record, states like Maine and Massachusetts restrict the use of such data for political campaign purposes. Other States, like South Carolina, have restrictions on only selling said data if you're a registered voter in the state. And while the data may have been stale, it still wasn't adequately protected however you slice it; it was quickly indexed by GrayhatWarfare, a searchable database where a current list of 48,623 open S3 buckets can be perused at your leisure.

This latest exposure is believed to be the fifth major breach of voter data in the last half-decade. It's a trend that shows no real sign of slowing down despite the simplicity of protecting this data and the rampant press coverage such exposures routinely receive.

Filed Under: bob dianchenko, data breach, security, travis trawick, voter data, voting
Companies: kromtech security, robocent

Another Company Blows Off Breach Notification For Months, Lies About Affected Customers When It's Exposed

from the trust-no-one dept

Another day, another security breach. Another day, another security breach handled badly by the company leaking data. Another day, another security researcher being treated like garbage for attempting to report it. Etc. Etc.

The victim perpetrator here is Panera Bread. Researcher Dylan Houlihan informed Panera Bread its online ordering service was leaking data. This notification happened months ago.

In August 2017, I reported a vulnerability to Panera Bread that allowed the full name, home address, email address, food/dietary preferences, username, phone number, birthday and last four digits of a saved credit card to be accessed in bulk for any user that had ever signed up for an account. This includes my own personal data! Despite an explicit acknowledgement of the issue and a promise to fix it, Panera Bread sat on the vulnerability and, as far as I can tell, did nothing about it for eight months.

Houlihan emailed Mike Gustavision -- then Panera's head of security -- about the vulnerability. Like many other discovered data leaks, all a user had to do was alter digits in company's online ordering site to view other people's personal information. Users did not even need a Panera account to do this.

Houlihan's notification attempt was greeted with derision by Panera's security head. [Click for a larger version.]

Dylan,

My team received your emails however it was very suspicious and appeared scam in nature therefore was ignored. If this is a sales tactic I would highly recommend a better approach as demanding a PGP key would not be a good way to start off. As a security professional you should be aware that any organization that has a security practice would never respond to a request like the one you sent. I am willing to discuss whatever vulnerabilities you believe you have found but I will not be duped, demanded for restitution/bounty or listen to a sales pitch.

Eventually, Gustavision provided a PGP key and allowed Houlihan to send him info on the site's vulnerability. But, as Houlihan points out, this is no way to treat someone reporting a possible breach. Not only was the immediate response needlessly combative, the company's response to the notification was to do nothing until it was publicized by other security researchers.

This was contrary to Gustavision's statements to Houlihan, which claimed Panera's security team was "working on a response." That was the claim last August. Houlihan continued to check the site since his own information was included in what was exposed and nothing changed until April of this year, eight months after being notified.

Somehow, Panera was magically on top of the situation when it went mainstream. After Brian Krebs spoke to the company's CIO about the breach, Panera briefly took its site offline for maintenance. It then declared it had fixed the hole within two hours of notification, glossing over the fact it had been notified eight months earlier and done nothing. It also downplayed the problem as only affecting a small portion of Panera customers.

Almost minutes after this story was published, Panera gave a statement to Fox News (no link will be provided) downplaying the severity of this breach, stating that only 10,000 customer records were exposed.

In essence, it lied to press outlets seeking comment. Security researchers noted the problem hadn't even been completely fixed yet.

Almost in an instant, multiple sources — especially @holdsecurity — pointed out that Panera had basically “fixed” the problem by requiring people to log in to a valid user account at panerabread.com in order to view the exposed customer records (as opposed to letting just anyone with the right link access the records).

And it was far, far bigger than Panera publicly claimed. Krebs initially estimated the exposed records at 7 million. Additional research by Krebs showed multiple divisions of Panera were affected by the same vulnerability (like its online catering service). After examining APIs used by Panera's online services, Krebs estimates close to 37 million records have been exposed.

What will Panera learn from this? Whatever it does learn won't spread to other companies, that's for certain. Breach after breach has shown us companies are willing to shoot the messenger, cover up the damage, ignore repeated notifications, and obfuscate when breaches are finally exposed. Panera didn't handle breach notification worse than other companies have. It just did as little as possible until forced to confront the problem. This mindset is shared by far too many entities. They love scooping up personal data, but not the security responsibility that comes with it.

Filed Under: data breach, leaks, security
Companies: panera

Both Facebook And Cambridge Analytica Threatened To Sue Journalists Over Stories On CA's Use Of Facebook Data

from the this-is-bad dept

I'm going to assume that you weren't living in an internet-proof cave this weekend, and caught at least some of the stories about Cambridge Analytica and Facebook. The news first kicked off with the announcement of a data protection lawsuit filed against Cambridge Analytica in the UK on Friday evening (we'll likely have more on that lawsuit soon), followed quickly by an attempt by Facebook to get out ahead of the coming tidal wave by announcing that it was suspending Cambridge Analytica and some associated parties from its platforms, claiming terms of service violations. This was quickly followed on Saturday with two explosive stories. The first, from Carole Cadwalladr at The Guardian, revealing a "whistleblower" from the very early days of Cambridge Analytica (who more or less set up how it works with data profiles) named Christopher Wylie. This was quickly followed up by another story at the NY Times, which was a bit more newsy, providing more details on how Cambridge Analytica got data on about 50 million people out of Facebook.

Admittedly -- much of this isn't actually new. The Intercept had reported something similar a year ago, though it only said it was 30 million Facebook users, rather than 50 million. And that story built on the work of a 2015 (yes, 2015) story in the Guardian discussing how Cambridge Analytica was using data from "tens of millions" of Facebook users "harvested without permission" in support of Ted Cruz's presidential campaign.

There's a lot of heat on this story right now, and a lot of accusations being thrown around, and I'll admit that I'm not entirely sure where I come down on the details yet. I assume people on basically both sides of this issue will scream at me and call me names over this, but there's too much going on to fully understand what happened here. I will note that, in that Guardian story in 2015, Cruz told the publication that this data collecting and targeting effort was "very much the Obama model." And political consultant Patrick Ruffini has a well worth reading Twitter thread arguing that people are overreacting to much of this, and that the 2012 Obama campaign did the exact same thing, and was celebrated for its creative use of data and targeting on the internet. Ad tech guy Jay Pinho makes the same point as well. Here's a Time article from 2012 excitedly talking up how the Obama campaign used Facebook in the same way:

That’s because the more than 1 million Obama backers who signed up for the app gave the campaign permission to look at their Facebook friend lists. In an instant, the campaign had a way to see the hidden young voters. Roughly 85% of those without a listed phone number could be found in the uploaded friend lists.

Of course, there is one major difference between the Obama one and the Cambridge Analytica one, which involves the level of transparency. With the Obama campaign, people knew they were giving their data (and friend's data) to the cause of re-electing Obama. Cambridge Analytica got its data by having a Cambridge academic (who the new Guardian story revealed for the first time is also appointed to a position at St. Petersburg University) set up an app that was used to collect much of this data, and misled Facebook by telling them it was purely for academic purposes, when the reality is that it was setup and directly paid for by Cambridge Analytica with the intent of sucking up that data for Cambridge Analytica's database. Is that enough to damn the whole thing? Perhaps.

As for the claims that this is just the same old Facebook model of selling everyone's data... that was not true and still is not accurate. Facebook doesn't sell your data. It sells access to its users via the data it has on you. That may not seem different, but it is different. But the lines do seem to get a bit blurry, as it appears that Cambridge Analytica, via its partnership with the professor Dr. Aleksander Kogan (who apparently briefly changed his name to -- I kid you not -- Dr. Spectre) and his "Global Science Research," basically paid people via Amazon's Mechanical Turk to do a "personality assessment" on Facebook that, as part of the process, exposed information about their entire social graph, which GSR apparently hoovered up and passed along to Cambridge Analytica.

At the very least, it can be said that Facebook should have recognized much earlier that this could and would be done, and to understand the potential privacy problems related to it. Facebook has a fairly long and painful history of not quite realizing how what it does impacts people's privacy, and this is one more example.

But, it's raising a bigger question, as well, and it's one that caused Facebook to do something that I'll definitively call as "incredibly stupid," which is that it threatened to sue the Guardian over its story, mainly because the Guardian story refers to this whole mess as a "data breach" for Facebook's data.

And, of course, Facebook wasn't the only one who threatened to sue. Cambridge Analytica did too:

The Observer also received the first of three letters from Cambridge Analytica threatening to sue Guardian News and Media for defamation.

There are issues of terminology here. Facebook, in its post, is adamant that what happened is not a "breach"

The claim that this is a data breach is completely false. Aleksandr Kogan requested and gained access to information from users who chose to sign up to his app, and everyone involved gave their consent. People knowingly provided their information, no systems were infiltrated, and no passwords or sensitive pieces of information were stolen or hacked.

There are legal reasons why Facebook is so concerned about whether or not this is a "breach" and, let's face it, the company is about to face a million and a half lawsuits over this, not to mention government investigations (already Senator Amy Klobuchar has demanded Mark Zuckerberg's head on a platter testimony before the Senate and Massachusetts' Attorney General Maura Healey has announced the opening of an investigation, and there have also been rumblings out of the UK and the EU, as well as the FTC). But, there are also some fairly important legal obligations if this was a "breach" in the traditional sense, such as disclosing that to those impacted by the breach.

I'm not entirely sure where I come down on the breach question. It doesn't feel like a traditional breach. It wasn't that Facebook coughed up this info, it was its users coughed up the info... and Facebook just made it easy for this outside "academic" to hoover up all that info by paying a bunch of people to take dopey personality quizzes. However, as the Guardian's Alex Hern points out, how do you distinguish what Kogan/GSR/Cambridge Analytica did from social engineering to get information.

Of course, there is something of a difference: it still wasn't Facebook per se coughing up the info. It was Facebook's own users. And, you might even argue that if you believe that Facebook doesn't "own" all this data in the first place, that it was actually those Facebook users coughing up a bunch of their own data -- including lots of data about their friends. Needless to say, this is a mess where a lot more transparency might help, and that transparency is going to be forced upon Facebook with a sledgehammer in the near near future.

But, regardless of where you come down on all of this, Facebook threatening defamation against the Guardian for calling this a data breach is ludicrous and Facebook should be ashamed and apologize. Even as it clearly disagrees with how the Guardian characterized much of the story, that's no excuse to whip out defamation threats. Not only is it incredibly stupid from a Facebook PR perspective (and makes the company look like a giant bully), it suggests that the company still has absolutely no fucking clue how to communicate with the press and the public about how its own platform works.

It's actually quite incredible to recognize just how big Facebook has gotten in the face of how little it seems to understand about what its own platform does.

Filed Under: aleksander kogan, christopher wylie, data, data breach, data sharing, elections, transparency
Companies: cambridge analytica, facebook, global science research

UK Court Says Company Is Innocent In Massive Data Breach Caused By Vindictive Employee, But Must Nonetheless Pay Compensation

from the who-said-life-is-fair? dept

It's well known that the EU has laws offering relatively strong protection for personal data -- some companies say too strong. Possible support for that viewpoint comes from a new data protection case in the UK, which follows EU law, where the judge has come to a rather surprising conclusion. Details of the case can be found in a short post on the Panopticon blog, or in the court's 59-page judgment (pdf), but the basic facts are as follows.

In 2014, a file containing personal details of 99,998 employees of the UK supermarket chain Morrisons was posted on a file-sharing Web site. The file included names, addresses, gender, dates of birth, phone numbers (home or mobile), bank account numbers and salary information. Public links to the file were placed elsewhere, and copies of the data sent on a CD to three local newspapers, supposedly by someone who had found it on the Internet. In fact, all the copies originated from Andrew Skelton, a Senior IT Auditor in Morrisons, as later investigations discovered. According to the court, Skelton had a grudge against the company because of a disciplinary process that took place in 2013. As a result of the massive data breach in 2014, Skelton was sentenced to eight years in prison.

The current case was brought by some 5,500 employees named in the leaks, who sought compensation from Morrisons. There were two parts to the claim. One was that Morrisons was directly to blame, and the other that it had "vicarious liability" -- that is, liability for the actions or omissions of others. The UK judge found that Morrisons was not directly liable, since it had done everything it could to avoid personal data being leaked. However, as the Panopticon blog explains:

having concluded that Morrisons was entirely legally innocent in respect of Skelton's misuse of the data, the Judge held that it was nonetheless vicariously liable for Skelton's misdeeds

That is a legal bombshell as far as UK privacy law is concerned, since it means that a company that does everything it reasonably can to prevent personal data being revealed can nonetheless be held vicariously liable for the actions of an employee, even a malicious one. That clearly offers an extremely easy -- if potentially self-damaging -- route for disgruntled employees who want to harm their employers. All they need to do is intentionally leak personal data, and the company they work for will have vicarious responsibility for the privacy breach. In fact, even the judge was worried by the implications of his own decision:

The point which most troubled me in reaching these conclusions was the submission that the wrongful acts of Skelton were deliberately aimed at the party whom the claimants seek to hold responsible, such that to reach the conclusion I have may seem to render the court an accessory in furthering his criminal aims.

As a result, the judge granted leave for Morrisons to appeal against his judgment that it was vicariously liable. Hundreds of thousands of companies around the UK will now be hoping that a higher court, either nationally or even at the EU level, overturns the ruling, and sets a limit on those super-strong data protection laws.

Follow me @glynmoody on Twitter or identi.ca, and +glynmoody on Google+

Filed Under: data breach, data protection, employees, eu, liability, responsibility, uk

Auto Location Tracking Company Leaves Customer Data Exposed Online

from the stop-doing-that dept

What is it about companies (or their contractors) leaving consumer data publicly exposed on an Amazon cloud server? Verizon recently made headlines after one of its customer service vendors left the personal data of around 6 million consumers just sitting on an Amazon server without adequate password protection. A GOP data analytics firm was also recently soundly ridiculed after it left the personal data of around 198 million citizens (read: most of you) similarly just sitting on an Amazon server without protection. Time Warner Cable also recently left 4 million user records sitting in an openly-accessible Amazon bucket.

This sort of incompetence shows no sign of slowing down. Not to be outdone, The Kromtech Security Center recently found over half a million records belonging to SVR Tracking, a company that helps track your car's location for its “vehicle recovery" service, left sitting online without adequate security. You guessed it: the company apparently also thought it would be a good idea to leave this data sitting on an Amazon server openly accessible via the internet:

"Kromtech discovered SVR’s data in a publicly accessible Amazon S3 bucket. It contained information on roughly 540,000 SVR accounts, including email addresses and passwords, as well as some license plates and vehicle identification numbers (VIN). There were half a million records overall, Kromtech said, “but in some cases credentials were given for a record with several vehicles associated with it.”

In this case, Kromtech notes that SVR tracking did at least store the data using a cryptographic hash function (SHA-1), albeit one that’s 20 years old and with easily-exploitable weaknesses. And while there certainly have been much larger security breaches in recent months, this one is notable for its high creep factor. SVR advertises that its technology provides “continuous vehicle tracking, every two minutes when moving” and a “four hour heartbeat when stopped.” That means that a hacker that had gained access to the login data would be able to track everywhere a customer's car has been in the past 120 days.

In addition to SVR account information, the exposed data also included documents and images related to vehicle maintenance records, as well as contract details with the roughly 400 or so dealerships that have business relationships with SVR. Fortunately SVR secured the data two days after Kromtech notified them of it, but refuses to clarify the scope of the breach to either Kromtech or the press. Kromtech notes that the data exposed could be significantly larger than initial reports indicate:

"The overall number of devices could be much larger given the fact that many of the resellers or clients had large numbers of devices for tracking. In the age where crime and technology go hand in hand, imagine the potential danger if cyber criminals could find out where a car is by logging in with the credentials that were publicly available online and steal that car?”

Of course this new trend of just leaving customer data sitting openly on the Amazon cloud is running hand in hand with the abysmal security already inherent in embedded car infotainment and navigation systems, problems we might want to more seriously contemplate before we automate the entire country's transportation and delivery systems.

Filed Under: auto tracking, data breach
Companies: kromtech security center, svr tracking

Court Stays FTC's LabMD Injunction; No Deterrent In Punishing A Company It Helped Kill

from the killing-a-horse-just-to-beat-it dept

Despite turning LabMD into a stone -- based on some suspect data breach allegations by a data protection company engaged in shady sales tactics -- the FTC is still seeking to extract as much blood as possible. Thanks to the FTC's ongoing efforts against LabMD, the company has been closed, has less than $5000 to its name, and is fighting back against the commission with pro bono help.

The FTC wants to punish LabMD for a patient file that ended up file sharing services thanks to an employee's use of Limewire at work. (The file was in folder that end up being "shared" by default Limewire settings [My Documents].) Tiversa, a company that prowled file sharing services for sensitive documents in hopes of leveraging these into data security contracts, took this info to the FTC when LabMD refused to purchase its offerings.

Since that point, the FTC has bankrupted LabMD by forcing it to defend itself against a supposed breach that never resulted in the misuse of patient data. Tiversa has seen its own fortunes diminish, culminating in an FBI raid of its offices in March of this year.

The FTC overturned an Administrative Law Judge's (ALJ) decision in July, giving itself permission to restore its charges against LabMD for the breach -- ones the ALJ had dismissed. The FTC claims LabMD "left" the mistakenly-shared file out somewhere in the internet, as if the company actually had any way to "retrieve" it once it had been uploaded.

Seemingly unconcerned that LabMD is now a defunct company, the FTC still wants it to implement a series of expensive steps to ensure the data it won't be collecting in the future is better protected.

Having found that LabMD violated the FTC Act, the Commission’s Final Order will ensure that LabMD reasonably protects the security and confidentiality of the personal consumer information in its possession by requiring LabMD to establish a comprehensive information security program. It also requires LabMD to obtain periodic independent, third-party assessments regarding the implementation of the information security program, and to notify those consumers whose personal information was exposed on the P2P network about the unauthorized disclosure of their personal information and about how they can protect themselves from identity theft or related harms.

LabMD has asked for a stay of this injunction pending its appeal. That stay has been granted by the Eleventh Circuit Appeals Court. (via the Office of Inadequate Security)

The appeals court points out [PDF] several things about the stay the FTC is contesting, not the least of which is the company's inability to actually follow the injunction if granted, much less have any reason to do so, given its current situation.

The costs of complying with the FTC’s Order would cause LabMD irreparable harm in light of its current financial situation. [...] The costs associated with these measures are hotly debated by the parties. LabMD says the costs will exceed $250,000. The FTC does not offer its own estimate, but disputes the $250,000 figure. Regardless, it is clear that the postage for the notice requirements alone would be more than $4,000. Certainly the costs of all the other measures would add to that amount.

LabMD is no longer an operational business. It has no personnel and no revenue. It now has less than $5,000 cash on hand. It reported a loss of $310,243 last fiscal year, and has a pending $1 million judgment against it on account of its early termination of its lease. LabMD cannot even afford legal representation, and is relying on pro bono services for this appeal.

Given the company's financial ruin, the injunction would serve no possible deterrent purpose. There's nothing left to destroy and, unfortunately, nothing to be gained by LabMD, even if it ultimately prevails.

Ordinary compliance costs are typically insufficient to render harm irreparable. But given LabMD’s bleak outlook, the costs of compliance pending appeal would constitute an irreparable harm. This is especially so because if LabMD is ultimately successful on appeal, the costs would not be recoverable in light of the FTC’s sovereign immunity.

Furthermore, the court feels there's absolutely no risk to the further exposure of patients' data, even with the file still supposedly in the wild. The company has its own copy, residing on a computer that is never connected to the internet. If a customer requests data, LabMD hooks it up to printer and mails or faxes them a hard copy.

As for the FTC's claim that a file that has been in the wild since 2005 would result in future breaches of patient confidentiality, the court is rather skeptical.

For those patients whose personal information was in the 1718 file, there is no evidence of a current risk to them. Specifically, there is no evidence that any consumer ever for nefarious purposes before this appeal terminates. suffered any tangible harm, or that anyone other than Tiversa, LabMD, or the FTC has seen the 1718 file. Although the FTC’s Order denying LabMD’s stay application says there remains a potential risk of harm to consumers whose information was in this file, we think it improbable that a party downloaded this information now years ago, has not used it for several years, but may yet use it for nefarious reasons before this appeal terminates.

Finally, the court has a few choice words for the FTC's dictionary attack -- used to shore up its weak claims of future harm from the escaped file.

[I]t is not clear that the FTC reasonably interpreted “likely to cause” as that term is used in § 45(n). The FTC held that “likely to cause” does not mean “probable.” Instead, it interpreted “likely to cause” to mean “significant risk,” explaining that “a practice may be unfair if the magnitude of the potential injury is large, even if likelihood of the injury occurring is low.” The FTC looked to different dictionaries and found different definitions of “likely.” It is through this approach that it argues its construction is correct, considering the statute’s context as a whole.

Even respecting this process, our reading of the same dictionaries leads us to a different result. The FTC looked to dictionary definitions that say “likely” means “probable” or “reasonably expected.”Reliance on these dictionaries can reasonably allow the FTC to reject the meaning of “likely” advocated by LabMD, that is, a “high probability of occurring.” However, we read both “probable” and “reasonably expected,” to require a higher threshold than that set by the FTC. In other words, we do not read the word “likely” to include something that has a low likelihood. We do not believe an interpretation that does this is reasonable.

The sick thing is that even if LabMD ultimately prevails, it won't matter. It cannot recover any of its expenses and the company has been gutted by its fight against the FTC. That the whole situation appears to have stemmed from a data protection company's shady sales pitch is even worse. Tiversa not only was uncooperative during the FTC's investigation of LabMD, but it has also drawn the attention of the House Oversight Committee, which was unimpressed by the Tiversa's tactics both before and after the FTC's investigation of LabMD.

Filed Under: court, data breach, file sharing, ftc, injunction
Companies: labmd, tiversa