comments from the first time this was posted here https://news.ycombinator.com/item?id=14314205

Denouement, in which the author is not rewarded:

> The company fixed the leak 3 weeks later by providing new Web services endpoints that use authenticated calls. The company mailed its users saying them to update their App as soon as possible. The old Web services have been shutdown after 1 month and half since my first contact with the CERT Nazionale.

> I could be wrong, but I suspect the privacy flaw has been around for 3 years because the first Android version of the App uses the same APIs.

> I got no bounty.

> The company is a leading provider of telematics solutions.

I wonder how much that flaw would have fetched from a malicious actor?

Not much. It's a good finding; as a bounty submission (for a good company), I could see it getting $1-$2k. But I don't think there's a market for these kinds of information leakage bugs. As a rule of thumb: if you can't plug a vulnerability directly into a business process that was already built and operationalized on some other vulnerability, it's probably not worth anything on the black market.

It might be good for class action lawyers and bounty hunters to start teaming up. Then the company either settles up to avoid a trial and bad publicity, or else they have an expensive court battle with potential negative PR coming out.

Something like that already happened with Justine Bone and Medsec.

This seems like the kind of bug that can cause a lot of harm (if a malicious actor wants to track someone's location) but not so much profit (no generic mass-account-stealing).

And that's a situation that the US legal system isn't well set up for.

Wow. This is gross negligence. Short version: the guy's insurance company had him put a GPS-enabled device in his car to measure usage. With no auth and only the car's license plate number, you can track the car, find out who owns it, and get a bunch of stats.

This is the kind of thing that should result in a fine of millions of dollars. They never even tried to secure this.

I have not seen him mentioning that the web service is apparently invoked over unsecure http. You can still add authentication, but if the service is running over http yu might as well not have any authentication at all.

>I have not seen him mentioning that the web service is apparently invoked over unsecure http.

It's mentioned. From the blog post: "besides the ugliest formatting ever and the fact the request uses plain HTTP"

In theory you could encrypt the payloads via some other means and use something like HTTP digest authentication, but I'm sure that's not what happens here.

Pretty certain I read this last year.

I assume you are getting down voted because you aren't contributing to the topic at hand and instead are turning it into a FOSS politics thing.

Thanks for the explanation.

Actually, it wasn't really my intention to start a FOSS debate, because I think there are no two opinions about it if this story would exist without the FOSS philosophy and I just wanted to highlight that.

Unless there has been some new innovation in this space, the OBD behavior trackers are just accelerometers. The typical placement down in the driver's footwell makes GPS too unreliable to bother with. The GPS correlation comes from being foolish enough to install their app.

There are many insurance companies that use OBD GPS trackers, as well as standalone trackers that plug in to the cigarette lighter, in order to charge based on mileage.

e.g. https://www.metromile.com/

They don't work well. I deal with them at work. The data is terrible.

What about wifi and cell networks? I've never looked into these devices, but surely that would be an easy way to get the general location of most cars.

Its certainly possible but these things are built to be dirt cheap.

I figured that they would use an app on your phone for GPS, accelerometer data, and gyro. The OBD adapter would just pull things like speed and be used to recognize that you're driving.

The Zubie receives GPS just fine.