Happy to answer questions and provide any additional context.
Happy to answer questions 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.
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.
(Submitted url was https://krebsonsecurity.com/2018/05/tracking-firm-locationsm...)
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.
To me that sounds like you stumbled upon an unauthenticated development/debug mode.
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
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.
But for some reason, access control has something to do with LocationSmart's entity body serialization format... hmm, okay then.
Props for finding the vuln.
At most, hitting location smart over and over would probably just hit the carrier databases over and over.
You can strike “most likely” from your statement. Carriers definitively do this.
When I tried their own trial (before it was taken down), they were unable to locate my iPhone on AT&T.
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.
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...
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...
phone--carrier--LocationSmart.
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.
If the CFAA bars legitimate security research like this, then we would all be truly fucked.
It's a good find. Congrats.
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 ;)
Wonder how long this was open for any bad actors to exploit.
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.
We won't know what the real exposure level was unless someone asks LocationSmart very persuasively.
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.
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.
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.
https://www.fcc.gov/consumers/guides/911-wireless-services
"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?