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.
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: auto tracking, data breach
Companies: kromtech security center, svr tracking
Reader Comments
Subscribe: RSS
View by: Time | Thread
[ link to this | view in chronology ]
We're getting screwed by these constant leaks & companies are allowed to hide it happened.
We have the political will to pass laws demanding sodas be a certain size, but no punishments for those entrusted with data who betray this trust.
[ link to this | view in chronology ]
Not only are they legally and economically beyond any punitive enforcement, but culturally beyond any kind of positive or negative reinforcement to get them to move in a direction toward any kind of quality or ethical behavior. Most real costs to our lovely economic experiment are entirely external to these industries. And then they go ahead and invent more of them.
[ link to this | view in chronology ]
I can't help but look at this from a slightly different perspective: When we keep seeing this exact same thing happen over and over, (organization XYZ left data sitting around exposed in an Amazon S3 bucket,) why is no one asking why Amazon makes it so easy to screw up?
[ link to this | view in chronology ]
Re:
Every step in securing your data means more time spent thinking of vectors of attack, ways of making servers harder to exploit, and updating *everything* in a corporate environment ASAP.
That last reason especially sticks in the craw of most non-data related businesses (Amazon doesn't count in this case). Trying to update software often means man hours lost on an entire corporate network.
I've listened to software engineers and security experts bitch about convincing companies to do the safest things, it's nearly impossible to convince anyone to remain up-to-date with security practices because these excuses are made over and over.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re:
But that’s not an excuse. Companies have to take security seriously, and they don’t. They take the theatrics of security really seriously and think that the problem is solved.
This is one of the many things that goes wrong when you put a business person in charge of your technology team. Instead of a technologist.
The marketing doesn’t help. Everyone says, “Oh, it’s so easy to do this thing that you need to do if you just use <AWS service>.”
Of course it’s easy to do it in the trivial, insecure, proof-of-concept way. And that’s as far as most projects get in the real world. You show someone that it can be done, and when that news makes it up to a certain level of the chain, then you get told to go ahead and launch. Even though the product is only a third done.
No one cares. Just get it done. You bring up security, and people don’t care. Doesn’t matter. Get this out the door and move on to the next thing. We’ll come back and fix everyth8ng later.
Outside of dedicated tech companies (who also fuck up like this), software is an inconvenience to the business people who run the show. They have to have it, and they have to pay for it, but they don’t understand it and don’t care about it.
Which is all fine and good with me. Just don’t put those people in charge of your software and then get surprised when it sucks and your security is a broke-ass checklist that someone in Legal googled 10 years ago, and that’s the only policy you have.
It’s easy to point a finger at the tech teams who make these kinds of mistakes, and it’s a finger that should be pointed. But not the only one. This is a systemic problem in corporate culture and how businesses interact with their technology teams. Everyone wants all the benefits of automation, but companies haven’t yet figured out how to integrate these things correctly yet.
We’re still in the early stages of this process, and no one has figured out a good answer. And our very own darlings of the tech world do not help things in the slightest way. You’ve got agile zealots as managers on the one hand who build you a skateboard when you ask for a car and tell you they’ll iterate later, you’ve got waterfall people on the other hand who promise a car and plan a tank for 5 years and never deliver, and that’s just at the level of management for people who actually claim to understand technology.
At the top levels of actual technology companies, you’ve got assholes like Kalanick, incompetents like Fiorina, and salesmen like Balmer. None of whom help make the case that business people should put technology people in charge of anything.
There’s a metric fuck-ton of blame to go around for these security breeches. And some of it belongs to the low-level engineers like me who just give up after a while because nothing is ever going to get done right. But there’s also plenty to go around for shit managers who don’t understand what they are doing and naive business people who listen to and hire them because they honestly don’t know any better.
The whole business is pretty much hosed at the moment, and I’m not sure how to make it better. How do you change a culture of willful ignorance? How do you change a culture of complacency?
Will fines and penalties do it? I don’t think so. It will be absorbed into the cost of doing business, or it will simply accelerate the rotation of the merry-go-round of fools in management.
Sorry if I come across as strident. I just quit a job that I otherwise liked because of exactly these issues. I’d rather be broke than be responsible for one of these leaks, and I’m pretty jaded and cynical about everything at the moment.
[ link to this | view in chronology ]
If you need a credit check for buying a House or whatever, you can temp unlock. Here's how you go about doing it!!!
http://clark.com/personal-finance-credit/credit-freeze-and-thaw-guide/
Trying to fix your screwed up credit after the fact and your identity stolen, it's really the best thing to do.
So many company's have so much of your personal Data, and then they have crap security to protect it. Clearly they don't learn the mistakes from others.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
It’s about tech and business people not being able to communicate.
It’s about people asking me, “Hey, can we do this, and how fast?”
And then me saying, “Oh, for a trivial case, it’s done. Here you go. Would you like to move forward with the project?”
Manager: “What project? It’s already done. Push it to prod now.”
Me: but but but it only sort of works, and it’s massively insecure. It’s just a prototype. It’s proof of concept.
Product manager: it passes all the user acceptance tests. Deploy.
Me: But but but. This is a terrible idea. It’s not even half done.
Manager: just get it out there. We’ll clean it up and iterate later.
Who gets castrated in this situation? The engineer, the product manager, or the business manager?
The bottom line is that everyone who stores user data is a technology company. But no one wants to put engineers in charge of anything. Because we are bad at being in charge. It’s a fundamental conflict between getting things done and getting things right.
How do you propose that we solve this?
[ link to this | view in chronology ]
Kromtech notes that SVR tracking did at least store the data using a cryptographic hash function...
Excuse me? A cryptographic hash function is not encryption. That's like saying someone locked his house by taking a picture of all of his doors.
[ link to this | view in chronology ]
Hire Competent People
[ link to this | view in chronology ]
SHA-1
The only "exploitable weakness" in SHA-1 is a collision attack with complexity 2^63, so not "easily" and has nothing to do with this case anyway (you'd want a preimage attack; none is known). They could've hashed with something newer like SHA-3 and it wouldn't have helped; a single hash application simply isn't appropriate for low-entropy data like passwords.
[ link to this | view in chronology ]
Re: SHA-1
Are they saying the only thing we could see is the hash? Then there would be no problem, because the hash does not contain the data.
But they said the data was exposed, and if it was, SHA-1 does nothing, because it is not encryption; it conceals nothing.
[ link to this | view in chronology ]