Remix.run Logo
Bad Connection: Global telecom exploitation by covert surveillance actors(citizenlab.ca)
104 points by miohtama 11 hours ago | 7 comments

https://www.haaretz.com/israel-news/security-aviation/2026-0... (https://archive.ph/0QYbN)

kevin_nisbet 3 hours ago | parent | next [-]

This was a fairly interesting read, but some of the claims struck me as fairly circumstantial. I ended up almost writing a novel of a comment, but will try and save everyone from that by summarizing.

I started my career in Wireless Telecom, and some of my work was directly on Diameter Routing and working with roaming partners on technical problems.

The SIM card stuff I have no expertise on, so I won't comment on that.

There are a couple of important things to note which I think the report misses.

The first is what a cellular network does for tracking a user. It's not returning a set of GPS coordinates. A cellular network has a problem to solve, which is on which radios do we transmit that the device should wake up from idle about an incoming call (or SMS or packet). We could not track this at all, and then the entire bandwidth is spent notifying the entire country about every call. On the other side we could track this down to every radio, but then you have the problem of your entire network is just signaling traffic about changes in the best radio to reach a device. A tree swaying in the wind causes constant updates type of idea.

So we break the network up into areas, and if the device moves and see's a beacon from a tower that it's in a new area, it tells the network to update it's location records. There is a slightly more precise record which is the Cell ID, but the device doesn't need to keep it up to date. So in the report when you see the references to the Cell ID/E-UTRAN Global Cell Identity, and LAC/TAI this is the concept those identifier tie to.

There are databases that can map the Cell identities to GPS locations, and you can think of that as the assignment to the tower, although there are some deviations that occur (remote locations for a radio, etc). So most often you're not getting the GPS location of the device, you're getting the tower. This is still a privacy implication, and get's more precise over time as the radio networks get more and more dense to support higher speeds. But still might be dozens of KMs away from the actual device location.

I ended up writing a novel, but need to cut it down. So a bunch of the evidence cited on the Diameter protocol and DNS behaviour on GPRs DNS I don't think is as strong as one might conclude when reading the report.

What particular struck me was the DNS NXDomain as an indicator of trade craft to conceal the source, that they refer to several times. To me this is an expected behaviour on roaming DNS if the source network used to make the query does not have a roaming agreement with the other provider. The DNS specifications by the GSMA are a bit awkward, and I've been bitten by them several times, but they don't carry the same DNS related expectations as you would expect on the internet. On the open internet, you expect to see a delegation from com to ycombinator, and to be able to follow that to ycombinator. This isn't the case on the roaming exchange networks, firewalls and answers are only opened up when there is an agreement. So if this provider is a small fry, there might not be many agreements in place, and it's not weird to get back an NXDomain or timeout. This does depend on whether it was the roots or the provider certs that provided the response that they don't go into detail.

Some of the Diameter related statements also struck me as not having a complete understanding of the technology, and suggesting a direct link to trade craft. Things like the Origin-Host and Route-Record 1 being the same, while perhaps a technical violation of the standard, have no impact, and can just as easily be explained by a network operator not wanting to advertise internal details to the rest of the world. Similar, with the IPX provider not detecting the mis-match between realm and host, I'm not even sure that's expected or how they would do it, although from an analysis perspective it is a clear screw up from the adversary that revealed it. But I don't remember sufficient information getting exchanged between providers that would actually allow an enforcement over those fields, but I could be wrong. Also keep in mind, it wasn't just the roaming exchange that didn't enforce it, all the networks also failed to enforce it. And now the adversary might just see this report and fix their bug, so it's not like that enforcement would've completely changed the situation. But they do have a point that if enforced, it might've been detectable earlier that there was a bad actor present.

There are also alternative and resonable explanations for some of the other claims, like was 019Mobile the one actually relaying the messages, or was the second hop tricked into accepting messages, and the adversary was just impersonating 019Mobile. That shifts things around a bit, they talk at length about 019Mobile being the source of these messages, but while likely, there are other plausible explanations for the origins of those messages.

There are also some technical details they got wrong, but probably not in material ways.

So it's an interesting report, it seems like there is a real operation going on, just that I take issue with much of the evidence cited that I think many readers may draw a strong conclusion from then they should.

macintux 3 hours ago | parent [-]

If that’s the short version, you should really write up a blog post.

neonate 8 hours ago | parent | prev | next [-]

https://archive.ph/0QYbN

9cb14c1ec0 6 hours ago | parent | prev | next [-]

Very interesting. Not Diameter and SS& many experts out there.

fmajid 5 hours ago | parent | prev | next [-]

You can’t really call it an exploit when SS7 and its layered protocols like MAP have basically zero security measures whatsoever.

chatmasta 8 hours ago | parent | prev [-]

Article is ad-walled and is blogspam of the original source from Citizen Lab: https://citizenlab.ca/research/uncovering-global-telecom-exp...

dang 8 hours ago | parent [-]

Yes, I just changed the URL from https://www.haaretz.com/israel-news/security-aviation/2026-0... to the report it references. We'll leave the link to the submitted URL in the toptext.