8 ms·

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 quest

• bhaile 8y ago
  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.
  • nneonneo 8y ago
    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.
    • cazum 8y ago
      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.
      • nneonneo 8y ago
        I've posted a full writeup here: https://www.robertxiao.ca/hacking/locationsmart/ https://www.robertxiao.ca/hacking/locationsmart/
    • x0x0 8y ago
      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...
      • nneonneo 8y ago
        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/ https://www.robertxiao.ca/hacking/locationsmart/
        • chatmasta 8y ago
          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.
          • nneonneo 8y ago
            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.
            • chatmasta 8y ago
              I highly doubt they even know.
              • nneonneo 8y ago
                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.
            • bigiain 8y ago
  • chatmasta 8y ago
    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.
    • nneonneo 8y ago
      https://www.robertxiao.ca/hacking/locationsmart/ 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).
    • chatmasta 8y ago
      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.
• Sephr 8y ago
  > 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.
  • nneonneo 8y ago
    Thanks! I just finished the writeup, posted here: https://www.robertxiao.ca/hacking/locationsmart/ 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.
    • Sephr 8y ago
      Thanks, your write-up is very informative! I think the HN staff should change the URL to your post.
      • deleted 8y ago
        [deleted]
      • dang 8y ago
        Changed. Thanks for emailing us! We wouldn't have seen this otherwise. (Submitted url was https://krebsonsecurity.com/2018/05/tracking-firm-locationsmart-leaked-location-data-for-customers-of-all-major-u-s-mobile-carriers-in-real-time-via-its-web-site/. https://krebsonsecurity.com/2018/05/tracking-firm-locationsm...)
      • deleted 8y ago
        [deleted]
• kotajacob 8y ago
  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?
  • kevcampb 8y ago
    The information is likely to be provided by an API from AT&T and others, which is obtained from cell towers.
    • kotajacob 8y ago
      Makes sense... Thanks. There should be a law...
      • StudentStuff 8y ago
        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.
        • saltcured 8y ago
          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...
      • bigiain 8y ago
        There is. A law which requires carriers to provide sufficiently accurate cell phone location data so they can send it along with 911 calls. https://www.fcc.gov/consumers/guides/911-wireless-services 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?
• chx 8y ago
  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.
  • bendd 8y ago
    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.
    • txcwpalpha 8y ago
      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-cybercrime-laws-security-researchers https://www.theguardian.com/technology/2014/may/29/us-cyberc...
      • chatmasta 8y ago
        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?
        • roywiggins 8y ago
          I believe the flow of info goes: 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.
• netsec_burn 8y ago
  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.
  • privacypoller 8y ago
    from https://www.locationsmart.com/platform/privacy 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
    • dsl 8y ago
      > 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.
    • sk5t 8y ago
      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.
• howard941 8y ago
  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.
  • nneonneo 8y ago
    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.
    • jjeaff 8y ago
      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.
      • jsjohnst 8y ago
        > 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.
• spdustin 8y ago
  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.
  • nneonneo 8y ago
    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.
    • StudentStuff 8y ago
      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.
      • jsjohnst 8y ago
        > 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.
      • bigiain 8y ago
        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...)
• perryh2 8y ago
  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.
  • nneonneo 8y ago
    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.
    • ironjunkie 8y ago
      I'm impressed by the amount of good guesses you had to get there. Good job!
• collinmanderson 8y ago
  I appreciate that you used Python 3 instead of 2 :)
• amatecha 8y ago
  Did it work for Canadian phone numbers?
  • nneonneo 8y ago
    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.
    • amatecha 8y ago
      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 https://news.ycombinator.com/item?id=17075833