
Abusing WebRTC to reveal coarse location data in Signal - geeklord
https://medium.com/tenable-techblog/turning-signal-app-into-a-coarse-tracking-device-643eb4298447
======
DrPhish
The only universal fix I can think of for this class of attacks is to have
routers bound latency to a lower limit (eg. 200ms), with fixed latency buckets
(eg. 500ms granularity) when it goes beyond that.

That is, no traffic would traverse the router in less than 200ms, and every
other flow would be fixed at 700ms, 1200ms, 1700ms, etc amounts of latency.
Tweaked correctly that would limit location to continent, unless I'm missing
something.

It would effectively trade quick responses to/from close networks for some
extra amount of privacy (in the case that GeoIP has already been taken care
of)

The latency would have to be controlled on both ingress and egress to account
for internal and external threats. I've got a niggling feeling that an
attacker that could control latency of enough geographically diverse networks
could find the boundary by manipulating responses to get finer detail, but
can't quite work the problem into a solution...

Is there a less horrible or more reliable universal mitigation that I'm not
thinking of?

~~~
jrockway
To some extent, this already happens. My cable modem adds about 30ms latency
no matter the destination. I think this is a combination of buffer bloat (wait
for buffer to fill before talking on the network) and waiting for a transmit
time slot (shared access to the physical layer). I haven't looked at it in
detail, but it is very surprising to me that I get 60ms RTT to Blizzard's
servers in Chicago (a speed of light distance of 4ms one way) and 25-40ms ping
to Google (in what they call "lga15", which is somewhere in Manahttan,
probably 60 Hudson).

I realize that ping is a very poor benchmark as most routers do not handle
ping in their fast path, but it's not adding 40ms of latency. So I suspect my
modem.

~~~
dannyw
This is extremely unusual to me. Personally I notice it when my ping to local
game servers go from 5 to 25.

I’d recommended you look into it, and potentially get another modem. If all my
requests started taking another 30ms, I’d consider my network degraded.

~~~
jrockway
Seems like everyone with any cable ISP has this problem. It could be a modem
problem, but it's happened with a variety of modems. It could be an ISP
problem, but both Comcast and Spectrum users see the same thing in my
experience.

I'd be interested in hearing counterexamples, but I imagine that people with
good experiences are on DSL or Fiber.

~~~
zrm
I can ping 1.1.1.1 right now at 12-15ms, or Google at around 20ms, via
Comcast. Less than 10ms to either one on Optimum. But it's 25-30ms to ping
Optimum from Comcast.

------
verdverm
I recall seeing a paper where they showed how close you can geolocate with
various numbers of peers to the target, by using network latency alone

~~~
stagas
That's funny, I was just working on a POC like this today[0] - it's accurate
most of the time for my location but I haven't tested from other locations.
You'd need to tweak the 'known' servers on and off to find the optimal
arrangement because you'd need to be somehow inside the polygon. I was
planning to find a way to discover these itself and other tweaks (like trying
multiple times then averaging out)

Edit: the paper I found related to this is here[1]

[0]: [https://github.com/stagas/http-
geolocate](https://github.com/stagas/http-geolocate)

[1]:
[https://homes.cs.washington.edu/~tom/support/geoloc.pdf](https://homes.cs.washington.edu/~tom/support/geoloc.pdf)

~~~
RL_Quine
[https://vercel.com/edge-network](https://vercel.com/edge-network)

This page contains websocket addresses of a CDN that returns ping pong from a
huge number of locations. It works surprisingly well for working out very fine
grain location in just playing with it.

~~~
stagas
Oh wow, they're actually doing the same thing, triangulating on latency. Hive
mind, I guess. I used universities because I figured a)they won't mind, and
b)they're more likely to have their servers on premises, then used a public
reverse geoip to get their locations. I'll try to see if I can integrate with
Vercel's edge network, seems more ideal.

Edit: no, I misunderstood, the location dot that's being displayed isn't the
product of triangulation, they're just doing reverse geoip lookup. So, I
wonder now if the edge network would perform better.

Update: it doesn't perform better. Either there is some kind of proxy
redirecting their traffic or these servers aren't where they say they are, the
center is skewed out completely. The universities win so far being correct and
accurate most of the time.

~~~
LargoLasskhyfv
Unimpressed with yours. Why? Because my ISP got some IPv4 space recently,
which was formerly allocated to .ua, .ru, .iq, & .ir. While being physically
next to or in Hamburg, .de. That led to all sorts of inconveniences for some
people, suddenly barred from logging on, or using the sites they frequent,
because they used outdated geo-ip data. I didn't even notice, except for the
outrage in their customer forum.

Now yours consistently puts me somewhere into, or onto the shores of the Black
Sea, while Vercels doesn't. So that makes me suspicious of your claim by using
latency alone.

Edit: There seems to be outdated geo-ip information factored in somewhere. Why
else it would put me IN the Black Sea?

~~~
stagas
I mentioned I just started working on it. To try for yourself you'd need to
clone and tweak the servers list to find an optimal arrangement for you. The
problem as I see it is that jumping continents occurs really artificial delays
which skews the result significantly, so it first needs to identify your
relative whereabouts, then decide on an optimal set of servers. If you clone
and tweak the servers to place yourself inside the polygon you'd see it does
locate you. Vercel is doing a reverse geoip lookup, so your location is
preconfigured in some database based on your ip.

~~~
LargoLasskhyfv
At least they are current ;-)

~~~
gregoryl
I hope you can come back in a day or so, and re-read this conversation. You're
not being very nice, or fair, and it doesn't portray you in a good light.

~~~
LargoLasskhyfv
I probably will. It may have come across harsh, but wasn't intended as such.
IMO i outlined the reasons why sufficiently in my post and edit.

~~~
stagas
Maybe you misunderstood what the tool is doing. It is not doing geoip, it is
using the latency of pings between your client and some selected servers with
known locations, then calculates the center based on those timings and these
known locations. Very simple, you can look at the code and see what it's
doing. It's not factoring in any kind of real latency, such as the speed of
light, hop delays, etc. Unfortunately, as others pointed out, this method
works poorly, especially in such long distances. In my tests you can only find
a certain window that performs well for your location, still within a radius
of hundreds or thousands of kms, which makes it pretty unusable as you point
out. Knowing what _doesn't_ work is also valuable information.

~~~
LargoLasskhyfv
I understood that. Let me replay it from my mind, how i percieved it. There is
the dark map with white contours. And yellow points on it, which represent the
triangualiton servers, i guess? Even clickable, at least the RED point which
represents _my_ assumed location sometimes moved. Most notably when i clicked
on London, then it hopped to Odessa. Otherwise, it was mostly in the northeast
region of the Black Sea. In the light of the recent IPv4-space acquisition of
my ISP, which i wrote about containing addresses formerly used in the Ukraine,
Russia, Irak and Iran, causing "funny" issues...what would _you_ have thought?

~~~
LargoLasskhyfv
edit: btw. tested in latest Firefox with uBlock Origin on/off. and Iridium
Browser (Chromium derivative), retested in Iridium only after 24h dyn-ip
renewal. Same results.

Anyways, time to sleep. Sun's getting too bright.

------
kodablah
I can see where a FQDN candidate is no biggie in a browser's offer/answer
since DNS lookups occur all the time. But I imagine the simple fix for
Signal's WebRTC use, since they control both sides of the exchange, is to just
disregard non-IP candidates. Or even better, don't do anything with the
candidates until the call is accepted. Worst case, could just have a
geographically centralized signaling server (or shared IP). Granted, since
Signal controls both sides, might as well only serve fixed "host" candidates
and disallow any offer/answer with custom crafted ones.

One also wonders, to prevent other forms of leaks, if Signal can make a
blanket policy to prevent DNS lookups or in general get tighter control on
outbound network.

~~~
pthatcherg
Disregarding non-IP candidates is exactly what we've chosen to do (and which
the new versions of the app do).

The downside of disregarding all candidates until the call is accepted is that
post-accept connectivity would be much slower.

Going through a server to hide your IP is an option in the settings in the
app, but it can potentially lead to higher call latency, so there is a trade-
off.

To prevent issues like this in the future we are taking more control of
WebRTC's behavior with a fork of WebRTC (Signal uses WebRTC) and are providing
patches to upstream WebRTC as well.

(I work at Signal on calling)

~~~
billme
>> “ PINs will also help facilitate new features like addressing that isn’t
based exclusively on phone numbers, since the system address book will no
longer be a viable way to maintain your network of contacts.” [1]

Any idea when more information might be available on this? Asked moxie years
ago to add this and know 100s of other have too.

Worth noting the FAQ as it relates to the PIN length is not correct, “How long
can my PIN be? There is no limit. Feel free to add as many characters as you
want.” [2] ...tested it and longest PIN I was able to create was 20 characters
all numeric.

[1]: [https://signal.org/blog/signal-pins/](https://signal.org/blog/signal-
pins/)

[2] [https://support.signal.org/hc/en-
us/articles/360007059792-Si...](https://support.signal.org/hc/en-
us/articles/360007059792-Signal-PINs)

------
floatboth
> if a Signal user wishes to hide their private/public IP addresses even from
> contacts who call, then it has an option “Always Relay Calls” in its privacy
> options

I thought Signal was all about privacy _by default_? :D

Signal fans love to dunk on Telegram for secret chats not being the only kind
of chat.. well turns out on Signal, private is not the only kind of call, and
your IP address is exposed by default.

~~~
dancemethis
Signal fans like to selectively forget that the server-side is proprietary
software - therefore, the whole platform can't quite be proven to be reliable.

Essentially, they are not much better than Whatsapp stans.

~~~
lorenzhs
That’s hilariously wrong, the server source code is at
[https://github.com/signalapp/Signal-
Server](https://github.com/signalapp/Signal-Server). How can you make such a
claim in good faith when it’s so absolutely trivial to refute?

------
upofadown
>Even Edward Snowden, the well known American Whistleblower, claims “I use
Signal every day.”

Well, 5 years ago...

~~~
cjbprime
Presumably he's been using Signal over Tor, defeating all such attacks as a
side-effect.

~~~
aesh2Xa1
How does Edward Snowden acquire a laptop or phone in a way that he can trust
it? I don't think it matters what protocols and applications he uses: he does
not enjoy privacy.

~~~
sadfklsjlkjwt
I order to get a device that is not explicitly compromised with custom
targeted malware one could: take a walk, enter a random shop, buy a device.
Now you only have the standard malware that everyone gets preinstalled on
their devices.

How to keep it free of custom targeted malware? That is another question!

~~~
Mediterraneo10
With a target like Snowden who is under constant surveillance and lives at the
whim of his host country, he could expect that any off the shelf hardware he
bought would be immediately compromised. His hosts would just make up some
bullshit reason to part him from the device for several minutes and do an evil
maid attack. Or from afar his hosts or another country's actors could exploit
undisclosed vulnerabilities in his device's wifi or bluetooth layer that they
have in their toolkit.

~~~
sadfklsjlkjwt
I agree I cover that in my OP.

------
dep_b
WebRTC and signaling can be an interesting attack vector. If rooms are not
protected technically from uninvited people to enter you can get all kinds of
information but even worse you can sometimes even hijack a call.

------
sneak
[https://archive.is/SYq8H](https://archive.is/SYq8H)

I got a blank page on the original domain, perhaps due to DNS adblocking.

------
extropy
You already have the peers IP address for p2p call right? How is this better
than that?

~~~
meowface
According to the article, by default Signal will relay all calls from people
who aren't contacts. This means if a non-contact calls you or vice versa, they
can't see your IP address and you can't see theirs, even if the call is
accepted and you're both talking. They also provide an option to enable
relaying calls to/from contacts, so that contacts won't see your IP address,
either.

Here, regardless of if you have that setting enabled or not, and regardless of
if you accept the call, contacts and non-contacts can cause your device to
make a DNS request, which will leak your DNS server. And if using a DNS server
with EDNS Client Subnets, the first 3 octets of your IP address will also be
leaked.

I think there's another issue like what you're describing which can kind of
obviate this, though: the vast majority of Signal users probably use Signal on
their regular mobile phone and its number, not a burner phone/SIM/number. (Few
users probably even own a burner phone/SIM/number or understand what that is
or why they might want one or how they'd obtain one.) So... everyone can just
see your phone number, which probably has an area code corresponding to your
city or close to it, and the other digits can possibly pinpoint it even more
precisely than that.

Anyone who isn't tunneling all of their DNS traffic with a VPN or otherwise
probably also isn't anonymizing their phone number and just has the app
installed on their personal, standard cell phone.

If they aren't traveling and haven't moved recently, you can probably see what
city they're in just from that. (This exposure does allow coarse location
detection even when someone's traveling, though it's a lot more coarse than
the area code, unless the Client Subnet value is being sent.)

