[HN Gopher] Freaky Leaky SMS: Extracting user locations by analy...
___________________________________________________________________
Freaky Leaky SMS: Extracting user locations by analyzing SMS
timings
Author : belter
Score : 113 points
Date : 2023-06-14 16:21 UTC (6 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| belter wrote:
| "...The core idea is that receiving an SMS inevitably generates
| Delivery Reports whose reception bestows a timing attack vector
| at the sender. We conducted experiments across various countries,
| operators, and devices to show that an attacker can deduce the
| location of an SMS recipient by analyzing timing measurements
| from typical receiver locations. Our results show that, after
| training an ML model, the SMS sender can accurately determine
| multiple locations of the recipient. For example, our model
| achieves up to 96% accuracy for locations across different
| countries, and 86% for two locations within Belgium. Due to the
| way cellular networks are designed, it is difficult to prevent
| Delivery Reports from being returned to the originator making it
| challenging to thwart this covert attack without making
| fundamental changes to the network architecture..."
| toast0 wrote:
| > "Due to the way cellular networks are designed, it is
| difficult to prevent Delivery Reports from being returned to
| the originator making it challenging to thwart this covert
| attack without making fundamental changes to the network
| architecture..."
|
| As a high volume SMS sender in a previous job, I can say this
| is pretty untrue. Plenty of carriers or intermediaries would
| block or spoof delivery reports.
|
| I found that requesting delivery reports tended to increase
| actual delivery, but receiving a delivery report didn't provide
| any meaningful indication of receipt and lack of receiving a
| delivery report similarly didn't provide meaningful
| information.
| paddw wrote:
| > Due to the way cellular networks are designed, it is
| difficult to prevent Delivery Reports from being returned to
| the originator making it challenging to thwart this covert
| attack without making fundamental changes to the network
| architecture
|
| Couldn't you just add a delay from the device?
| Gh0stRAT wrote:
| That would make it harder by increasing the noise, but the
| signal is still there.
|
| Unless the receiving (target) phone knows the location of
| each of the senders, it won't be able to vary the delays in a
| way that perfectly cancels out the signal. The only hope is
| to raise the noise floor enough that it would take an
| impractical number of texts to find the phone's location,
| which should definitely be possible with random delays.
| AlexAndScripts wrote:
| Surely you could set a base value (say 1s) and wait to meet
| that? Then introduce a few hundred ms of variance either
| way.
| wongarsu wrote:
| What the attack is measuring is basically the
| transmission delay to the device and back. The device (or
| the mobile network operator) doesn't know that delay, so
| they can't cancel it out. If you add a constant wait time
| you only accomplish something if the attacker doesn't
| know about that, otherwise they simply subtract that. And
| random variance just makes the measurement noisier, send
| enough SMS and the noise averages out.
| jtriangle wrote:
| Or just turn off read receipts, problem solved.
| mdasen wrote:
| These aren't read receipts, they're delivery reports from
| the network (not your device) that you can't control.
| From the paper: It works by leveraging
| SMS Delivery Reports, which are transmitted back to the
| sender when the network delivers the SMS to the
| recipient. The sender can request these reports, and
| there is no way for the recipient to prevent them.
| russdill wrote:
| So setup a gateway that redelivers SMS messages,
| preferably though some other protocol. The gateway of
| course sets up another possiblity for exploitation.
| KirillPanov wrote:
| > Couldn't you just add a delay from the device?
|
| Cellular baseband software is ultra-closed-source. So no, you
| can't.
| dheera wrote:
| Just don't give your cell number to people. I use a virtual
| number for almost everything.
|
| "I don't have a mobile phone and the law doesn't require me
| to have one"
|
| Or have 1 cell phone line that you give out as your number,
| set it up with an app to auto-forward SMS to an e-mail
| address and calls your actual cell phone, and put that
| phone in a locked garage in the middle of Iowa.
| tuckerpo wrote:
| Is there an updated upstream git link? The one linked in the
| paper 404s.
| jh00ker wrote:
| TIL about SMS Delivery Reports and I Googled to learn how to
| enable them in the native SMS messaging app on my mobile device!
|
| I didn't have time to read the whole doc. Did it say how many SMS
| Delivery Reports were needed to create the model? I saw this "We
| repeated the classification for every combination of locations in
| our dataset, with sample sizes varying from 100 to 500"
|
| I think getting 100 messages from a (series of) unknown number(s)
| would be alarming, but after reading this, I now know that it's a
| sign that I need to ... get a new burner phone and increase the
| size of my security detail? :^)
| jethro_tell wrote:
| I believe they were silent messages though so I'm not sure
| you'd notice.
| bornfreddy wrote:
| If something can send silent messages, it can probably send
| my gps location just as easily.
| toast0 wrote:
| If your phone receives a message with certain data fields
| properly set, the message will be discarded without
| becoming visible to the user, or the user visible
| indication may not be obvious (sending a SMS to indicate
| there are / are not voicemails). If the sender had
| requested a delivery report and the carrier (and all
| intermediaries) forwards the message with the delivery
| report request intact, and the device sends a delivery
| report in response, and the carrier forwards the delivery
| report back to the original sender, the sender may be able
| to infer something from when they receive the delivery
| report.
| guube wrote:
| This is a feature the Netherlands police actually uses to
| track phone locations. It's possible to send a "silent
| sms" to a handset and by doing so you can discover where
| the receiving handset is located. This is undetectable by
| the user of the handset unless they use a rooted device
| and monitor all incoming sms payloads.
| hunter2_ wrote:
| I'm kind of surprised that rooting the device allows the
| user of the device to become aware. It seems like the
| sort of thing that the baseband layer would handle
| without passing anything at all to the main OS. At least
| for the messages designed for stealth. Obviously the
| messages meant to influence the UI (like voicemail
| status) need to make their way to the OS.
| wongarsu wrote:
| I assume from the point of view of the baseband processor
| these are all messages meant to influence the UI, and the
| silent messages sent by police are an "abuse" of the
| feature
| croes wrote:
| The silent message is sent to your device not from your
| device
|
| https://en.m.wikipedia.org/wiki/SMS#Silent_SMS
| sudobash1 wrote:
| I didn't know about Delivery Reports either. Does anyone know
| why they are not enabled by default (at least with the Google
| Messages app on Android)?
| callalex wrote:
| Because they are extremely unreliable and behave in bizarre
| and unexpected ways. Phone carriers do all kinds of broken
| and lazy stuff if they think they can get away with it
| without their subscribers noticing. Source: I used to work at
| Twilio, we sent a lot of text messages.
| hunter2_ wrote:
| Other comments suggest that these have nothing to do with
| settings you find in the app. If so, then my best guess is
| that a setting in your app by the name "delivery report" is
| actually just mislabeling some other thing such as "read
| receipts"...
| anonu wrote:
| Here's some more info on SMS DLRs which this exploit relies on:
| https://confluence.modicagroup.com/display/SC/Mobile+Deliver...
| zbuf wrote:
| I can call the phone and tell which country you're in
| fasteo wrote:
| _Additionally, we assume the attacker can collect measurements
| from locations of interest directly from the victim when located
| at specific locations /areas of interest (without revealing the
| attack) or deploy similar devices and connections as the victim
| at these locations for data collection_
|
| _In the Preparation phase, the adversary repeatedly sends
| multiple (silent) SMS, with Delivery Reports enabled, to the
| victim while observing their respective locations._
|
| This is a cool paper, but hard to actually implement it
| belter wrote:
| "A step by step guide to Silent SMS Attacks and Security" (2021)
| - https://www.firstpoint-mg.com/blog/step-by-step-silent-sms-a...
|
| https://firstpoint911.wpenginepowered.com/wp-content/uploads...
| knodi wrote:
| hmmm what about traffic congestion on SMSC and inter-carrier
| connection congestion latency?
| kornhole wrote:
| This is another reason to only use SIM cards for data. VOIP seems
| to eliminate this possibility since the message is going to a
| server that a device must retrieve.
| russdill wrote:
| Pretty sure the problem would be far worse with VoIP. You're
| now getting several packets per second to measure.
| kornhole wrote:
| First the message goes to the server. Then it must wait for
| my client to pick it up which is not instantly. I cannot see
| how my location could be measured by picking up a message
| from a server.
| russdill wrote:
| VoIP is voice. It's a realtime low latency point to point
| protocol. There are options to use intermediate servers,
| but there's a ton of room for information to leak.
| kornhole wrote:
| I meant SIP protocol VOIP that can also send and receive
| SMS via a server.
___________________________________________________________________
(page generated 2023-06-14 23:01 UTC)