Hacker News new | past | comments | ask | show | jobs | submit login

Hi all, I'm the researcher who found the bug. I started looking at it after I saw the earlier HN posting about Securus and LocationSmart.

Happy to answer questions and provide any additional context.

> and provide any additional context

Any context at all would be appreciated. The Krebs article mentions almost no context whatsoever about the bug except that you found an unauthenticated API.

Can you give some details about the API?

• Did you need to exploit SS7 flaws?

• Did you reuse some kind of nonce or session auth token, or was there no security whatsoever?

• Did it take phone numbers, hashes of phone numbers, bulk queries, etc.?

• Can we see example output data that you collected from the API?

• Did you notice the API endpoint in the devtools network tab, or did you have to dig much deeper?

You should do a write-up on the issue you found.

Thanks! I just finished the writeup, posted here: https://www.robertxiao.ca/hacking/locationsmart/

In short: it was a fairly straightforward modification of the usual API flow, to omit the secondary API call that requests consent, then request a JSON location payload instead of an XML payload. For whatever reason, that bypassed the usual consent check and just dumped the phone's location.

Man I got here once the link had already changed and your write up is concise and tells all of the necessary information versus the Krebs article which is way too long and really doesn't say much useful. Thanks!

Thanks, your write-up is very informative! I think the HN staff should change the URL to your post.

Changed. Thanks for emailing us! We wouldn't have seen this otherwise.

(Submitted url was https://krebsonsecurity.com/2018/05/tracking-firm-locationsm...)

When I read this I just started cackling like a mental patient.

The first thing that comes to mind is if this is on a well known framework, I want to know because those security defaults are awful.

However if these guys rolled their own API auth system and messed up something this simple, or deliberately modified framework defaults... I can't even imagine what conversations happened at their offices this morning.

> JSON location payload instead of an XML payload. For whatever reason, that bypassed the usual consent check

To me that sounds like you stumbled upon an unauthenticated development/debug mode.

That was unbelievable, nice find. Hope you share a POC on Github of how trivial it was. Welcome to the future, where an unauthenticated API by a company can tell you the position of anyone.

from https://www.locationsmart.com/platform/privacy

First Sentence: >> LocationSmart has built the most secure LBS location data exchange available today.

They go on:

>> Privacy and security are paramount in LBS services. Locking down privacy is not only core to our brand, it's also our unwavering business practice.

what a crock

> the most secure LBS location data exchange available today

To be fair, they are not wrong. I looked into getting real time cell location data a while back, and the security was basically IP whitelisting.

The old "We take privacy and security very seriously" line.

But for some reason, access control has something to do with LocationSmart's entity body serialization format... hmm, okay then.

I appreciate that you used Python 3 instead of 2 :)

Was there enough of a delay between the request and the reply to mitigate the risk of a bad actor flooding a particular cellphone with battery-discharging pings?

Props for finding the vuln.

The request-reply delay was between 3-5 seconds in most cases, but sometimes much higher for unknown reasons. I suspect that, if this is pinging the phone, you might be able to drain the battery remotely, but that's a fairly secondary concern considering the magnitude of the primary issue.

There is no phone pinging going on. The carriers most likely keep a database of most recent location of their customers based on customer phones pinging towers.

At most, hitting location smart over and over would probably just hit the carrier databases over and over.

> The carriers most likely keep a database of most recent location of their customers based on customer phones pinging towers.

You can strike “most likely” from your statement. Carriers definitively do this.

Congrats on the find! How did you know to test requesttype=locreq.json? I googled for "locationsmart locreq.json" and your blog post was the only result.

The first request is to "requesttype=statusreq.json", returning a JSON object, and the second to "requesttype=locreq" returning XML. On a whim I decided to try and get JSON location data out (I like JSON better anyway), and found that the two formats did not exhibit identical behaviour. On exploring that further, I found the consent bypass bug.

I'm impressed by the amount of good guesses you had to get there. Good job!

Did you find that it was carrier- or model-specific?

When I tried their own trial (before it was taken down), they were unable to locate my iPhone on AT&T.

I found it worked for all four major carriers (AT&T, T-Mobile, Sprint and Verizon) but around 1/10 phones failed to geolocate for unknown reasons. Unfortunately I didn’t get a large enough sample size to test these before it was taken down. It didn’t seem to correlate to device or carrier - I was locating iPhone and Android devices with equal ease.

Perhaps those were data devices like Hotspots, tablets and the like that can't make calls, thus there is no E911 mandate for said device? IIRC some newer LTE Data devices don't even have GPS, which would make locating a device harder if your a cellular carrier.

> newer LTE Data devices don't even have GPS, which would make locating a device harder if your a cellular carrier.

Nope, AGPS isn’t required. At any given time, multiple cell towers can hear your devices signal. In the rare event it’s just one, you still get a surprisingly accurate location due to a quirk of cell towers (there’s never just one antenna, except for small cells in places like subways, it’s usually three or more using sector panels). Given a 120° direction (or less) and a distance based on time of flight, you usually get within a few blocks in most cities, and that’s without factoring in triangulation or other more advanced localization techniques. One carrier (maybe more) has the ability to localize a person with a range of ten feet (not everywhere, but enough places to turn it into a product they sell), which is generally more accurate than AGPS.

Keep in mind a large part of what a cellular carrier needs to do is know which cell you're in so it can route traffic to your device. While they don't necessarily get device gps access, they literally cannot do what you're paying them for if they cannot locate you down to the nearest cellular base station. (And in most areas, they'll have you connected to enough base stations that they can at least roughly triangular you using signal strength to estimate distance from multiple cells. I don't know if 3G/4G/LTE allows base stations to calculate TOF roundtrip times to get even better distance accuracy like Wi-Fi does, but it wouldn't surprise me if there's not at least something in the spec that can be abused to allow that...)

Was that random phones, or phones you knew were actively in use?

I'd imagine a cellular network has some "exception handling" for devices that are not switched on or in range of any of it's base stations. And I hypothesise that whatever mechanism this is using might not crank up whatever "scan the whole network" behaviour that might occur if a not-currently-geolocated phone gets an incoming call/message? 1/10 seems too high to account for that though...

These were people's personal phones that they had with them, but no guarantee that they were actively being used.

I have a half off topic question: how are you doing this in light of the CFAA and what happened to Aaron? I truly wonder.

I discovered the bug yesterday, followed responsible disclosure with US CERT (based at CMU, so we got things moving very quickly there), and the bug is now fixed.

If the CFAA bars legitimate security research like this, then we would all be truly fucked.

"If the CFAA bars legitimate security research like this, then we would all be truly fucked."

You must be new here. This is why we have all been saying that the CFAA is truly fucked, for many years now :)

But yes, you did play with fire on this one. People have been convicted for far more innocent activities than this. I assume you're a student or recent grad and may be a bit optimistic about the world we are in. Don't fuck around under your real name or IP address when you do this kind of thing. "Accidentally" dropping a ' into a webform just to see what happens is one thing, but you won't be able to feign innocence with something this involved. Unless you are both the client and the server, or the other party is unambiguously inviting testing (such as a bug bounty), you have no claim to legitimate security research.

It's still awesome that you found and drew attention to this. It's important work. But, cover your ass next time, or know what you're getting into. Especially hitting obscure companies like this, who notoriously exist in a culture very unlike the typical valley-type company, where such activity makes them feel very threatened and outraged, often turning to law enforcement or initiating legal action.

Also, the term you're looking for is coordinated disclosure. Do not let the vendors define "responsibility" as they have attempted to do with the injection of that term into the lexicon ;)

CFAA probably does bar research like this; your right to test something for security flaws technically ends where someone else's server hardware begins. In reality, the optics of this vulnerability are so bad that you are vanishingly unlikely to take any legal shit for it. But be careful extrapolating from it. If you have questions about the legality of this kind of testing (and you should): consult a lawyer. Small price to pay.

It's a good find. Congrats.

Wait, yesterday? And the fix is already deployed to production today? That's either some truly impressive engineering from a company that made a freshman-year-level security mistake, or whatever patch they put in place to fix this is just as leaky as the original bugged version and it's just a matter of time.

Theory: Devops disabled the security flag on the JSON API, in order to perform integration tests, then didn't enabled it until reminded.

This for sure! My theory has also been that it's possible they literally just needed to add "if (subscriptionApproved) {" to the top. Not exactly a ton of code!

They just killed the try page entirely. It's now a redirect to the home page. Hopefully they don’t try to bring that page back up without fixing all the bugs...

Why would he, (neo), have any target from the law on his back? He wasn't sharing or selling the information. LocationSmart should be the ones getting fucked.

Under the ridiculously broad scope of the CFAA, that doesn't matter. The CFAA can be (and has been) twisted to prosecute people that do anything to a computer system that they do not own if the system owner could even remotely perceive said action as harmful. It's been used in the past to prosecute security researchers for accessing publicly available websites because the website owners claimed that they weren't "meant" to be public, they were only publicly accessible to make it easier for the actually "authorized" people to access them.

Even doing something like an nmap or a simple ping against a server that you're "not supposed to" could put a target on your back from an overzealous prosecutor.

See https://www.theguardian.com/technology/2014/may/29/us-cyberc...

If we want to be really pedantic here, didn’t LocationSmart violate the CFAA? Their system queried the location of users’ devices without their consent. Does tower triangulation count as accessing the device?

I believe the flow of info goes:


The carrier determines the location of the phone because it's a cell phone. The Carrier provides the information to LocationSmart. There's no querying of the devices by LocationSmart per se.

Telecoms, not LocationSmart, are to blame here. They made an API providing access to location information without any supervision.

Was this able to be done programmatically? Like POST a set of numbers and get back their location data.

Wonder how long this was open for any bad actors to exploit.

Yes, that's exactly what I ended up doing - I had a little script that took a phone number and spat out a Google Maps page.

Would you mind paste-binning/gist/posting the script? I'd be interested in seeing exactly how easy it was. I was playing around with the site last night but couldn't get anywhere.

I've posted a full writeup here: https://www.robertxiao.ca/hacking/locationsmart/

Was this in any way protected or did you just watch network requests in your browser, see an endpoint, and curl it? I'm not diminishing your discovery, just wondering if it was utterly trivial to use...

I modified a request in a fairly predictable way and bypassed the consent stage. See the full writeup here: https://www.robertxiao.ca/hacking/locationsmart/

Thanks for the write up!

All I can say is wow.

I was going to poke around that site yesterday after I saw the article, because looking at their website it really looked like there had to be some vulnerabilities. What you tried is exactly the kind of thing I would have looked at first.

Yep, there’s no way you’re the first to find this. Honestly I’m at a loss for words how absurd this is. We just need to assume this was actively exploited for who knows how long.

I definitely do not assume that I'm the first to find this, only the first to actually get it taken down. Worse, as the try site's been up since at least Jan 2017, that's nearly 18 months of exposure.

We won't know what the real exposure level was unless someone asks LocationSmart very persuasively.

Anybody know a EU citizen in the US who'd be prepared to request how often their data's been accessed using the GDPR regs?

I highly doubt they even know.

Ideally, they have access logs (for the web API, their backend location requests, or both) that could be used to detect patterns of misuse. Unfortunately, since their API is exclusively POST, the web server access logs will be less useful, but they could be used to detect e.g. direct API queries that skip the consent request.

Do you think your graduate degree was necessary to find this bug, or could any idiot with devtools open find it just by trying to automate the site?

Your descriptions thus far are pretty vague but man... it sounds like there is a VERY high likelihood that this was being exploited by malicious actors on an ongoing basis.

https://www.robertxiao.ca/hacking/locationsmart/ provides the technical details. In short: much more likely the latter than the former. And this /try/ page has been up at least since Jan 2017 (~18 months).

FYI to anyone downvoting this / the OP:

I didn’t mean this to be offensive or crass. I was asking because generally security exploits are ranked by (a) severity and (b) triviality. That is, a severe bug that is extremely difficult to exploit is not as alarming as a severe bug that is trivial to exploit.

When laypeople read that a CMU researcher discovered a bug, they might assume it is not trivial. So in that sense mentioning the PhD almost does a disservice to expressing the triviality of the bug.

When a high school kid in Hungary discovered he could purchase train tickets for any price by changing it client side, non-technical people could understand it was a trivial bug. When a CMU researcher discovers a bug, they likely assume the opposite.

Sorry if this is a stupid question, but do we know if this location was collected by the operating system of the mobile devices? Or was it being collected simply by data from carriers? Also since this was just an API vulnerability would I be correct to assume it's still being exploited by this companies customers?

The information is likely to be provided by an API from AT&T and others, which is obtained from cell towers.

Makes sense... Thanks. There should be a law...

There is. A law which requires carriers to provide sufficiently accurate cell phone location data so they can send it along with 911 calls.


"Phase II E911 rules require wireless service providers to provide more precise location information to PSAPs; specifically, the latitude and longitude of the caller. This information must be accurate to within 50 to 300 meters depending upon the type of location technology used."

Not the law I'm guessing you were after, huh?

Sad thing is this has been going on since the late 1990s, back then they had lower level reps at AT&T handling law enforcement location requests manually. Knowing a few of them, it took forever for those former reps to get cellphones due to a fear of being tracked, having dealt with those requests.

I've also noticed multiple in that group will purposefully leave their phone behind & drive their older cars when they choose to have a tracking free day, even 2 decades later exposure to how easy it is to pull live location data still notably impacts their behavior.

With firsthand experience of license plate scanning, they might reconsider their old cars. And who knows what they'd do if they also had firsthand experience of facial tracking cameras! Perhaps they'd invent a new cyberpunk costume, turn into night owls, or take of cave diving...

Almost certainly obtained from the carriers.

Did it work for Canadian phone numbers?

I didn't have that many Canadian numbers to test, but it worked for one number on Telus, failed on one number from Bell, and returned a cached result for another Telus customer (they were in the States, and the API returned their port of departure in Canada). This shouldn't be construed to imply that Bell phones cannot be tracked - Bell is noted to be a partner of LocationSmart, so it could entirely have been a glitch or other temporary issue.

Thanks for the response -- I just noticed another user commented a couple days ago that it worked for their Canadian phone, as well: https://news.ycombinator.com/item?id=17075833

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact