Administered by:
Update Signal and pay attention when joining groups:
https://www.wired.com/story/russia-signal-qr-code-phishing-attack/
No, Signal has not been compromised No, Signal encryption has not been broken No, there is no back-door in Signal
You should continue using Signal. The update is responding to a sophisticated, state-level attack targeting specific groups.
Unless you are a high-value target, you are almost certainly never going to see this in the wild.
If you know you are a high-value target, ask your support.
Technical details in the report:
https://cloud.google.com/blog/topics/threat-intelligence/russia-targeting-signal-messenger
The tl;dr is:
Signal uses https://signal[.]group/#hash-fragment links in QR codes that allow people to join groups. Group identifier is in the hash-fragment.
The link loads in a browser first. A bit of JS redirects it to a sgnl://signal[.]group/hash-fragment link that is then handled directly by Signal app on mobile.
Malicious QR codes use a different domain (list in the report) and redirect to a sgnl://linkdevice URL instead.
@rysiek@mstdn.socialThat sgnl://linkdevice URL is also handled by Signal app on mobile, but instead it links that mobile client to another client (like Signal Desktop).
Apparently what the update does is:
- it asks the person using the mobile app to explicitly enter link-new-device flow;
- and then double checks for a while at random intervals if the person really intended to link a new device.
One of the relevant commits:
https://github.com/signalapp/Signal-Android/commit/112874c08019a40b6f8f1dbbf84eb0ab4d796582
@rysiek Linkdevice workflow should need to be initiated from the device that already has access not the side that wants to get access.
This sounds like a variant on the long unfixed Discord "Scan QR Code" account takeover vector.
@dalias absolutely!
I can see how that's complicated here – Signal app is the one that has access, but is also on the device that is easier to scan QR codes on.
So it kinda makes sense, from usability perspective, to initiate it with a QR code displayed in Signal Desktop, and scanned on the mobile device.
Not sure what the solution here is, but I agree with you it should be the other way around.
@rysiek 1. Client generates cryptographic secret sent to cloud infrastructure when you go to "link device" on client.
2. Device you want to link pulls this secret associated with account id you want to link. Fails if client for account is not in linking process already. Displays QR code.
3. Existing client scans QR code, only links if secret matches.
Edit: To be clear, this isn't complete and doesn't authenticate the other direction, which you still need to do as well (new device also generates a secret).
@rysiek They didn't already do that!? You could just link devices from scanning a QR code with no further interaction!?
@rysiek Please tell me that I've misunderstood what you're saying.
@pettter I double checked. They *were* already doing that. Now they make the person using Signal on mobile explicitly go into the link-new-device flow and re-scan the QR:
https://github.com/signalapp/Signal-Android/commit/112874c08019a40b6f8f1dbbf84eb0ab4d796582
@pettter @rysiek
I expect that Signal already required that you scan the QR code from a dedicated screen which you need to manually open first.
The only thing I see in the commit is the change of the dialog for the case when you scan from a general purpose QR scanner or click on the link telling the user to "Make sure you only scan QR codes that come directly from Signal."
@pettter @rysiek
There is another related commit that makes the user read instructions if they have not linked devices in the last 30 days or something like that:
https://github.com/signalapp/Signal-Android/commit/a934df5f9769fbc511477edac9421d1ba4b46895
@pettter there was a confirmation dialog. Now it requires you to go to a specific part of the app and scan it again:
https://github.com/signalapp/Signal-Android/commit/112874c08019a40b6f8f1dbbf84eb0ab4d796582
@rysiek Well that's something at least, but holy shit we've really fucked up how people react to confirmation dialogues haven't we? ("We" being software developers as a collective)
But also, as @dalias noted, this flow has no business being initiated from the device that wants to be linked:
https://hachyderm.io/@dalias/114030792304413072
@rysiek Yeah no shit. I'm not sure how I feel about Signal having this kind of honestly quite shoddy security engineering. The safest device is the one you don't use, and the most useful device is the one everyone can access to do everything, but to me this feels very much like another case of Signal wanting to have their cake (marketing themselves as critical security infra for dissidents) and eat it too (making usability tradeoffs that don't support that threat model).. @dalias
@dalias I don't know, I'm not deep in the field, but Signal is just one of those companies which continually has made choices that baffle me. Tying user ID to phone numbers and leaking Signal usage through contact lists, refusing federation and secure distribution through f-droid, implementing Stories and fucking cryptocurrency integration instead of useful group chat features (moderation tools, subchannels).. @rysiek
@pettter @rysiek Half of those criticisms are poorly founded stuff spewed by anti-Signal circles with agendas. For example Stories was the key feature to displace very bad insecure shit in large parts of the world, and they did an actually secure/private version of it.
Signal is not the final place we need to be, but they're the only player who has a short term hope of replacing awful stuff by not having big feature regressions for normies who switch. Meanwhile we'll keep advancing better stuff (VeilidChat, Cwtch) for eventual mainstream audiences.
@rysiek @pettter Compare this https://hachyderm.io/@dalias/114016554675938466 to getting greeted by a bunch of nazi recommended groups when you launch the app.
@pettter not 100% sure here