[HN Gopher] 0-click deanonymization attack targeting Signal, Dis...
___________________________________________________________________
0-click deanonymization attack targeting Signal, Discord, other
platforms
Author : hackermondev
Score : 918 points
Date : 2025-01-21 14:59 UTC (8 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| internet_points wrote:
| So if you send a picture to a Signal user, it's retrieved via
| cloudflare, and cached in a data center near that user; now you
| can look up the cache status and find the data center used. I'd
| say "deanonymization" is stretching it, unless the user is in the
| middle of nowhere (no other users near the data center). But
| interesting writeup anyway.
| naavis wrote:
| Indeed, "incredibly precise estimate of the user's location"
| feels like an exaggeration. But still, very interesting!
| bigbones wrote:
| It gets more interesting when you think about the impact on
| groups. Sending an image to a group is enough for all devices
| associated with that group to be identifiable from CloudFlare's
| side, who additionally see a giant chunk of unencrypted traffic
| from the same client addresses going to other web sites. Given
| Cloudflare's less-than-straight approach to sales, it is
| astonishing the words "secure" and "Signal" ever appear in the
| same sentence.
|
| CloudFlare get to see a fuckton of metadata from private and
| group chats, enough to trace who originally sends a piece of
| media (identifiable from its file size), who reads it, when it
| is is read, who forwards it and to whom. It really doesn't
| matter that they can't see an image or video, knowing its size
| upfront or later (for example in response to a law enforcement
| request) is enough
| paulryanrogers wrote:
| I wonder if we'll see assets being padded to some common byte
| sizes to combat this.
| kijin wrote:
| Nothing stops Cloudflare from inspecting the file contents,
| or using a hash to distinguish between identically-sized
| files.
|
| The only reason we assume they don't do this is because
| it's a waste of resources for no good reason. But what if
| somebody gave them a good reason?
| echoangle wrote:
| Aren't the files end-to-end encrypted? How would they
| inspect the files?
| diggan wrote:
| Last time I used Cloudflare I think their settings
| default to only "Origin SSL/TLS" (or whatever they call
| it), which wouldn't encrypt anything between Cloudflare
| and the origin, it would only encrypt data between
| Cloudflare and the end-user/browser.
| lolinder wrote:
| But the Signal client encrypts images before sending them
| to the Signal server. If it padded out the images at that
| point, the images would all be indistinguishable from
| each other unless Cloudflare were actually able to break
| the encryption (which would completely undermine the
| entire security model).
| diggan wrote:
| Ah yes, I'm sorry, I mistook the context. If Signal
| encrypts the images E2E, you're right that it wouldn't
| matter what Cloudflare does, especially if padded.
| echoangle wrote:
| TLS doesn't matter for End-to-end encrypted stuff though,
| you could exchange the data over Telnet and it would
| still be secure. The content itself is already encrypted
| before being transmitted and can only be decrypted by the
| receiver.
| kijin wrote:
| AFAIK the attack described by OP only works if the
| attacker knows the (randomly generated) URL of the image,
| which probably means they have a Signal client that can
| decrypt the image already. So the secrecy of the content
| is not at issue. The question is whether some specific
| person has received the same image, and from where.
| chatmasta wrote:
| Part of his attack requires disabling the cache on his
| (sender) side so that he doesn't pollute the cache. That
| implies that both sides of the conversation share the
| same URL, which means Cloudflare could assume two IP
| addresses requesting the same URL on the Signal
| attachment domain are participating in a shared
| conversation.
| dingnuts wrote:
| yeah, the person you're referring to is confused because
| the Cloudflare HTTP service terminates TLS and presents a
| Cloudflare certificate, but that doesn't have anything to
| do at all with Signal's E2EE which is not based on HTTPS
| PKI
| greysonp wrote:
| Hi there, Signal dev here. We do, in fact, pad attachments
| to a limited set of bucket sizes.
| lolinder wrote:
| > Given Cloudflare's less-than-straight approach to sales, it
| is astonishing the words "secure" and "Signal" ever appear in
| the same sentence.
|
| This is an overly binary take. Security is all about threat
| models, and for most of us the threat model that Signal is
| solving is "mainstream for-profit apps snoop on the contents
| of my messages and use them to build an advertising profile".
| Most of us using it are not using Signal to skirt law
| enforcement, so our threat model does not include court
| orders and warrants.
|
| Signal can and should append some noise to the images when
| encrypted (or better yet, pad them to a set file size as
| suggested by paulryanrogers in a sibling comment) to mitigate
| the risks of this attack for those who do have threat models
| that require it, but for the vast majority of us Signal is
| just as fit for purpose as we thought it was.
| crawfordcomeaux wrote:
| Hello, I'm an organizer for a system to coordinate multiple
| mutual aid networks, many of which are only organizing by
| Signal & Protonmail exclusively because they think they're
| secure and private.
|
| People who are doing work to help people in ways the state
| tries to prevent (like giving people food) rely on this
| tech. These are the same groups who were able to mobilize
| so quickly to respond to the LA fires, but the Red Cross &
| police worked to shut down.
|
| This impacts the people who are there for you when the
| state refuses to show up. This impacts the future version
| of you who needs it.
|
| Most people aren't disabled, yet. Doesn't mean they don't
| need us building infrastructure for if/when they become
| disabled.
| Evidlo wrote:
| What groups did the police and Red Cross shut down? Any
| links?
| basilgohar wrote:
| In any geopolitical crisis, you tend to have victims on
| both sides be prevented from getting relief, except when
| the one side is imperial.
|
| The powerful entities tend to prohibit relief to the
| oppressed side, even making it illegal.
| lolinder wrote:
| This is why I say that it's overly binary, not incorrect.
| Some people do have such needs, and Signal can and should
| fix this for those people.
| mmooss wrote:
| Someone should tell anyone who seeks confidentiality that
| no email is secure. Use Signal and enable the data
| retention (i.e., automatic message deletion) feature. By
| itself that is not perfectly secure, but it's a start.
| cekanoni wrote:
| people who think protonmail is secure it's to the same
| level as mail.yahoo.com :)
| hedgedoops2 wrote:
| Maybe not individual warrants (at least not warrants to do
| non-scalable collections like hardware bugs in one's phone
| - I.e. warrants that, most users, with high probability,
| are not subject to). But mass surveillance, e.g. NSA, even
| with 'mass warrants' (e.g. Verizon-FISA warrant), that
| everyone is subject to, is probably in most people's
| attacker model. I don't have a study handy, but it seems
| reasonable that most users use signal to protect against
| mass surveillance and signal advertises itself as being
| good for this.
|
| Also Marlinspike and Whittaker are quite outspoken about
| mass surveillance.
|
| If cloudflare can compile a big part of the "who chats with
| whom" graph, that is a system design defect.
| autoexec wrote:
| I highly doubt that signal does anything to help with
| mass surveillance. Signal started keeping people's name,
| photo, phone number, and contacts in the cloud protected
| by a "secure" enclave the NSA almost certainly has access
| to and hackers already got into
| (https://community.signalusers.org/t/sgx-cacheout-sgaxe-
| attac...) and even leaving all that aside, all anyone
| needs is a PIN that can be trivially brute forced.
| (https://www.vice.com/en/article/signal-new-pin-feature-
| worri...)
| vel0city wrote:
| > Signal can and should append some noise to the images
| when encrypted (or better yet, pad them to a set file size
| as suggested by paulryanrogers in a sibling comment) to
| mitigate the risks of this attack for those who do have
| threat models that require it
|
| Adding padding to the image wouldn't do anything to stop
| this "attack". This is just watching which CF datacenters
| cache the attachment after it gets sent.
| lolinder wrote:
| Right, my bad on the ambiguity--I was replying to the
| OP's concern about image sizes, not the attack in TFA:
|
| > It really doesn't matter that they can't see an image
| or video, knowing its size upfront or later (for example
| in response to a law enforcement request) is enough
| vel0city wrote:
| That makes sense. Thanks for the clarification, my bad!
| rangestransform wrote:
| I think the threat model of enough signal users to matter
| is nation-state actors, and signal should be secure against
| those actors by default so that they may hide among the
| entire signal user population
| doodlebugging wrote:
| >It gets more interesting when you think about the impact on
| groups. Sending an image to a group is enough for all devices
| associated with that group to be identifiable from
| CloudFlare's side,
|
| Doesn't this open up the possibility to identify groups that
| have been infiltrated by spies or similar posers? If you use
| this method to kinda-sorta locate or identify all the users
| in your group and one or more of those users ends up being
| located in a region where you should have no active group
| members then you may have identified a mole in your network.
|
| Just thinking out loud here since there's no one else home.
| gruez wrote:
| >If you use this method to kinda-sorta locate or identify
| all the users in your group and one or more of those users
| ends up being located in a region where you should have no
| active group members then you may have identified a mole in
| your network.
|
| ...unless they happen to be using a VPN for geo-unblocking
| reasons or whatever.
| lolinder wrote:
| If you're in a group like this where people are seriously
| concerned about their location being discovered by
| governments or by their own contacts, anyone in that
| group who is not already on a VPN all the time is either
| ignorant or nuts.
| throwway120385 wrote:
| Communication of any sort over any channel risks sharing
| location information. Silence is secrecy.
| xnorswap wrote:
| It could be useful for correlation.
|
| Say for example that you're an investigating agent in regular
| contact with someone.
|
| A single data-point wouldn't mean anything. However, a sequence
| of daily image retrievals might tell you that they spend 90% of
| their time in WA and 10% of their time elsewhere.
|
| That information alone still might not mean anything, but if
| you also have a specific suspect in mind, it may help confirm
| it. Or if you have access to the suspected person directly, if
| you're able to also befriend their "clean" profile, you might
| be able to pull the same trick and correlate the two location
| profiles.
|
| De-anonymisation isn't about single pieces of information, but
| all information helps feed into a profile to narrow suspects or
| confirm suspicions.
|
| ( By "agent" I just mean a person, not an AI agent nor Law
| enforcement, who could presumably just get the information more
| directly from cloudflare. )
| immibis wrote:
| There's probably at least a few instances where you send
| someone you think is American a picture but it gets cached in
| Moscow, or vice versa. Or you post a meme to a Californian
| left-wing group and it gets cached in DC. Not hard to imagine
| situations where getting an unexpected rough location could
| be a valuable signal.
| gruez wrote:
| >Or you post a meme to a Californian left-wing group and it
| gets cached in DC. Not hard to imagine situations where
| getting an unexpected rough location could be a valuable
| signal.
|
| Not really. Any public meme group is inevitably going to be
| monitored by intelligence agencies, and you should assume
| as such. Even if it isn't, I can imagine agitators from the
| other side joining the group with a Russian VPN to poison
| the well. If there's a private group of people that you
| supposedly trust, any _competent_ mole is going to be using
| device /network level VPN to cover their tracks. Otherwise
| they're 1 click away (eg. if someone shared a link) from an
| opsec fail.
| meowface wrote:
| I would bet money almost no public meme groups are
| monitored by any intelligence agencies. And the few that
| are mostly only are just in the sense of being casually
| co-opted by state-sponsored trolls with almost no
| attention from actual intelligence agency staff (in the
| way this thread implies, with investigations and
| deanonymization and such).
| catlikesshrimp wrote:
| You can also ping the same person multiple times, like once a
| day at different time of the day. That provides a more
| complete range.
| genewitch wrote:
| you don't have to "befriend" them. you send a friend request
| because that defaults to a push notification for users with
| the discord app on their phone. Now, with signal, i don't use
| it so i don't know how initial chats start, or whatever. The
| discord one is 0-click because the PFP in the friend request
| is the payload delivered via PUSH.
|
| And to someone else's point - they had to block the request
| on their end with a MITM to do the 1-click version on signal.
| No such MITM is needed with the friend request.
|
| As an aside, one time i got doxxed _hard_ in an IRC channel
| with several hundred active users. I had a suspicion of who
| it was, and i knew they lived in chicago. So i
| "accidentally" sent a link to "screenshot proof" that was
| hosted on one of my domains. there was 1 immediate click.
| instant. Chicago. "accidentally" because it looked like i
| pasted an email body.
|
| Packed the _real_ screenshot and a complaint to the ircadmin.
| they said "and so you dox them back?"
|
| can't win for trying.
| thrwaway1985882 wrote:
| "Near a user" is also a big assumption. I'm ~200 miles to ORD
| and ~500 to IAD, but my ISP's peering & upstream arrangements
| mean Cloudflare serves my traffic 700 miles from DFW.
|
| But, at the same time: Cloudflare isn't going to serve me a
| cache from Seattle, Manchester, or Tokyo. Pinning down an
| unknown Signal user to even a rough geographic location is an
| important bit of metadata that could combine to unmask an
| individual. Neat attack!
| btown wrote:
| It's also quite insidious as you don't need to control
| anything on any server to get this information; as long as
| you can get your target to load a unique URL never before
| loaded by anyone else, you can simply later poll it with an
| unauthenticated HTTP GET from different locations, and find
| which one reports a Cloudflare HIT (or, even if they hid that
| information, finding the one that returns with lower
| latency).
|
| If you're allowing user uploaded content, and you use
| Cloudflare as a CDN, you could mitigate and provide your
| users with plausible deniability by prefetching each uploaded
| URL from random data centers. But, of course, that's going to
| make your Cloudflare bill that much more expensive.
|
| Cloudflare could allow security-sensitive clients to hide the
| cache-hit header _and_ add randomized latency upon a cache
| hit, but the latter protection would also be expensive in how
| many connections must be kept alive longer than they
| otherwise would. Don 't do anything on a personal device or
| account if you want your datacenter to be hidden!
| ipaddr wrote:
| Going forward uploaded content should never go through
| cloudflaire and it never really needed to.
|
| Add unique urls.
|
| Maybe just avoid it altogether.
| gabeio wrote:
| > Going forward uploaded content should never go through
| cloudflaire and it never really needed to.
|
| The problem in this case isn't cloudflare. The problem is
| that these images load without the user's interaction and
| the person sending it gets to choose if it's cloudflare
| or not. So your statement within this context doesn't
| really work.
| vel0city wrote:
| The person receiving it chooses to download images or
| whatever automatically though.
|
| I dunno, I'd still say the problem is at least 50%
| cloudflare. Why should they make which datacenters have a
| resource cached be obvious public knowledge? I do agree
| though, one could still end up inferring this information
| noisily by sending an attachment, waiting a while, and
| then somehow querying a lot of DCs and trying to infer
| times to see if it's cached or not.
|
| Personally, I've never been a fan about so many things
| like URLs being so public. I get the benefits of things
| like CDNs and what not and the odds of guessing a
| snowflake value and what not, but still...all attachments
| in Discord are public. If you have a URL, you have the
| attachment. And they're not the only ones with this kind
| of access model.
| radicality wrote:
| Isn't that because the URL parameters are so long that by
| design they effectively _are_ the password protection for
| the resource ? They shouldn't be able to 'leak' to
| unintended recipients.
|
| Personally, like you I'm also not a huge fan of this, but
| URLs like that basically should be treated as the
| passwords. Don't post them publicly / don't give them out
| to people you don't trust.
| vel0city wrote:
| There's a part of me that's fine with it for a short-
| lived URL which contains a temporary access key but for a
| forever URL with a forever access key I'm not entirely
| happy with it.
|
| I use it to share memes and shitpost but definitely not
| something to share sensitive content IMO.
| gabeio wrote:
| For signal then the issue becomes saving who owns what
| image (so that you can re-issue "passwords") and THAT is
| much more dangerous to the users than simply allowing
| users to grab semi-anonymous links into their cdn with
| enough of a url to be nearly impossible to iterate
| through every combination without hitting tons of rate
| limits. (Ignoring this location cache timing issue.)
|
| Edit: Actually... (in signal's case) it might be possible
| to provide the user's device 2 tokens, 1 to access the
| url and 1 to issue new access links. Then the user can
| request a new access link with their second token when
| their url access token expires. Signatures would help
| prevent it from needing to be stored in the database. It
| would be interesting to try.
| ipaddr wrote:
| Would removing cloudflare fix the issue? Then the problem
| is cloudflare related.
|
| Your defense doesn't really work. Sure many entities
| could share blame but the one fix is getting rid of
| cloudflare.
| chatmasta wrote:
| Pre-fetching also becomes an issue for apps that are meant
| to be e2e encrypted, since it requires the server to
| download (read) every attachment. But if the app is already
| caching the attachment then they're effectively reading it
| anyway.
|
| (EDIT: Apparently signal e2e encrypts images prior to
| upload, so pre-fetching the encrypted blob from one or
| multiple servers would in fact be a mitigation of this
| attack.)
|
| I do wonder if Telegram is as invulnerable as the author
| assumes. They might not be using Cloudflare for caching, or
| even HTTP, but the basic elements of this attack might
| still work. You'd just need to modify the "teleport" aspect
| of it.
| duskwuff wrote:
| Telegram doesn't use local CDNs for caching. All users
| are associated with one of about five telegram DCs, and
| upload files to their local DC. If a file was uploaded by
| a user on another DC, users connect to it temporarily to
| download the file.
|
| The DC that a user is associated with is exposed by the
| API - you don't need to get them to upload a file to
| discover it - but it's so broad that it's not much of a
| deanonymizing signal. (Knowing that your target is in
| DC1, for example, just means that they're probably
| somewhere in North or South America. Or that they
| registered using a phone number that said they were.)
|
| https://core.telegram.org/cdn
| ajsnigrutin wrote:
| for "normal people", that's a pain, but with enough
| resources,...
|
| Although. it has edge usecases even for "normal people":
|
| Eg. you suspect your coworker to be catfishing you on eg.
| discord, you know that he's in your city now, verify, then
| wait for him to leave for a vacation to somewhere abroad,
| check again.
| dotancohen wrote:
| This is actually pretty smart, and shows that this exploit
| could be chained with other information to identify a
| specific individual. This could also be used to e.g. check
| which world-travelling reporter is communicating with you.
| mmooss wrote:
| It's not an edge case. Using multiple sources of
| information to paint a more complete picture is the norm.
| That's how marketing profiles work, for example.
| 8338550bff96 wrote:
| I doubt how useful it would be as an attack. As a single
| point of info it tells you next to nothing. As part of a
| composition of other indicators it would be the weak link in
| the chain probably just causing noise for the not un-likly
| scenario where the person you're targeting is using a VPN.
|
| If it was any less specific we'd be talking about a
| deanonymization attack that outs whether or not a target is
| still on Earth.
| mmooss wrote:
| > not un-likly scenario where the person you're targeting
| is using a VPN
|
| Do you think a large proportion of Signal users also use
| VPNs? I'd expect it would be a higher proportion than the
| general population but still only a small minority.
| kdmtctl wrote:
| > Do you think a large proportion of Signal users also
| use VPNs?
|
| It is feasible to consider that _interesting_ Signal
| users mostly use VPN as an extra protection layer.
| raphman wrote:
| Oh, this attack would be a useful tool for e.g.,
| identifying whistleblowers that travel a lot (e.g., in
| academia, military). If you know their Signal ID, you could
| send them images from time to time and then compare their
| coarse locations with travel information for a number of
| suspects.
| judge2020 wrote:
| Note that CF will also route relative to the sites' plan.
| Enterprise sites are almost always routed to the closest DC,
| while if that DC is overloaded then lower tier websites,
| typically just Free sites, will get routed elsewhere (I
| suppose this is achieved via different anycast ranges where a
| specific DC is excluded). Although Discord, Signal, etc are
| almost certainly Enterprise sites.
|
| I have this old site to test this (the list of sites is a bit
| old): https://cloudflare-test.judge.sh/
| whoopdedo wrote:
| Send picture to multiple accounts, perhaps on different
| services, the links that are cached at the same data center can
| be more confidently believed to be related.
| cyanydeez wrote:
| timing and location can usually prune things down to enough
| data about a person.
| quotemstr wrote:
| Even time zone leaks are privacy issues, and the leak we're
| discussing is more fine grained than time zone.
| dinosaurdynasty wrote:
| It only takes 33 bits to identify someone. This reveals a
| couple of bits.
| gruez wrote:
| Not really. It's only true if the bits are uncorrelated, and
| you can acquire additional bits of information. I don't see
| how you can go from "this guy on the internet lives near
| Albuquerque, New Mexico" to "this guy is Walter Hartwell
| White, and lives at 308 Negra Arroyo Lane, Albuquerque, New
| Mexico, 87104" without massive opsec failures.
| chatmasta wrote:
| Repeat the attack daily for a few weeks and you might get a
| pattern of movement. Of course if the target hasn't left
| their general area then this won't help. But if you're a
| nation state watching a target move between multiple
| international locations, you could match this up with
| passport travel data to significantly reduce the anonymity
| set.
| gruez wrote:
| Seems contrived. What type of a person cares about
| deanonymization attacks and nation-states trying to find
| him, but doesn't have an always-on VPN? Even without this
| attack, not using a VPN means you're 1 wrong click/tap
| away (if you accidentally clicked on a link) from leaking
| your IP.
| chatmasta wrote:
| Right, agreed that VPN is the primary mitigation against
| this from a user perspective. But opsec is hard,
| especially when the attack can be triggered by a
| notification when the victim might not be expecting it
| and might not have VPN enabled (e.g. maybe they only
| enable VPN when using Discord).
|
| (But notifications are already a bad idea for opsec
| anyway.)
| gruez wrote:
| >But opsec is hard [...]
|
| That's why the attack is contrived. If you have poor
| opsec you don't need need this attack at all. You can
| probably get the victim's exact IP by getting him to
| click on a link, or sending him an email. If he has good
| opsec he's going to be using a VPN that renders this
| attack useless. For this attack to be valuable you need a
| guy who has such good opsec that you can't get his
| location any other way, but for whatever reason isn't
| using an always-online VPN.
| kuschku wrote:
| Every little bit helps.
|
| You can plot the timestamps of every message, read receipt
| and emoji reaction, which gives you the timezone and hints
| at work schedule, commute duration and vacations.
|
| Often people will post photos or have profile pictures.
|
| Say you have a photo taken at a random mcdonalds. That'd be
| 36'000 locations. Imagine cloudflare location and timezone
| help you narrow it down to new mexico. That's 80 locations.
| Small enough that you can look at every single one using
| street view and check where the photo actually was taken.
|
| Now you can subpoena the McDonald's cctv footage and figure
| out who sent that picture.
| gruez wrote:
| >Often people will post photos or have profile pictures.
|
| >Say you have a photo taken at a random mcdonalds. That'd
| be 36'000 locations. Imagine cloudflare location and
| timezone help you narrow it down to new mexico. That's 80
| locations. Small enough that you can look at every single
| one using street view and check where the photo actually
| was taken.
|
| Sounds like the bigger opsec failure is posting the
| pictures, and the leaking the cloudflare POP only makes
| the search slightly easier.
| darkwater wrote:
| > Sounds like the bigger opsec failure is posting the
| pictures, and the leaking the cloudflare POP only makes
| the search slightly easier.
|
| I would not define 3 orders of magnitude as "slightly
| easier".
| cthalupa wrote:
| You can almost certainly narrow down the McDonalds with a
| wide variety of things - this example is fairly
| contrived.
|
| If you can see outside of the McDonalds for street view
| to be usable, you're almost certainly able to determine
| what country it is in, and potentially the exact
| location, depending on what is visible outside.
|
| If it's a picture that shows the menu, well, street view
| isn't likely to be super useful, but you'd have a trivial
| time figuring out what country it is in at that point -
| menus vary from country to country, even when they are
| still in English.
|
| New Mexico has relatively few McDonald's restaurants
| because New Mexico has a fairly low population - only
| 2.1m for the whole state. With that in mind, it seems
| unlikely that that Cloudflare has a close enough POP for
| you to be able to specifically decide it's NM.
|
| If I can see enough for Street View to be able to confirm
| location, it seems like I can just search via the data
| there and get far more narrowed down results. If I can
| see a Burger King and a Best Buy outside from the
| picture, I can just use one of the many mapping services
| with APIs to get a list of all McDonalds locations within
| a tenth of a mile of a Burger King and Best Buy and look
| through a smaller list. If I'm confident of the time
| zone, like you suggest we should be able to be, then
| that's an even smaller list.
|
| I'm not saying this attack is useless by any means, but I
| don't see a world where the sharing of the pictures to
| begin with isn't the most significant opsec failure and
| doesn't open you up to being de-anonymized in a myriad of
| other ways.
| swid wrote:
| There is a fun post that explores this idea via an anime
| called Death Note.
|
| https://gwern.net/death-note-anonymity
| jellicle wrote:
| Two or three very small opsec failures equals one massive
| opsec failure.
| jjmarr wrote:
| If you want to extend the analogy, Gus Fring's threat model
| for RFP contractors at the superlab required flying people
| into the United States and driving them for days before
| reaching the final destination. i.e. If you aren't selected
| for the final proposal, the most you _should_ know is the
| lab is "somewhere reachable by driving from the United
| States".
|
| Locating the superlab to within 800 miles would break Gus'
| threat model.
|
| Combined with the information the police have, which is
| that a new form of "blue meth" is spreading across the
| American southwest, a reasonable conclusion would be that
| the "underground superlab" is where the meth is being
| manufactured. It's independent corrobation of a major
| _manufacturing_ operation occurring in the United States in
| the exact region where a new drug is taking off.
|
| This is useful, since it helps rule out the meth being
| smuggled in from Mexico. It also makes the lab a high
| priority target, because a DEA agent investigating doesn't
| need to liaise with a foreign government, and you can
| secure a domestic prosecution + American prison time
| instead of attempting to extradite the cooks.
|
| It also allows me to send a detailed memo about the
| superlab to ASAC Schrader's office in Albuquerque telling
| him about a threat in his jurisdiction, rather than
| circulating a brief summary about this superlab in the
| weekly intelligence briefing sent to all high-ranking DEA
| officials they probably don't read.
| devnullbrain wrote:
| Brilliant. Please consider writing a book about things
| like this.
| 65 wrote:
| I'd say it'd be useful for very specific use cases. Such as
| finding out what country Jia Tan, the XZ Utils backdoor
| attacker, is in.
| cassepipe wrote:
| I wonder if it'd be a good idea for Signal to implement a
| "simple" mode that would deactivate most features in order to
| reduce the attack surface for people who really think they are
| being targeted. Would that be a good idea ?
| lxgr wrote:
| It's not stretching it. The expectation is that Signal does not
| reveal any observable aspect of your IP address or location
| when receiving messages on it.
|
| Whether this specific level/type of deanonymization is a
| problem for your particular use case is an entirely different
| question. Personally, I wouldn't even care if mutual contacts
| were to see my IP address outright (and they do for calls), but
| I'm not every user.
| pyeri wrote:
| Exactly. Especially when considering that Signal was often
| advertised as that *one* privacy friendly open-source
| messaging solution in a world dominated by data-collecting
| demons like WhatsApp, etc. I don't think even WhatsApp let's
| such status details leak; notwithstanding whatever they might
| be doing with the user data on the backend.
| genewitch wrote:
| I don't care if users see "my" ipv4 because cgnat. I _think_
| i don 't care if they can see my ipv6 because each machine
| gets a /64 to itself, that's the logic, right?
|
| But my PBX and my matrix server both use coturn. Our 10 user
| "private" PBX we have to VPN into a fortigate in a DC to use,
| but to my understanding, there's literally no way to
| eavesdrop on those calls without already compromising the
| server it's running on, and if that's the case, no extra VPN
| steps or whatever will help.
|
| anyhow even with a real, publicly routable IP, stock windows
| 11, stock macos (used to be true), and most linuxes won't get
| compromised by stuff like backorifice or whatever else l0pht
| put out as "remote administration tools". that is, there
| usually isn't any listening ports on a public IP these days.
| Shield's Up!
| bigiain wrote:
| > to my understanding, there's literally no way to
| eavesdrop on those calls without already compromising the
| server it's running on
|
| That's probably correct (with the caveat that I suspect
| NSA/FSB/MSS/Mossad/whoever can reasonably be assumed to
| have backdoored Fortinet)
|
| There is still the problem that an attacker with "global
| passive observer" capabilities (which almost certainly
| includes most non 3rd world nation states, and probably a
| few of the more problematic 3rd world ones too) can still
| do traffic analysis to uncover your social network (or
| criminal/terrorist/whistleblower/journalistic network) by
| identifying the call traffic endpoints.
| bigiain wrote:
| > I think i don't care if they can see my ipv6 because each
| machine gets a /64 to itself, that's the logic, right?
|
| I suspect you're looking at that wrong.
|
| It's each internet connection that gets a /64, not each
| machine. Your ISP hands you a /64 and you can do whatever
| you like with it on your home(/corporate) network.
|
| So you can choose from 18 thousand trillion IPV6 addresses
| for any machine behind your ISP/internet connection, but
| the top half of your IPV6 address uniquely identifies that
| ISP and they can connect that to your account/payment
| details, with 4 billion times as much precision as an IPV4
| address.
| hmottestad wrote:
| If I know someone on Signal I can now check if they've left the
| country.
|
| Or send this to a bunch of signal users whom you suspect one of
| them being a particular person, and if you know that the person
| you are looking for is going to travel you can send it once
| before and once after. Then see which of these users were in
| the home city and subsequently in the destination city.
| paulpauper wrote:
| This is not unique to signal. URL strings can contain
| identifying information regardless of where they are shared or
| posted. For example, if you send a link that ends with string
| of characters, these may correspond to a geographic location or
| browser settings. Blogger urls used to be geolocated, such as
| .ca for Canadian viewers. it is always safe to strip out
| unnecessary chacters if you're paranoid.
| dlandis wrote:
| > attacker can use the cache geolocation method to pinpoint the
| recipient's location
|
| Agree, good writeup, but also a stretch to say they are
| "pinpointing" anyone's location.
| ncr100 wrote:
| Mmmm "qualified deanonymization" perhaps?
| harrall wrote:
| When I was ~15 and this was ~2004, some friends and I ran a
| forum with a lot of users and did some bad things where we
| would track down repeat banned users and screw with them. (In
| our defense, they were screwing with us.)
|
| We used everything, from browser fingerprinting (and EFF only
| made the world aware of it 6 years later), looking them up in
| databases, tracing every digital evidence they left, etc.
|
| Every little thing counted. What I learned is that people leave
| a lot of traces and you can collect these traces to dox them.
| The way you write is even sometimes fairly identifiable.
| mmooss wrote:
| Combined with other information, it may identify someone
| reliably, just like you can with zip code, age and gender. For
| example, if you know this person is part of a group with
| members in several locations, or if you can corroborate
| someone's movements, etc.
|
| For example, imagine someone suspected of sharing sensitive
| information with a journalist. They might have a short list of
| suspects, and use this technique to confirm which one it is.
| They might identify which journalist it is - maybe only a
| limited number cover this beat.
| cutemonster wrote:
| Or you want to find a specific journalist, and you find out
| that they just arrived to a certain city, and there are only
| three hotels in that city...
| mmooss wrote:
| That doesn't tell you whether that journalist is
| investigating you. Identifying them as the recipient of a
| Signal message from a suspect is valuable information.
| oceanplexian wrote:
| The real attack is that a law enforcement agency can trivially
| subpoena CloudFlare with the attachment URL they will hand over
| the IP address of the recipient of the image along with
| whatever other requests they made through the CDN which can
| pretty precisely and rapidly de-anonymize you.
| snapcaster wrote:
| It's leaking so many bits idk what else you would call it,
| deanonymization isn't a one shot thing and it's a spectrum not
| a binary outcome
| soerxpso wrote:
| "Deanonymization" doesn't have to refer to a full exact
| address. There are people who wish to conceal which country or
| region they live in, which this cripples.
|
| There was a real example of that amount of information being
| relevant in the Silk Road investigation. Ulbricht accidentally
| revealed his timezone early on, which was useful to US
| authorities since it narrowed him down to being in the US,
| whereas without that information he could have been from
| anywhere in the world.
| alp1n3_eth wrote:
| Not really.
|
| Anyone who wants to conceal what continent they're on will
| also be using a VPN 24/7, or will have the proxy setup in
| Signal (AKA running 24/7), which defeats this.
| lolinder wrote:
| Yep: If your threat model includes an attack like this and
| you're not always on a VPN already, you're likely already
| compromised.
|
| This is a neat demo, but it should not fundamentally alter
| the way that anyone is using Signal. Either it doesn't
| matter to you or you already have mitigations in place.
| bigiain wrote:
| > If your threat model includes an attack like this
|
| The problem is, nobody's threat model includes state
| level attackers, until one day it does.
|
| Back when Ulbricht was publicly asking questions using an
| easily uncovered identity, he wasn't thinking that in a
| few years he'd have the full force of every relevant TLA
| in the US (and Five Eyes/14 Eyes) trying to track him
| down.
| lolinder wrote:
| But he also chose to go on and found a darknet narcotics
| service. Most people don't do something like that.
|
| Yes, it's vogue right now to speculate that what you're
| doing right now could suddenly become illegal in a new
| administration, but if that happens tomorrow, most of us
| would be one of hundreds of thousands who are all in the
| same boat. For that reason, most of us won't get targeted
| retroactively for behaviors that were legal at the time,
| and we have the option to reevaluate our security posture
| when the political landscape changes.
|
| But yeah, if you're actively speculating about starting
| an illegal service today, you should definitely have a
| better security posture than Ulbricht did.
| cekanoni wrote:
| Headline feels like a click bait :)
| bufferoverflow wrote:
| CloudFlare has the actual IP address that viewed the image.
| Which means some powerful (or rich enough) actors can get it.
|
| This is very very bad.
| cthalupa wrote:
| This was... always, the case though? For any CDN service? How
| do you serve traffic to people without knowing where to send
| it?
| bufferoverflow wrote:
| Onion protocol.
| iforgot22 wrote:
| Looks like it's possible to hit 2 datacenters due to load-
| balancing, which would narrow it down a bit more.
| AnonC wrote:
| This is quite a detailed write up. I went through the post
| quickly, but didn't get why Signal would just download an
| attachment from an unknown number/contact without first prompting
| the user to accept or deny the conversation request. I've seen
| conversation requests always waiting for me to accept or not. If
| I don't accept, I don't see any messages on that chat and the
| other person doesn't get any indication of message delivery. What
| have I missed?
|
| If the message is from a known or trusted contact, I think there
| can be larger problems than just a rough location reveal.
| hypeatei wrote:
| > didn't get why Signal would just download an attachment from
| an unknown number/contact
|
| Usability, most likely. Ultra-secure and paranoid doesn't
| result in good UX most of the time.
| powerhugs wrote:
| Push notification thumbnails. It's mentioned in the article
| ...
| furyofantares wrote:
| > I went through the post quickly, but didn't get why Signal
| would just download an attachment from an unknown
| number/contact without first prompting the user to accept or
| deny the conversation request.
|
| I guess you went through the post too quickly, because it goes
| over how that's exactly how it works. Unless you have push
| notifications enabled and on default settings to include the
| content in the push notification.
| gruez wrote:
| >I went through the post quickly, but didn't get why Signal
| would just download an attachment from an unknown
| number/contact without first prompting the user to accept or
| deny the conversation request.
|
| Where are you getting the impression that signal auto-downloads
| attachments from an unknown number/contact? The OP says there's
| auto-download, but not that it happens from unknown contacts.
| hypeatei wrote:
| This is certainly an "attack" but not one you'd normally
| associate with zero click. There is no code execution, but some
| tricks to see which Cloudflare datacenter cached the image --
| giving a very rough area the user is in. Impressive and
| insightful nonetheless.
| sim7c00 wrote:
| depending on the circumstance, the rough area might already be
| useful to adversaries of the person trying to hide. I wouldn't
| expect things like criminals etc. to suffer from this, 300
| miles is a big radius for example... but if you want to know if
| 'the guy is still in country' or something like that (for
| instance law enforcement) it's useful for them. such parties
| could then collaborate with local resources to do further
| investigations. knowing which local resources in what area to
| enable might save a lot of 'costs'.
|
| as you said, impressive and insightful. :D kinda feel like the
| docs on it were a bit chatGPT aided, they are super clear and
| full of 'certain sentences'. (this is totally an excellent use-
| case for that, so not bashing on it at all!).
|
| nice read.
| sitkack wrote:
| You would know if they are over a cellular network or
| checking on mobile.
|
| If someone sends you a youtube link and you hit play, YT
| knows who you are, both from a network perspective and
| potentially the logged in user.
|
| If you are using signal in a high risk environment, you
| should be using it from a system that contains no extra
| information about you. This is the same posture one should
| take when using Tor.
|
| Basic opsec.
|
| I don't think these kinds of things are in signals threat
| model. It is meant? as a message platform for people with
| nothing to hide?
| sim7c00 wrote:
| i don't think you can call opsec basic, since it requires
| tons of knowledge about technology and techniques
| adversaries might deploy against you. targets of attacks
| don't neccesarily have this kind of knowledge.
|
| opsec is _incredibly_ hard for a person not deeply into
| technology and this type of information. you might argue
| that you need to stick with certain tools and techniques
| that are known good, but new vulnerabilities and techniques
| implemented against you can completely shatter previous
| knowledge on whats good and bad opsec and still break it
| despite doing it 'very well'. (like certain darknet markets
| being closed down due to new vulnerabilities being found in
| the platforms they use...)
|
| most people who rely on opsec/tradecraft for a living, also
| rely on teams of people to help them maintain it and
| validate it constantly... (or eventually fail and get
| bitten).
|
| you are right though that its unlikely a company or app
| producer would have a threat model tuned to people who want
| to hide stuff. those things generally tend to be closed
| down sooner or later. (encrochat and such services...)
| sitkack wrote:
| You are absolutely right, I think it should be basic
| opsec, but is probably advanced opsec seeing how many
| folks get tripped up by this stuff.
|
| This means, never using a browser context you have ever
| logged into any service that is personally identifying.
| That also means the order in which you load pages. If
| your ritual is open pintrest followed by slashdot, that
| is now your finger print.
|
| It isn't just what you do, but how you do it and the
| ordering between those events. You also don't want to
| accidentally deanon yourself or your peers, even when
| everyone is trusted because it also leaks group
| membership information.
|
| The mental framework for opsec can be modeled as vector
| calculus and differential geometry. You have to think of
| the flow of information across a surface and in the
| integral of that flow. Assume an adversary with perfect
| total information.
| lovasoa wrote:
| Law enforcement could probably just ask cloudflare for the
| exact IP address that retrieved the attachment.
| sitkack wrote:
| Anyone can do this are per the TFM, which is an excellent
| read.
| sim7c00 wrote:
| do you think law enforcement in Iran will get an answer
| from cloudflare?
| rlpb wrote:
| Only if they're from a friendly country. If the reason a
| user needs anonymity is geopolitical, that isn't a
| guarantee.
| a1o wrote:
| This is pretty interesting, and well documented. Great work! I
| wonder if there is a way to turn off notifications or if the
| approach is to simply not run such apps.
| omoikane wrote:
| Not sure about mobile apps, but in Discord desktop there is an
| option under "settings -> notifications". Your browser may also
| have notification settings that would help.
|
| This changes the attack from a 0-click attack to a 1-click
| attack.
| wood_spirit wrote:
| Presumably cloudfare will close the loophole for enumerating
| cache edges now.
| squigz wrote:
| This doesn't strike me as a new 'attack' (I have to imagine
| there's even a name for such attacks), and 250 miles seems a
| large radius to 'deanonymize' someone, even a high-value target
| (even if such people didn't take any other measures to avoid
| being tracked...)
|
| For reference, here's a 250 mile radius around Toronto Canada
| https://i.imgur.com/ydpR0IZ.png
| Tepix wrote:
| Congrats on finding this. Very impressive for a 15-year-old!
|
| The section "How to Protect Yourself" is lacking.
|
| Step 1. Don't receive this information in the push message. Only
| send the fact that there is something waiting for you in the app.
| Chances are there are other vulnerabilities that compromise the
| end-to-end encryption guarantees provided by the app (and only by
| the app).
|
| In Signal on iOS: Click on your icon in the top left corner.
| Click on settings. Click notifications. Click on display below
| "message contents". Make your choice.
|
| Another situation where convenience clashes with security,
| unfortunately.
| anon-3988 wrote:
| Step 2: If you use Discord, don't allow invites from _anyone_.
|
| Its quite bizarre why social media apps allow anonymous people
| to interact with you. 99% of the conversation I have is with
| people that I roughly know.
| ziddoap wrote:
| > _Its quite bizarre why social media apps allow anonymous
| people to interact with you._
|
| I mean, it's one of Discord's major use-cases. Joining a
| server of a common interest and meeting/talking with other
| people that share that interest.
| im3w1l wrote:
| Discord is for gamers and quite a lot of people will be
| playing a game and tell someone "add me on discord my tag is
| xyz". Not allowing invites would seriously cut into the
| usability.
| Marsymars wrote:
| You could have it so both people have to add each other
| before there's any indication that either person added the
| other.
|
| No extra work for person A, and the work for person B is
| just what person A had to do anyway.
| mplewis wrote:
| This is mostly unusable for what should be obvious
| reasons.
| Marsymars wrote:
| I'm... not actually clear on what those reasons are? For
| the adder, the experience is exactly the same - the only
| difference is that there's no longer an adder and an
| addee - instead there are two adders.
| high_na_euv wrote:
| So, how would you start interacting with your friends if you
| just created account?
|
| >anonymous people
|
| Wtf, how is this even relevant?
| anon-3988 wrote:
| You can add them by creating a unique, temporary
| UUIDs/links that they can use?
|
| You know them from somewhere else, lets say I play a game
| and we decided to get into a voice chat. We could create a
| temporary, dynamically created voice chat that we can all
| join (much like Google Meet) where all of us are anons.
|
| Then, if we really want to know each other, we can then
| share the UUIDs.
|
| I understand why ANYONE can send an email to me (I can
| decide when/will to check them)
|
| I don't understand why ANYONE can whisper to my ears (I
| cant decide since they are pushed to the top of the app)
| mplewis wrote:
| Adding this level of friction to the process is not
| viable for a messaging platform whose bread and butter is
| connecting with friends.
| udev4096 wrote:
| Just don't use it. Expecting privacy and security from a
| literal keylogger. Who in their right mind uses a plain-text
| messaging app in 2025?
| mplewis wrote:
| Most people, actually.
| zolland wrote:
| How is Discord a key logger?
| Bluescreenbuddy wrote:
| If you're worried about anonymity and you're using discord,
| you're failing. It's not made for that.
| squigz wrote:
| > Its quite bizarre why social media apps allow anonymous
| people to interact with you
|
| Bit strange to attribute this to 'social media apps', isn't
| it? I'm interacting with an anonymous person right now. Most
| platforms allow it, including the older ones (i.e., IRC)
| gobip wrote:
| "Signal instantly dismissed my report"
|
| "Telegram, another privacy-focused application, is completely
| invulnerable to this attack"
|
| "Discord [...] citing this as a Cloudflare issue other consumers
| are also vulnerable to"
|
| "Cloudflare ended up completing patching the bug"
|
| I wish Signal would react differently. I still remember the
| bubble color controversy when they changed their mind after the
| backlash and not before. :-)
| airstrike wrote:
| Is there really any difference between dismissing the report or
| "citing this as a Cloudflare issue"?
| debugnik wrote:
| Not in practice.
|
| > There's clearly a problem here as Cloudflare says consumers
| are responsible for protecting themselves against these types
| of attacks, while consumers (ex. Discord) are putting the
| blame on Cloudflare.
| danielparks wrote:
| I just sent a feature request[1] to Signal with the following
| text: I understand that Signal does not
| consider this https://gist.github.com/hackermondev/45a3
| cdfa52246f1d1201c1e8cdef6117 to be a valid security
| bug, but it would be helpful to at least be able to
| mitigate it. Please add an option in settings to
| disable automatically downloading attachments.
| That should be enough to change the attack from 0-click (just
| opening the conversation) to 1-click (click the
| attachment). Most people won't care about this, but for
| some every little bit of privacy is important.
|
| [1]: https://support.signal.org/hc/en-us/requests/new
| LWIRVoltage wrote:
| Hold on, someone else in this thread noted this does exist
|
| " You can disable the auto-download. Settings > Data and
| storage > Media auto-download, you can choose what to auto
| download for mobile data/wifi/roaming."
|
| So, that part is there, but my question is, it's still aissue
| when they manually download the image, right? Unless
| something never accepts images from someone they aren't
| expecting, who 's number or unique created ID has never been
| seen before
| gruez wrote:
| >"Signal instantly dismissed my report"
|
| >I wish Signal would react differently. I still remember the
| bubble color controversy when they changed their mind after the
| backlash and not before. :-)
|
| Can you blame them though? They're a non-profit with limited
| manpower and resources. There's quite a lot of cranks in the
| security field, and as many people have echoed in this thread,
| the bug report is rather sensationalist. At some point you just
| have to pattern match and ignore any reports that seems a bit
| too cranky. Is this ideal? No. But I don't see how it's any
| different than summarily dismissing a vaccine skeptic's claim
| that vaccines are bad, even if there's a kernel of truth buried
| in there (eg. that benefits for young people are questionable).
| kelnos wrote:
| > _" Cloudflare ended up completing patching the bug"_
|
| This short quote fragment is a little misleading: Cloudflare
| patched the bug in their systems that allow you to send HTTP
| requests to any CF data center, regardless of where the
| originator of the request lives. This is likely something they
| want fixed for a large variety of reasons, some probably much
| more important than the specific attack OP wrote about.
|
| > _I wish Signal would react differently._
|
| The severity of a potential security issue, or the
| determination of who is responsible for fixing or mitigating
| it, is a matter of opinion. Just because you think this is
| important for Signal to fix, it doesn't mean it's some absolute
| truth that it does. At the risk of appealing to authority, I
| would expect that people who run a security/privacy-focused
| messaging project to have a better handle on classifying these
| sorts of things than random people on HN like you or me.
|
| But of course, sometimes they'll get it wrong too. I'm not
| familiar with the bubble color thing you mention, but sure,
| nobody's perfect; we're all human and we make mistakes. I'm
| personally not convinced Signal needs to do anything here. A
| 250 mile radius is quite a large area, and users can already
| choose to not auto-download attachments. To be fair, though, I
| think a simple way for Signal to fix this would be to disable
| caching on the attachments HTTP endpoints, though that might
| increase their bandwidth bills and increase load on their
| servers, depending on what their access patterns look like.
| anon-3988 wrote:
| Wouldn't other user that sees the other person's profile picture
| also drum up the cache? This wouldn't work for someone in a large
| server.
| doctorpangloss wrote:
| I'm not sure how much if it makes any sense.
| Einenlum wrote:
| The attacker uses a patched version of Signal to be able to
| intercept requests and to block a get request to the attachment
| they have just created. At least it is my understanding.
| punnerud wrote:
| That's just to be able to use their APIs to get the location
| of the sender.
|
| Example you used the normal Signal app without patch and
| sending me a message, and I have the patched version.
|
| Just to remove certificate pinning, to be able to see the API
| traffic because of encryption.
| open-sesame wrote:
| Unless I'm missing something, this seems like an incredibly long
| winded way to check the users IP location?
|
| For example, connecting to a VPN and checking
| https://cloudflare.com/cdn-cgi/trace gives me `colo:CPH`
| (Copenhagen) which is far from my nearest CF datacenter
| (geographically), closer to the IP location from my VPN provider
| (Oslo) but still not particularly close?
|
| If I don't use a VPN, I don't even get the capital city of my
| country (which I'm in right now), I get a colo approx 250 miles
| north. So I also dispute that Cloudflare always returns the
| "nearest available datacenter".
|
| Don't get me wrong, the write up is cool and certainly
| interesting - just not convinced on the real world applications
| here...
| botanical76 wrote:
| Do you not buy that a user's IP location needs to be protected?
|
| There is a reason applications go to so much effort to proxy
| requests to resources such as images. It's not free to do this.
| ziddoap wrote:
| > _just not convinced on the real world applications here..._
|
| As a piece of data alone, the results are probably not of
| significant use.
|
| The real-world application (and potential danger) is when this
| data is combined with other data. De-anonymization techniques
| using sparse datasets has been an active area of research for
| at least 15 years and it is often surprising to people how much
| can be gleaned from a few pieces of seemingly unconnected data.
| gruez wrote:
| >The real-world application (and potential danger) is when
| this data is combined with other data. De-anonymization
| techniques using sparse datasets has been an active area of
| research for at least 15 years and it is often surprising to
| people how much can be gleaned from a few pieces of seemingly
| unconnected data.
|
| Seems pretty handwavy. Can you describe concretely how this
| would work?
| ziddoap wrote:
| > _Seems pretty handwavy._
|
| It has a whole Wikipedia article and everything.
|
| https://en.wikipedia.org/wiki/De-anonymization#Re-
| identifica...
|
| > _Can you describe concretely how this would work?_
|
| Here's one of the earlier papers I remember off-hand,
| demonstrating one methodology. New (and improvements to
| existing) statistical techniques have happened in the ~18
| years since this was published. Not to mention their is
| significantly more data to work with now.
|
| https://www.cs.utexas.edu/~shmat/shmat_oak08netflix.pdf
|
| _" We apply our de-anonymization methodology to the
| Netflix Prize dataset, which contains anonymous movie
| ratings of 500,000 subscribers of Netflix, the world's
| largest online movie rental service. We demonstrate that an
| adversary who knows only a little bit about an individual
| subscriber can easily identify this subscriber's record in
| the dataset."_
|
| From the Wiki I linked:
|
| _" Researchers at MIT and the Universite catholique de
| Louvain, in Belgium, analyzed data on 1.5 million cellphone
| users in a small European country over a span of 15 months
| and found that just four points of reference, with fairly
| low spatial and temporal resolution, was enough to uniquely
| identify 95 percent of them." [...] "A few Twitter posts
| would probably provide all the information you needed, if
| they contained specific information about the person's
| whereabouts."_
|
| Point being that operational security is hard, and it takes
| a lot less to "slip up" and accidentally reveal yourself
| than most people think. Obtaining a location within 250
| miles (or whatever) can be a key piece of information that
| leads to other dots being connected.
|
| Other examples (albeit with less explanation) include
| police take downs of prolific CSAM producers by gathering
| bits and pieces of information over time, culminating in
| enough to make an identification.
| gruez wrote:
| >"We apply our de-anonymization methodology to the
| Netflix Prize dataset, which contains anonymous movie
| ratings of 500,000 subscribers of Netflix, the world's
| largest online movie rental service. We demonstrate that
| an adversary who knows only a little bit about an
| individual subscriber can easily identify this
| subscriber's record in the dataset."
|
| > [...]
|
| "Researchers at MIT and the Universite catholique de
| Louvain, in Belgium, analyzed data on 1.5 million
| cellphone users in a small European country over a span
| of 15 months and found that just four points of
| reference, with fairly low spatial and temporal
| resolution, was enough to uniquely identify 95 percent of
| them." [...] "A few Twitter posts would probably provide
| all the information you needed, if they contained
| specific information about the person's whereabouts."
|
| The only reason the two attacks work is that you have
| access to a bunch of uncorrelated data points. That is,
| ratings for various shows and their dates, and cellphone
| movement patterns. It's unclear how you could extend this
| to some guy you're trying to dox on signal. The geo info
| is relatively coarse and stays static, so trying to
| single out a single person is going to be difficult. To
| put another way, "guy was vaguely near New York on these
| dates" doesn't narrow down the search parameters by much.
| That's going to be true for millions of people.
| ziddoap wrote:
| > _To put another way, "guy was vaguely near New York on
| these dates" doesn't narrow down the search parameters by
| much. _
|
| That's why I said that this data alone is probably
| worthless, but can gain value when combined with other
| data.( _" As a piece of data alone, the results are
| probably not of significant use"_)
|
| The combining of data is the important bit and the entire
| emphasis of both of my other comments.
|
| Two pieces of otherwise anonymous data can, when
| combined, lead to re-identification.
| gruez wrote:
| >Two pieces of otherwise anonymous data can, when
| combined, lead to re-identification.
|
| How are you going to get more anonymous data? Practically
| speaking if your target has such poor opsec that he's
| hemorrhaging bits of data, you probably don't need this
| attack to deanonymize them.
| ziddoap wrote:
| > _How are you going to get more anonymous data?_
|
| All over the place? Your comment history here (and mine!)
| is full of data. Each piece alone isn't identifying, but
| there's a good chance that in aggregate it is.
|
| If you share that username on
| discord/twitter/reddit/steam/whatever, that's even more
| data. If you reference old accounts anywhere, you guessed
| it, even more.
|
| > _you probably don 't need this attack to deanonymize
| them_
|
| My comment wasn't necessarily specific to this attack,
| just noting that this attack _can_ be an additional piece
| of data in the chain of re-identification.
|
| You've gone from " _not convinced on the real world
| applications here_ " to " _how are you going to get more
| anonymous data_ ". If we assume that you can get some
| data somewhere (a small list of example sources above),
| can we agree that there is, possibly, a real world
| application?
| kgeist wrote:
| I guess it can be useful for tracking fugitive political
| dissidents, terrorists, etc. If you can narrow their location
| down to 250 miles, it's already very useful information. And
| without raising any suspicions.
| vel0city wrote:
| It's not really narrowing it down to 250 miles; its narrowing
| it down to a circle whose radius is _at least_ 250 miles or
| ~196,000mi^2.
|
| My closest Cloudflare CDN is just listed as "DFW". The DFW
| metro area is about 8,700mi^2, and I imagine I could be even
| further than the "metro area" and still get the "DFW"
| Cloudflare datacenter.
|
| In their little video animation, the area inside the overlap
| of those two circles encompasses several states. The edges of
| the two circles go from Washington to Florida and almost
| include Chicago. The target could have been in Denver or St
| Louis or Las Vegas or Phoenix or San Diego or San Francisco
| or Amarillo or El Paso.
| kgeist wrote:
| I think it's still useful. Going from "we don't know where
| Osama bin Laden is at all" to "he's somewhere in Pakistan".
| vel0city wrote:
| If only we knew OBL's Discord handle then we would have
| known he was about where we figured he was all along...
|
| And then this whole thing gets thrown off if one uses a
| VPN with an endpoint somewhere other than where you are.
| Click a button, suddenly my datacenter is AMS. Click it
| again, suddenly its OTP...
| kgeist wrote:
| >If only we knew OBL's Discord handle then we would have
| known he was about where we figured he was all along...
|
| Discord is just an example, this can apparently work with
| many apps that store user attachments on Cloudflare.
|
| >Click a button, suddenly my datacenter is AMS. Click it
| again, suddenly its OTP...
|
| Well, if the location keeps changing, it's obvious it's
| not their real location. But if it's always the same, no
| matter what, that's a huge clue. Of course, this works
| best when you've got some other data to back it up. It's
| kind of like playing Akinator - the more answers you get,
| the closer you get to figuring out the target. One answer
| might not tell you much, but three or four?
| vel0city wrote:
| In their example target it pinged two datacenters, one in
| Dallas and on in San Franciso. Their requests might
| bounce between datacenters even if they aren't on a VPN.
| nkohari wrote:
| This assumes that Osama bin Laden has poor enough opsec
| that he's using (eg.) Discord without a proxy. State
| actors have much more sophisticated techniques available.
|
| (It's still an interesting vector, though! But it's true
| that the headline and writeup are a bit sensationalized.)
| lxgr wrote:
| Having your IP address not revealed to people that can message
| you on Signal seems like a pretty reasonable privacy
| expectation.
| gruez wrote:
| Your IP isn't revealed though, only your vague geographic
| area.
| lxgr wrote:
| That's marginally better, but can still be a problem. Just
| consider e.g. a whistleblower working for a company with a
| very small satellite office in a given country.
| udev4096 wrote:
| Did you even read it? There's no IP leak. And if you're a
| high target, then using some kind of proxy is literally the
| first step you take. The attack is nothing but an
| exaggeration and has no merit in real world
| lxgr wrote:
| Yes, I read it. Information about your IP address is
| leaked, as that's how Cloudflare routes you to a given
| datacenter.
|
| And I strongly disagree that being able to uncover
| somebody's rough geographic location is not a privacy
| problem.
|
| I wouldn't be surprised if this, for example, lets you
| deduce if somebody is currently home, at work, or commuting
| (as all three ISPs might be hitting different Cloudflare
| datacenters). That's not information everybody is
| comfortable broadcasting to the world.
| udev4096 wrote:
| If you aren't comfortable broadcasting it, then maybe
| take measures so that it doesn't get to that point.
| Privacy is not by default, ever
| lxgr wrote:
| To quote Signal themselves:
|
| > Privacy isn't an optional mode -- it's just the way
| that Signal works. Every message, every call, every time
| [1]
|
| While I don't consider this a critical bug requiring an
| immediate technical remediation from Signal, this should
| definitely be either fixed or called out in the
| documentation at some point.
|
| [1] https://support.signal.org/hc/en-
| us/articles/360007320391-Is...
| udev4096 wrote:
| They also use AWS so good luck using it on your actual IP
| HeatrayEnjoyer wrote:
| Privacy by default is Signal's entire brand
| zild3d wrote:
| > Unless I'm missing something, this seems like an incredibly
| long winded way to check the users IP location?
|
| It's less accurate than that. IP Geocoding can be down to the
| city level in many cases. This is _maybe_ nearest cloudflare
| data center
| maverick74 wrote:
| Would be very interesting to see how other IM behave with this:
|
| For example: Jami - one of the most feature-complete, distributed
| IM...
| walkerbrown wrote:
| Nice work OP, and congrats on HN front-page. Keep publishing or
| it never happened!
| ryao wrote:
| Usually, being identified as being part of such a huge group that
| there is no chance of being found is an example of anonymization,
| rather than deanonymization. The author might not like that there
| is any potential to narrow things down at all, but the
| information provided by this could be easily wrong if a VPN were
| used to have the traffic egress through a different geographic
| region.
| aimazon wrote:
| What's old is new. Does anyone remember the forum signatures that
| would display the viewers IP address and location on a little
| wooden signpost held up by a troll-looking creature?
|
| https://cdn.geekzone.co.nz/images/forums/danasoftcache.jpg
| alp1n3_eth wrote:
| Just like the days of DoSing an IP from a COD Lobby
| catlikesshrimp wrote:
| That was a troll feature. It usually showed any user his own
| information.
|
| MAYBE some forum doxxed users by posting their informatio? but
| I didn't see any.
| giancarlostoro wrote:
| My friend would figure out the username, but he never did it
| maliciously, just for the challenge. Forums would show you
| which user was viewing a thread...
| giancarlostoro wrote:
| Had a friend who made his own nice one, would then visit the
| thread, and figure out "who is viewing it" and show your
| username. ;)
| kostadin wrote:
| I was fascinated by this once I learned how it worked. At the
| time I was learning php and wrote a script that would draw
| graphics based on the requesting ip address and return as gif,
| then used that as my avatar on a few phpbbs. Learned a lot.
| yapyap wrote:
| > it's possible for an attacker to run a cache geolocation attack
| to find out which local datacenter they're near--similar to how
| law enforcement track mobile devices through cell phone towers.
|
| very much disagree on this, they track mobile devices through
| your connection strength to multiple cellular towers while this
| attack proves which singular datacenter the victim is nearest.
|
| Don't get me wrong the write up is really interesting but it does
| feel like the author is a bit of a sensationalist.
| some_furry wrote:
| > Don't get me wrong the write up is really interesting but it
| does feel like the author is a bit of a sensationalist.
|
| They claim to be 15 years old. Cut them some slack.
| r4victor wrote:
| Their twitter says
|
| > Joined November 2017
|
| so likely a bit older :)
| some_furry wrote:
| Ah, that's true. They even have HackerOne activity from 8
| years ago:
| https://hackerone.com/daniel/hacktivity?type=user
|
| So either they lied about their age then in order to join
| social media and they're some sort of child prodigy... or
| they're lying now.
| xnorswap wrote:
| Or that hackerone account has been traded.
| hackermondev wrote:
| that's a hackerone bug, that 8-year-old report is not
| mine :)
| spzb wrote:
| It's clearly a different username on the 8 year old
| report.
| creaturemachine wrote:
| It's not unfathomable for a precocious 8yr old to register
| for an account, with or without parental guidance.
| dare944 wrote:
| "bit of a sensationalist" is reasonable feedback; no slack
| needed. After all, this is how they learn.
| some_furry wrote:
| It would probably be better for such learning to occur in a
| place that doesn't create immutable records of judgments
| from one's peers; i.e. Hacker News comments.
| j3s wrote:
| people learn when they're given kind, direct, actionable
| feedback from people they trust - not when they're called
| sensationalists by random critics on the internet.
|
| what have you made lately?
| gruez wrote:
| >people learn when they're given kind, direct, actionable
| feedback from people they trust - not when they're called
| sensationalists by random critics on the internet.
|
| So what are we supposed to do? Dox him, find who his
| friends are, and use them to backchannel feedback? I
| think the "sensationalist" critique is direct and
| actionable - just don't do it.
| kelnos wrote:
| I think "this writing is sensationalist" is constructive,
| actionable feedback.
|
| And I think expecting that all criticism must come from
| people the target of it knows and trusts is a bit much.
|
| > _what have you made lately?_
|
| Plenty of stuff. But that's irrelevant. People are free
| to give feedback regardless of what they've been working
| on.
| redcobra762 wrote:
| No.
| vel0city wrote:
| > through cell phone towers
|
| Extremely sensationalist. A cell tower might have a range of a
| few miles, _max_. This is giving ranges of 250+mi.
| mapcars wrote:
| While the detection area of the cloudflare attack is bigger I
| think the main problem here is that its much easier to get
| access to it than to cellphone towers.
| alp1n3_eth wrote:
| Cool writeup with some interesting techniques and approaches!
|
| I'll echo the other comments and say "deanonymization" is
| stretching the definition of the word, along with "grab the
| user's location", as it isn't anything near precise. 150 miles is
| approx. a 2-hour drive on the highway from Atlanta, GA to
| Augusta, GA. In that radius, there's probably 700,000+ people.
|
| I do think the auto-retrieve attachment feature of Signal is
| slightly concerning, as for a private messenger I'd expect there
| to be an option to turn it off (like turning off JS in Tor). I
| don't know if I'm not looking deep enough, but there doesn't seem
| to be a feature for that.
|
| Signal appears to take a useful-by-default approach that balances
| privacy and ease-of-use in order to encourage adoption by the
| masses, I'd assume most people that are really concerned are
| hardening Signal, similar to what is in this guide:
| https://www.privacyguides.org/articles/2022/07/07/signal-con... .
| They've always recommended a VPN / proxy + a modification of
| settings for more high-security scenarios.
|
| Caching isn't going anywhere, and neither is CloudFlare. The
| DoSing days of old in P2P multiplayer lobbies with exposed IPs
| seemed to carry more of a threat than this, CloudFlare's response
| seems to be the best out of the 3. Caching sensitive information
| is never recommended and the onus is on the application doing the
| communicating to tell their CDN / middle-service to not cache
| specific items.
| vel0city wrote:
| You can disable the auto-download. Settings > Data and storage
| > Media auto-download, you can choose what to auto download for
| mobile data/wifi/roaming.
| alp1n3_eth wrote:
| Thank you! That's what I get for quick scrolling through the
| settings. I for sure thought it would have been under Privacy
| (for this concern), but that makes sense too.
| LWIRVoltage wrote:
| So, just to confirm my understanding, if one goes into
| those settings and disables all auto-download, that helps-
| but, then a user will manually download images, correct?
| Are they still vulnerable to this issue then at that time?
| vel0city wrote:
| A user might download images and yes, if they download
| images Cloudflare will show which datacenters have cached
| that image. They might also install an APK you give them
| or run that taylor_swift_concert.mp4.exe as well.
|
| If I host an image on Cloudflare and put the URL here,
| I'll know which CF datacenters are near HN users who
| bother clicking the link as well.
| tribby wrote:
| it looks like it can't be disabled for view-once media (or at
| least, that's what the settings screen says)
| vel0city wrote:
| I wonder if view-once media is even handled the same way as
| a regular attachment (using CF) or is sent more like a
| regular message.
|
| I imagine if one really wanted it to be view-once, it
| wouldn't go to a CDN.
|
| Thanks for pointing this out!
| jrochkind1 wrote:
| I think view-once media there means media hosted on
| signal servers, not remote servers? But not entirely
| sure.
| vel0city wrote:
| I'd love a hard answer to this if anyone knows or has
| time to look at the source code.
|
| https://github.com/signalapp
| gorfian_robot wrote:
| hmm. I find the auto-download setting in the mobile app but
| not on desktop (mac). anyone know?
| gorfian_robot wrote:
| (some comments seem to suggest that the desktop app always
| auto-downloads)
| giancarlostoro wrote:
| > "deanonymization" is stretching the definition of the word,
| along with "grab the user's location", as it isn't anything
| near precise.
|
| You'd think so, but you would be surprised how quickly this
| adds up to other details people share, like "oh I just drove 15
| minutes to get Starbucks" or something to that effect, small
| things that eventually add up to a precise location over time.
| alp1n3_eth wrote:
| > you would be surprised how quickly this adds up
|
| Yes, but if social engineering is involved and tracing back
| through user conversations across a platform, it's hardly a
| vulnerability, let alone one deserving of a bounty. The way
| this is currently functioning is intended functionality, and
| can be further locked down depending on the user's threat
| model.
|
| This can essentially be classified as opsec failure for the
| Signal user. If they're trying to hide from a hit in a 300
| mile radius, they've got bigger problems to worry about, and
| should already be using a VPN setup.
|
| Every time you click on a link your external IP addresses is
| exposed, is this a vulnerability? Being online without a VPN
| / proxy is inherent consent to have your external IP & other
| required items to be shared with services / middlemen.
|
| When it comes to Discord, if you have this strict of a threat
| model and you're still using it, idk what to tell you.
| hmottestad wrote:
| If I can send you a link and be guaranteed that you click
| on it. Then that's definitely a security issue.
| giancarlostoro wrote:
| > When it comes to Discord, if you have this strict of a
| threat model and you're still using it, idk what to tell
| you.
|
| I mean, you just never know... I've seen a lot of wild
| things, I've seen what drives people to doing crazy things.
| Just look up the "Deadly Runescape E Dater" who flew from
| the US to the UK to stab the girl he e-dated.
| mmooss wrote:
| This is all the classic dismissals of security issues,
| including blaming the user.
|
| > opsec failure for the Signal user
|
| Signal's mission is to provide security for users who don't
| know the word 'opsec'.
| alp1n3_eth wrote:
| Blaming the user is sometimes what it boils down to.
| Security includes a balancing act that involves
| usability, and Signal is firstly targeting the masses,
| but includes settings that can be configured for high-
| risk scenarios.
|
| This "vulnerability" requires the user to have none of
| the normal things a person with a more extreme threat
| model would have already configured. EZPZ guides online
| on locking down Signal.
|
| It's just like an iPhone. They don't ship with Lockdown
| Mode enabled by default, as it hurts the average
| consumer's usability. Signal at minimum will ensure no
| one is snooping on your messages, and it's up to the user
| whether they want to take that further.
|
| If your definition of not providing security is allowing
| someone to know they exist on a continent, then that
| user's ISP has performed terribly as well since they
| aren't bouncing their signal around the world by default.
| mmooss wrote:
| > Blaming the user is sometimes what it boils down to.
|
| At least we agree about your argument. :)
|
| > Signal at minimum will ensure no one is snooping on
| your messages, and it's up to the user whether they want
| to take that further.
|
| Signal also secures metadata, including the participants
| in the conversation. That is undeniable - they have gone
| through considerable development investment to provide
| that feature.
|
| > that user's ISP has performed terribly
|
| Now we're blaming the ISP. If your app doesn't work with
| your users and ISPs, who does it work for? And how does a
| non-technical end-user know whether or when to trust you?
| why_only_15 wrote:
| Random unrelated point: in a 100km radius circle between
| Atlanta and Augusta there are ~2,000,000 people (calculated
| using https://www.tomforth.co.uk/circlepopulations/ )
| powerhugs wrote:
| For being 15 year old, cool work!
|
| But calling this de-anonymization is a stretch, if it can
| possibly pinpoint you within 250 miles (that's assuming geoip is
| correct too, which it rarely is).
|
| In their GeoGuesser demonstration video, the higlighted area is
| densely populated and you still would need to match millions of
| people vs the online user.
|
| It does provide some hints as to the location of the targeted
| user, and that is cool!
| nunobrito wrote:
| It is already more than enough to know which country to contact
| the authorities and to pinpoint a rough area where to look.
|
| If the scammer is in Nigeria, tough luck. If he is in the EU or
| US then exists a feasible chance to go after the person.
| SahAssar wrote:
| > assuming geoip is correct too
|
| It's not using geoip, it's using anycast.
| eugenekolo wrote:
| Can probably achieve the same level of deanonymization by just
| monitoring what times the user communicates most often. Or send
| them enough links that they'll click on.
| treksis wrote:
| impressive
| LWIRVoltage wrote:
| Am I correct in surmising that someone who uses aVPN on their
| phone, while sending Signal messages/ content, would be cloaked,
| provided the VPN server they pick isn't near them ?
| nunobrito wrote:
| Yes, that is correct. VPN near location would be disclosed, not
| yours.
| sitkack wrote:
| You could use this technique to see what geographic areas view
| what sites based on the content cache age, you would have to have
| the list of sites, but it would allow you to bucket a geographic
| by top sites from the test corpus.
| herczegzsolt wrote:
| The accuracy of this geolocalization depends very much on peering
| agreements.
|
| I don't know about the UD bit this will not be very accurate
| within the EU.
|
| As an example: In Hungary, there's pretty much only one peering
| hub (bix) and there's only one Cloudflare datacenter. You've
| already geolocated me better than this hack just by knowing my
| language or phone prefix.
| Einenlum wrote:
| It's not because you have a Hungarian number that you're not
| travelling somewhere else. I don't really understand the point.
| herczegzsolt wrote:
| When I am traveling, i most likely use my mobile data. That
| data is tunneled to my mobile provider, exiting to the public
| internet at exactly the same server.
|
| In my case, Cloudflare will identify me as BUD even when i'm
| roaming at a different country.
|
| This behavior is very typical for the EU, because the telco
| landscape is fairly fragmented, and each company typically
| have only one, or at most 2 peering locations.
|
| This may be different within the US where the distances are
| bigger, and latencies matter more, so there is more incentive
| to peer locally.
| aaurelions wrote:
| If you need to deanonymize a user who moves around a lot, this
| method makes sense.
| nine_k wrote:
| So, it's like the [Spectre] attack against CPUs: trigger an
| access from a privileged context, check if the access has filled
| in some cache, infer privileged information from that.
|
| It seems that time and again, security-enforcing procedures
| assume that many functions they invoke are pure, but in reality
| these functions have side effects, and these effects are
| observable much easier than the security requires.
|
| The actual problem here that the secured area is _only_ the stuff
| that came through the encrypted channel. Any access beyond it,
| like following a link, is obviously insecure. If the link was
| sent via the secure channel, it becomes _even less_ secure
| because it allows to observe a correlation between the secure
| channel (otherwise impenetrable) and the insecure outside
| context, and allows to blow (some of) the cover. Opening links
| via Tor would mitigate it a bit.
|
| The hard truth here is that almost everything may have observable
| side effects, so opsec needs to permeate all aspects of life, the
| more cover you need, the fuller. This is mostly incompatible with
| a convenient UX, but, to be popular, a secure messenger has to be
| reasonably convenient. This necessarily limits the level of
| security attainable by its casual use.
|
| [Spectre]:
| https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
| Mystery-Machine wrote:
| Why does CloudFlare return whether it was a cache hit or miss?
| This information could be hidden/removed. I understand it's not a
| complete solution of the issue, because cached responses will
| return much faster than non-cached ones, but it's a step in the
| right direction.
| cesarb wrote:
| It seems to me that a key requirement for this attack is that
| both the attacker and the victim load the same link, that is,
| that the attacker knows the URL the victim is going to load. If
| Signal/Discord created a different link to be given to the
| victim, and never shared it with the attacker, this attack
| wouldn't work.
|
| That could be as simple as adding some extra pseudo-random
| parameters to the URL which will be ignored by the origin (but
| honored by the caches), or as complex as creating a completely
| separate URL for the receiver of the message, and somehow giving
| it to the receiver without giving it to the sender (easy on
| Discord, harder on Signal due to its end-to-end nature).
| layer8 wrote:
| Since creating separate URLs would largely defeat the purpose
| of caching, a simpler solution would be to just disable
| caching, as Cloudflare suggested in their response.
| udev4096 wrote:
| Clever finding but the title does no justice to the actual
| attack. Even a bare minimum threat model requires a user to use
| VPN or Tor which completely eliminates your "0day". Signal
| rightfully declined your report because it's only job is to
| provide secure communication
| lxgr wrote:
| Signal is definitely also aiming to provide metadata privacy,
| which they understand to be part of secure communication.
|
| Otherwise, they wouldn't pad attachment and message sizes,
| offer a "sealed sender" feature, allow relaying all calls to
| avoid callers/callees from learning users' IP addresses etc.
| mmooss wrote:
| Signal is intended not for HN readers, but for ordinary people
| who don't understand VPNs and Tor.
| ementally wrote:
| Not exactly the same type of attack, but very similar
| https://cyberinsider.com/timing-attacks-on-whatsapp-signal-t...
| cedws wrote:
| Unfortunate that Cloudflare patched the issue enabling specific
| datacenters to be targeted. Would have been extremely useful for
| finding the location of servers behind Cloudflare.
| thayne wrote:
| What is the benefit of caching images in a cdn for Signal?
|
| Assuming local client-side caching, the total number of requests
| for that resource should be very small, probably one in the vast
| majority of cases.
|
| On an unrelated note, it seems like CloudFront could very easily
| fix this by not returning the cf-ray header, or at least having
| an option for the customer to remove it. Although, it might still
| be possible to get that information based on timing
| information...
| dualogy wrote:
| > the total number of requests for that resource should be very
| small
|
| "For that server" is the other number-of-requests..
| popcalc wrote:
| So that law enforcement can ask Cloudflare for the IP logs...
| Signal is a joke.
|
| https://simplex.chat/
| modeless wrote:
| Yes, Cloudflare should allow customers to disable that header,
| and Signal shouldn't cache images sent to a single person, or
| even groups of less than a few hundred people.
| jrochkind1 wrote:
| I dont' believe the Signal app/network is choosing to
| cacheimages in a CDN?
|
| But any user can send anyone other user a message that includes
| a link to a CDN-cached resource. Isn't that the "attack" here?
| Or am I misunderstanding?
| aprilnya wrote:
| Signal does cache them in a CDN. If the vulnerability was
| sending any link, you could just set up your own web server
| and get the person's IP
| jrochkind1 wrote:
| Ah, and the attack is knowing what CDN that is that signal
| itself is using, and examining it directly? I had missed
| that somehow.
| angry_octet wrote:
| It isn't caching, it's CDNing. It is just an artefact of CDNs
| that they act as caches for the original content, and for
| improved distribution response time they cache to the nearest
| server from the response. ('Nearest' being an approximate
| heuristic, it is property of the anycast route tables in the
| BGP routers the request passes through, it is actually a 'best
| route'.)
| moralestapia wrote:
| Pretty impressive work.
| maxrmk wrote:
| Cool! Contrary to some of the other posters I think this
| definitely counts as deanonymization, or at least is close
| enough. How anonymous would satoshi be today if we had his
| location to within 250 miles?
|
| Repeated applications of this attack (maybe disguised somehow?)
| could let you track someone's travel over time, and it is usually
| only takes 4-5 zip code sized locations to uniquely identify
| someone.
| cenamus wrote:
| How many people live in a 250 mile circle around New York?
| everfree wrote:
| I think the more important question is how many people in the
| world _don 't_ live within a 250 mile circle around New York?
| An investigator could potentially cut their geographical
| search down by 95%+.
| modeless wrote:
| Also the attack can be performed multiple times and if a
| person travels it could narrow down the possibilities quite
| a lot.
| vel0city wrote:
| They had an example of the attack getting two locations
| back, Las Vegas and San Francisco.
|
| So the target is somewhere in the many thousand square
| miles in the circle that encompasses almost half the US!
| sureIy wrote:
| Let's say they travel between NY and LA, how many sources
| of data will you need to know who was in NY on a specific
| date and LA on a second date? Feels like only the
| government can reasonably locate that.
| modeless wrote:
| The government is a plausible adversary for Signal
| int_19h wrote:
| FWIW if it's the government, wouldn't they be able to
| just get direct access to Cloudflare logs - in real-time
| even - and thus observe and track the specific incoming
| connection to fetch the cached image?
| kachapopopow wrote:
| You can already do the same with advertisement ID in (almost)
| every single one of these applications.
| aimazon wrote:
| The counter point is that anyone who cares about being
| anonymous is using methods to disguise their identity that
| cannot be compromised by this attack, e.g: a VPN. Plus, there
| are much more effective versions of this attack, like sending a
| link to an endpoint that you control -- getting someone to
| click a link isn't hard if you're considered trustworthy enough
| to send them notifications. And less technical versions, like
| correlating when the user is online vs. offline with timezones
| around the world.
|
| The method that both Apple and Cloudflare use in their own
| privacy software (iCloud Private Relay for apple, WARP for
| Cloudflare) is specifically based on the idea that your region
| is not information that reveals your identity. If you enable
| Apple Private Relay, your origin IP will be obscured but the IP
| your traffic is routed through will be in the same country --
| same principle.
|
| https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overv...
|
| This attack is academically interesting and novel but it's not
| "deanonymization".
| rosseitsa wrote:
| I am not sure I understand what you mean by "trustworthy
| enough to send them notifications". Do you need anything
| other than one's phone number to send them a signal message?
| byearthithatius wrote:
| Still quite anon. He almost certainly used a VPN, and if he
| didn't he likely lived in a major city which included thousands
| if not hundreds of thousands of capable engineers. If it said
| he was in SF during some messages that would tell us literally
| nothing.
| meowface wrote:
| Satoshi's possible home IP address actually did leak shortly
| after Bitcoin's release, though it wasn't realized until years
| later.
|
| (It definitely may not be him and might instead be a random
| early user. But I think there's a moderate chance it's him.)
|
| Details: https://news.ycombinator.com/item?id=29728339
|
| (I don't advocate attempting to find and publish his name and
| address, since it'd make his life difficult, but it's still
| very interesting in the abstract as a curious unsolved mystery
| for all these years despite the number of eyes on it.)
| kevindamm wrote:
| There was mention that the Teleport tool no longer works after
| the bugfix of the underlying issue (calling other cf locations
| via Workers and an internal subnet). It seemed like the ability
| to query which caches HIT on the dye-test image relied on being
| able to call out to each other DC.
|
| Without this control over the route (driving the probing of which
| caches were hit), the attack would no longer work, right?
| devmor wrote:
| There is another method to query the caches. This is mentioned
| in the article.
| kevindamm wrote:
| Ah, the VPN deployment which probes from various geographies?
| It has limited coverage (according to author, about 54% of
| all Cloudflare datacenters) but still a sometimes-working
| attack, granted.
|
| However, Cloudflare are known for being harsh on VPN exit
| points and the behavior of requesting the same (unique each
| pass) image from every geography and then never again, would
| probably look significantly suspicious, but yeah it seems not
| to be a priority for cloudflare at the moment.
| jdthedisciple wrote:
| why is the picture not simply cached near the sender as opposed
| to the receiver?
|
| is there any good reason for deciding this way on the part of
| Signal et al?
| pornel wrote:
| The attacker can't be forced to make a request. In this PoC the
| attacker disabled their own outgoing image requests.
|
| But that wouldn't help anyway, even if the image could be
| cached near the sender first, or the signal server prewarmed
| some other cache. After the victim opened the image, the
| attacker would see two locations that have the image cached,
| and could easily deduce which one is the victim's location
| (e.g. if Signal pre-warmed a random cache, repeating the attack
| a couple of times would be enough to eliminate the randomness).
| mmooss wrote:
| It's cached near the receiver for performance purposes, I
| assume, the same reason Cloudflare uses geographically local
| caches.
| kovariantenkak wrote:
| Looking at the locations where Cloudflare has their servers [1]
| in the middle of Europe. With Geneva, Zurich and Munich there is
| definitely the possibility that this attack on Signal will leak
| whether someone is at home or not.
|
| I don't understand how Signal could dismiss this so easily. I'm
| starting get a bad feeling about their responses to these "low"
| stakes attacks. They already missed the ball on the database
| encryption mishap on desktop.
|
| [1]: https://www.cloudflare.com/network/
| devmor wrote:
| This is an extremely cool avenue of attack, I love the
| bot/demonstration.
| croemer wrote:
| Cool writeup by a 15yo, except for the way it completely
| oversells in the title.
|
| Basically this allowed an attacker to find out which cloudflare
| data center a victim connected to when being tricked into loading
| something from cloudflare. This is often within a 250 mile radius
| of where they're living but not necessarily.
|
| Can't one find out someone's IP just as easily by making them
| make a request to a URL controlled by an attacker? Is the problem
| that cloudflare is whitelisted for 0-click?
| 9sIX3oZ1JB5 wrote:
| Might even argue that the title is good because it made us
| click
| AceJohnny2 wrote:
| > _Can 't one find out someone's IP just as easily by making
| them make a request to a URL controlled by an attacker?_
|
| Unless you can find another flaw in Signal, that'd likely be a
| 1-click attack, which is less valuable than the 0-click attack
| demonstrated by the author.
| Kaibu wrote:
| "Luckily" my ISP is DTAG which has horrible peering with
| Cloudflare. So I'm routed through Warsaw (WAW) most of the time,
| even though there are multiple closer datacenters in Germany.
| lxe wrote:
| Not sure why so many top comments dismiss the severity of this.
| This is just exactly the type of attack that give law enforcement
| or a malicious actor a way to establish proof of whereabouts.
| byearthithatius wrote:
| I would guess some are just jealous of his age, but some do
| find the claim of de anonymizing to simply be overblown given
| it doesn't tell you nearly enough to find anyone except in very
| niche cases. This "attack" is easily defeated with a VPN or
| living in any major city.
| gtsop wrote:
| Interesting you touched on his age. I got extremely curious,
| why did the OP did such a flex?(assumming they are telling
| the truth). The first sentence is such a weird brag that it
| felt suspicious. The report is highly technical and extremely
| well written. We're either dealing with a pure genious or a
| fraud. But why would a genious flex? Doesn't make sense.
| adamrezich wrote:
| I don't know what you think is genius about any of this,
| but you're right, the flex is odd. It's something I've been
| seeing more and more of lately, and I find it off-putting,
| because, Back In My Day, I never had such a phase, where I
| felt like I should be given more credit for my 1337 h4xx0r
| skillz, because I was in high school or whatever--and I
| don't remember anyone else doing it, either.
|
| I can only assume this is a consequence of modern social
| media having shifted the Internet from being a bunch of
| pseudonymous people making and sharing stuff, to everything
| being myopically focused on one's identity _first_ , and
| what they do _second_ (as is _literally_ the case here).
|
| And it looks like it works to achieve its desired effect,
| too--a significant portion of the comments here are
| congratulating the guy for doing such a thorough technical
| write-up, given his age. Maybe this is just me being a
| grumpy "old" man now, but I would've found that
| condescending when I was his age, and would've rather
| concealed my age than be condescended to as such. But, to
| each his own, I suppose.
| gtsop wrote:
| I find genius being 15 and being in a state to find this
| issue and write this report. For my understanding there
| is a ton of context and knowledge packed in this write-up
| which i can't possibly imagine myself being able to grasp
| it at the age of 15. That is not to say it's not
| possible, but it goes to say it is very hard, that's why
| i characterise it as genius
| iforgot22 wrote:
| I can see a very talented 15yo pulling this off. But the
| number of anonymous "I'm 15 and this is my impressive feat"
| posts on HN make me wonder if it's just a joke.
| gtsop wrote:
| I believe most people (me included) dismiss the OP's claimed
| severity, as if it is being oversold. I see a balance of
| opinions saying "great find, but not as critical as claimed" so
| they don't seem dismissive. It is important to correctly
| classify the severity of issues. Proof of whereabouts is not
| deanonymization, especially when the abouts are so loose
| mmooss wrote:
| They dismiss it for the same reason people dismiss disruptive
| new technology - they are uncomfortable with it. It's a signal
| (ha) that the threat is very real.
|
| First dismiss it and see if the problem is still there in the
| morning. Hope that before then, someone finds a reason it's not
| a problem. Anyone?
| jrochkind1 wrote:
| I guess signal preview-loading or remote-image-loading features
| are always going to be usable to identify broadly what region a
| user is in, using this attack.
|
| Can one disable those features in Signal? Would be annoying
| becuase they are nice, but yeah.
|
| If you don't want that attack to be able to locate you somewhat
| (or at least locate your internet endpoint, if you are using a
| VPN or something), you will need to turn off signal previews and
| network image displays. Right?
| Einenlum wrote:
| I guess one possible fix would be for cloudflare to implement an
| option to disable the x-cache header for unauthorised users. This
| way Signal devs could still check their setup by sending
| authentication headers.
|
| But it would solve the issue completely because you could always
| check the response time. Probably Signal should disable caching.
| I guess it's rare for someone to repeatedly download an
| attachment. Once it's there it's there. For grouped conversations
| it could be an issue though.
| byearthithatius wrote:
| I think its good for finding out if someone is still in a certain
| region. More like region identification not deanonymization.
| kelnos wrote:
| Why has Signal even enabled caching for those URLs? The most
| common case is going to be that the attachment is downloaded
| once, and that's it.
|
| I would even expect that Signal wouldn't _allow_ you to download
| it more than once, and would immediately delete it after the
| first successful download. Well, ok, maybe the client fails mid-
| way through, so allow some grace period for a re-download. But I
| can 't imagine that would be the common case either, and so
| disabling caching on their CDN would fix this issue, and
| hopefully not increase their costs much.
|
| At any rate, "deanonymization" is a bit clickbaity here.
| Narrowing someone's location to within 250 miles or so isn't
| great, but it doesn't deanonymize them.
|
| Edit: I didn't think about the case where an attachment is sent
| to a group chat, where multiple people will be downloading it.
| But in that case wouldn't the attachment be encrypted
| individually for each person in the group? I'm not sure how this
| works, of course.
| alp1n3_eth wrote:
| Signal's default setup is more usability focused while
| supporting E2E, and less about tinfoil hat threat models about
| being present on a continent you're a citizen of.
|
| The items you mentioned can essentially be configured, for
| those that want the insane level of privacy / security.
| Messages can be auto-deleted 30 seconds after being seen, a
| proxy can be configured to route all your traffic through it,
| and tons of other things can be done to customize it more to
| the user's liking.
|
| I'd imagine they're caching it because of egress costs. File
| attachments, voice mail, video, etc. can all add up.
| mqus wrote:
| > Signal's default setup is more usability focused while
| supporting E2E
|
| If images/attachments were e2ee, this problem probably
| wouldn't exist, right? or are the images on cloudflare
| encrypted?
| notatoad wrote:
| This is just the fundamental way the internet works, and is the
| reason that anonymizing proxies like Tor exist.
|
| If you don't want people to be able to detect your rough
| geographic location, you should be using a proxy to hide it. For
| everybody else, knowing the edge server you are closest to is
| really not a threat.
| mmooss wrote:
| People for whom it's a threat don't necessarily understand
| anonymizing proxies - very few do. Signal is supposed to
| provide security for those who do not.
| honestSysAdmin wrote:
| I guess I'm not so "crazy" for funneling all my Android's
| outbound traffic through a VPN that does two hops.
| ryanisnan wrote:
| Great job, you're going to go far Daniel.
| moktonar wrote:
| Guess what: you don't need cloudflare
| joshfraser wrote:
| It's a classic timing attack. You can detect which Cloudflare
| datacenter is "closest" (ie. least network latency) to a targeted
| Signal or Discord user.
|
| The speed of light is the main culprit here.
| punnerud wrote:
| Is he just 15? The level of technical details, and this part is
| not that simple: "quickly patched the Signal desktop app to
| remove SSL pinning and configured Burp to intercept and view HTTP
| requests/responses sent through the app"
| coffeeboy27 wrote:
| You'd be surprised at how adept the younger generation can be,
| especially those who've grown up with technology. As tech
| evolves, so do they. There are kids who genuinely apply
| themselves, and because they've been immersed in this
| environment, it's practically second nature to them. I remember
| the late 1990s: I was young, but more than anything, I was
| curious about how things worked, I had the luxury of time, and
| access to technology to explore it. I started coding in C++
| when I was around 13, and honestly, I still feel like I started
| too late.
| tga_d wrote:
| A fun attack, but I don't think this is a significant improvement
| over the existing state of the art using delivery receipt timings
| ("Hope of Delivery"). https://arxiv.org/pdf/2210.10523
| Havoc wrote:
| Surprised that was only worth 200 bucks.
| rapatel0 wrote:
| de-anonymization attack?
|
| - The information extracted is a rough 250 mile radius around the
| user
|
| - The attacker already has a way to contact the person (signal
| username / phone number)
|
| Intersting reading, but also seems like technical clickbait.
| flagos10 wrote:
| Just by the fact he's expressing distances in miles, I can say
| he's from USA.
|
| That's my 0-click deanonymisation.
|
| Nice attack otherwise.
| Funes- wrote:
| >Just by the fact he's expressing distances in miles, I can say
| he's from USA.
|
| And you could be falling into his trap of getting you to
| believe so by expressing distance in miles, as well.
| ritcgab wrote:
| Imagining the cloudflare datacenters as cachelines and this is
| just like a side-channel attack like spectre. Not as fine-grained
| but still cool stuff.
| scottydelta wrote:
| How is it different than sending someone an image hosted on your
| server which is a tracking pixel and just get their IP+location?
|
| This will be more accurate than the cloudflare approach.
| quotemstr wrote:
| You can't instruct a random Signal client to fetch a random
| URL. Here's how this attack works:
|
| 1. Attacker sends novel image to Signal
|
| 2. Signal hosts the image on their core servers
|
| 3. Signal instructs victim to fetch preview of the image
|
| 4. Victim asks the CDN for the image
|
| 5. CDN gets the image from Signal core servers and caches it
|
| 6. Victim gets the image from the CDN and displays the preview
| normally
|
| 7. Attacker hits _every one_ of the CDN cache servers
|
| 8. The CDN cache server that say "yep, saw that already" is the
| one closest to the victim
| 0xCMP wrote:
| Well, unlike with tracking pixels, you are not in the direct
| request path and cannot block it. You also have no way
| monitor/log if it is happening (like you can in theory with a
| packet capture).
|
| It's obvious in hindsight, but I bet no one would have
| mentioned this possibility as why you should disable
| notification previews or that simply receiving a notification
| would possibly reveal this information.
| iforgot22 wrote:
| It might be hard to get the target to load that image because a
| lot of apps have caught onto that technique. It used to work
| for iMessage even.
| tech234a wrote:
| Note: this person is the same 15-year old who found the Zendesk
| Slack takeover exploit a few months ago [1].
|
| [1]: https://news.ycombinator.com/item?id=41818459
| ingohelpinger wrote:
| is simplex immune?
___________________________________________________________________
(page generated 2025-01-21 23:00 UTC)