_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI O2 VoLTE: locating any customer with a phone call
ivanvanderbyl wrote 5 hours 25 min ago:
Iâm curious to see if this exists on O2 in NZ. I switched to them
last week because they do free roaming in Australia, and VoLTE calls.
mrjeeves wrote 3 hours 59 min ago:
I doubt it. This is likely O2 UK specific.
celsoazevedo wrote 3 hours 20 min ago:
This only affects O2, not EE/VF/3, right?
kjellsbells wrote 5 hours 57 min ago:
Also very curious how the call initiator was able to see the call
control messages (ie SIP). Arent all these messages wrapped inside an
encrypted GRE tunnel between handset and cell tower (and MME)? Being
able to unpick GRE tunnel encryption would be a gigantic hole. Perhaps
this only works because the OP is running analysis on their device, but
even then I'm surprised that the pre-encryption payload is available.
mrjeeves wrote 4 hours 24 min ago:
Hello, article editor here. Many Android devices with Qualcomm chips
offer the option to expose a modem diagnostics port over USB meaning
a rooted device isn't even needed. It's just much easier to use NSG
rooted on-device than going around with a laptop places.
It's as simple as using Scat ( [1] ) with the modem diag port enabled
to view all signalling traffic to/from the network.
URI [1]: https://github.com/fgsect/scat
celsoazevedo wrote 4 hours 50 min ago:
They're using a rooted Android phone and an app called Network Signal
Guru: [1] At least the free version of the app doesn't seem to
"decrypt" anything, but it has root access and access to the modem,
so it can read these logs. It can also disable bands and try to lock
to a specific mast (like dedicated 4G/5G routers can), which is
useful if you're trying to use mobile data as your main internet
connection.
URI [1]: https://play.google.com/store/apps/details?id=com.qtrun.Quic...
immibis wrote 4 hours 45 min ago:
Right, so, that's the hacking tool they'll soon get prosecuted for
using, while the problem will remain unfixed.
tguvot wrote 5 hours 17 min ago:
i think you meant GTP tunnel. And GTP tunnel is between enodeb and
core network. it's secured only in case that it run inside IPSEC.
cloudref wrote 6 hours 25 min ago:
Could you mitigate this by turning off VoLTE? I can see docs online for
turning it off on an iPhone 11 - but my iPhone 15 doesn't have that
option!
mdasen wrote 6 hours 0 min ago:
> Disabling 4G Calling does not prevent these headers from being
revealed, and if your device is ever unreachable these internal
headers will still reveal the last cell you were connected to and how
long ago this was.
So it seems like that won't do anything.
usr1106 wrote 6 hours 50 min ago:
According to GDPR this is clearly illegal. I am pretty sure their
subscriber contracts don't contain consent for sharing your location to
any caller.
Now UK has left the EU so GDPR does no longer apply. But it is my
understanding they have not changed any fundamental principles in
whatever applies now?
palm-tree wrote 6 hours 41 min ago:
I'm no expert, but I'm fairly sure that UK GDPR applies, which is
effectively the same as the EU version
URI [1]: https://ico.org.uk/for-organisations/data-protection-and-the...
ajb wrote 4 hours 57 min ago:
Yes, it still exists. Most (all?) EU legislation that ended had to
be explicitly revoked, since the UK was fairly diligent in
transposing it to national legislation.
andix wrote 7 hours 22 min ago:
The really interesting part of this issue is, that under most
jurisdictions it probably won't even qualify as hacking. The data is
sent out by the network voluntarily and during normal use.
There are no systems at any point tricked into revealing personal data,
which is often illegal, even if the hack is trivial. Even appending
something like "&reveal_privat_data=true" to an URL might be considered
illegal, because there is clear intent to access data you shouldn't be
allowed to access. In this case none of that is done.
immibis wrote 4 hours 46 min ago:
It is, however, a data breach, triggering the requirement for them to
report it to the regulator immediately or get fined, etc etc (if such
rules exist in the UK)
18172828286177 wrote 5 hours 32 min ago:
> The really interesting part of this issue is, that under most
jurisdictions it probably won't even qualify as hacking
You clearly arenât familiar with how broad the Computer Misuse Act
is
andix wrote 5 hours 8 min ago:
> You clearly arenât familiar with how broad the Computer Misuse
Act is
No, I'm not familiar with it at all. But usually illegal hacking
requires to access devices in a way you aren't allowed to access.
As long as making the phone call itself is not an issue, it should
be fine. Dumping data from the memory of your phone can't be
unauthorized.
It would probably become an issue if you make unusual phone calls,
harassing people with constantly calling, or calling just for the
purpose of getting the location data and immediately hanging up.
But just dumping the diagnostics for regular phone calls should be
fine (I'm not a lawyer).
watusername wrote 4 hours 52 min ago:
> Dumping data from the memory of your phone can't be
unauthorized.
> just dumping the diagnostics for regular phone calls should be
fine
IANAL, but computer hacking laws like the CMA in the UK and CFAA
in the US are written in a manner so vague that even pressing F12
to view the source of a web page could be a violation [0]. From
O2's perspective, they could argue that the OP has accessed their
internal diagnostic data in an unauthorized manner. What we
(technical people) think is irrelevant.
[0]: In the US, the DOJ has revised its policy to not prosecute
defendants pursuing "good faith security research," which you may
trust at your own risk:
URI [1]: https://www.justice.gov/archives/opa/pr/department-justi...
mrjeeves wrote 3 hours 31 min ago:
It's tough, but when the people don't respond what do you do?
Do you just sit on the info, hoping noone else sees it and
exploits it?
Or do you try and get them to fix it somehow?
watusername wrote 1 hour 59 min ago:
First of all, thank you for trying to resolve this with the
carrier and finally bringing it up to everyone's attention
here. Perhaps public attention is what's needed to push them
to address the problem.
To be honest, I personally would be scared to report such
vulnerabilities with my real identity to begin with. With big
tech companies, no matter how poorly their bug bounty
programs are run, I still have this naive expectation that
they won't shoot the messenger. At worst they could ban my
accounts and maybe send threatening letters, but they
probably won't ruin my life as long as I abide by the norms
(agreed by technical people).
However, I do not feel the same naive optimism towards
"legacy" institutions like telecoms and public services. At
best it's thankless work, at worst I get sued [0] or become a
scapegoat so some official could score some political points
[1]. It's unfortunate - I am acutely aware that this is
chilling effect at work, and our systems are collectively
less secure because of it.
[0]: [1]:
URI [1]: https://www.cnbc.com/2024/09/15/dark-web-expert-warn...
URI [2]: https://techcrunch.com/2021/10/15/f12-isnt-hacking-m...
andix wrote 4 hours 23 min ago:
I don't have a lot of knowledge about US and UK law, but I hear
a lot of bad things.
"good faith security research" is a different ballpark though.
Some laws catch all unauthorized access, even if the intent is
not in a bad faith (which is probably a very bad idea, but
that's how it is). But it also makes sense to some point: if
your neighbor has a really bad lock that can be opened just by
hitting the door frame a few times, you're also not allowed to
break in just to disclose their bad security.
Usually some deliberate action needs to be taken that qualifies
as unauthorized access. Something like adding a malformed
header to a HTTP request could be enough. Or logging in with
credentials that are clearly not yours (even if it's just
admin/admin). But logging the traffic of regular and authorized
usage patterns shouldn't be enough.
celsoazevedo wrote 7 hours 34 min ago:
Seems to be a serious problem. It's not that hard to root a phone,
install NSG, and look at this info. O2 is also the largest mobile
network in the UK and they have contracts with the government...
It's disappointing that they didn't reply, but I'm not surprised. O2
seems to be a mess internally. Anything that can't be fixed by someone
at a store takes ages to fix (eg: a bad number port). Their systems
seem to be outdated, part of their user base still can't use VoLTE,
their new 5G SA doesn't support voice and seems to over rely on n28
making it slow for many, their CTO blogs about leaving "vanity metrics
behind"[0] even though they are usually the worst network for data,
etc.
[0]
URI [1]: https://news.virginmediao2.co.uk/leaving-the-vanity-metrics-be...
edude03 wrote 7 hours 55 min ago:
I donât know anything about IMS but I assume they have to stay on the
call long enough for the debug headers to be sent (like the tracing the
call thing in every spy movie but real) and if thatâs the case can
this be mitigated by âjustâ* not answering calls from unknown
numbers?
*yes Iâm aware that means people you know who have your number could
also exploit this
andix wrote 7 hours 6 min ago:
I guess this information is already known to the network before the
connection is even established. Those seem to be debugging headers,
you probably need them for cases where the connection can't be
established properly to debug why. If I understand the article
correctly, the information is even there if the receiving phone is
turned off, then you get the last known cell.
dilyevsky wrote 7 hours 45 min ago:
IMS is just SIP core + bunch of gateways + integration with base LTE
infra (eNodeB, PCRF, etc) so "signaling messages" are just SIP
messages. So depending on whether those compromising headers were
included on things like SIP 180 Ringing messages and such it may not
be enough to not answer the calls. Source: actually worked on
deploying IMS at a telco (not this one)
mrjeeves wrote 3 hours 54 min ago:
The headers are included in every single downlink message after
initiating a call, including the downlink SIP Invite message before
100 Trying, 180 Ringing or 183 Session Progress.
If you're quick enough (or automate this with dedicated software,
like an attacker might actually do), it won't even need to ring
out. It's really not good.
edent wrote 8 hours 35 min ago:
O2 used to have a responsible disclosure address - but they removed it
a few years back.
When I worked there (many years ago) the security team was excellent.
When I emaileld them about an issue last year, they were all gone.
mrjeeves wrote 4 hours 23 min ago:
We know the relevant team within O2 was actually informed, but
evidently no action (or insufficient action) was taken.
lol768 wrote 14 hours 39 min ago:
> Attempts were made to reach out to O2 via email (to both Lutz
Schüler, CEO and securityincidents@virginmedia.co.uk) on the 26 and 27
March 2025 reporting this behaviour and privacy risk, but I have yet to
get any response or see any change in the behaviour.
This is really poor. And why is a Virgin Media address the closest best
thing here? [1] should 200, not 404.
To be clear, I have no problem with disclosure in these circumstances
given the inaction, but I'm left wondering if this is the sort of thing
that NCSC would pick up under some circumstances (and may have better
luck communicating with the org)?
URI [1]: https://www.o2.co.uk/.well-known/security.txt
mrjeeves wrote 4 hours 19 min ago:
This one is actually on us. The email contacted was actually
@virginmediao2.co.uk, not @virginmedia.co.uk. It's a typo in the
article.
I'll update it with a correction.
Mr_Minderbinder wrote 55 min ago:
I have spotted another error:
> is within LAC 0x1003 (decimal: 4009)
It should be decimal 4099.
DIR <- back to front page