NSA F9T53 Opsec Special Bulletin: Signal Vulnerability(scribd.com)
scribd.com
NSA F9T53 Opsec Special Bulletin: Signal Vulnerability
https://www.scribd.com/document/843124910/NSA-full
21 comments
I’m having problems loading the website, but the Wayback Machine has a recent copy as well:
https://web.archive.org/web/20250308170611/https://www.soc.m...
https://web.archive.org/web/20250308170611/https://www.soc.m...
Wow that was really comprehensive and much easier to read than I thought it would be for a military document.
Yeah, that deserves a front-page link of its own.
Weakness in the linked devices security model. And so by extension, tools like "beeper"
If you don't link devices and check there are no linked devices your side of things is OK but you have no certainty in group chats or the other side one on one. So it's down to your own trust in the other party/parties.
"Two can keep a secret if one of them is dead"
If you don't link devices and check there are no linked devices your side of things is OK but you have no certainty in group chats or the other side one on one. So it's down to your own trust in the other party/parties.
"Two can keep a secret if one of them is dead"
This doesn't invalidate your point, but FYI, you can open your contact's info in the Signal app and see the number of linked devices they have. If someone is concerned enough about this, they could ask their contact to unlink all devices.
EDIT: I'm using a fork, which may be why I'm seeing it and others aren't. See below.
EDIT: I'm using a fork, which may be why I'm seeing it and others aren't. See below.
Given sufficient mutuality, you can have some assurance of e2e but your risk here is your own and the other ends OPSEC which is all the NSA guidance really can re-inforce: the more people and devices you bring into an exchange the less likely it is you really have secure communications.
I don’t see this information for my contacts in the signal iOS app.
I don't see it in the Android app either, and I find the original claim very hard to believe in the first place, since that would be a weird piece of information for Signal to reveal about a user.
Apologies for the mistake. I'm running a Signal fork called Molly[0]; the feature I mentioned seems to be unique to that fork, based on a search of the code.
However, it shows that the data is being provided to the client by the server, in some way. This is a guess, but it may be because sending clients have to encrypt with a key for each device.
Here's the code:
https://github.com/mollyim/mollyim-android/blob/26403ab1806a...
https://github.com/mollyim/mollyim-android/blob/26403ab1806a...
[0] https://molly.im/
[0] https://github.com/mollyim/mollyim-android
However, it shows that the data is being provided to the client by the server, in some way. This is a guess, but it may be because sending clients have to encrypt with a key for each device.
Here's the code:
https://github.com/mollyim/mollyim-android/blob/26403ab1806a...
https://github.com/mollyim/mollyim-android/blob/26403ab1806a...
[0] https://molly.im/
[0] https://github.com/mollyim/mollyim-android
I find "bypassing end-to-end encryption" to be misleading... as if somehow the e2e encryption in Signal is somehow broken or flawed.
This "social engineering" hack? is simply allowing a 3rd party to gain access to another persons account and "snoop" on their secured messages/calls.
Pls correct me if I'm reading this wrong.
This "social engineering" hack? is simply allowing a 3rd party to gain access to another persons account and "snoop" on their secured messages/calls.
Pls correct me if I'm reading this wrong.
No you're right, this is basically just phishing.
However, I think there is a real possibility that the Signal code (of which the public appstore versions are NOT fully open-source) could be modified to save/transfer messages after they have been decrypted, basically circumventing the whole point of e2ee... which is why having control over the client code is essential.
I suggest either building Signal yourself, using only verified reproducible builds without any binary blobs, or switching to the Molly-FOSS fork.
However, I think there is a real possibility that the Signal code (of which the public appstore versions are NOT fully open-source) could be modified to save/transfer messages after they have been decrypted, basically circumventing the whole point of e2ee... which is why having control over the client code is essential.
I suggest either building Signal yourself, using only verified reproducible builds without any binary blobs, or switching to the Molly-FOSS fork.
No, bypass means to go around, not to break. So this is correct terminology. By adding devices into a chat, you get to see the plaintext messages, thus bypassing the protection provided by the end to end encryption.
It's not clear. The relevant text seems to imply that an attacker can link their own device to a target account via providing a malicious URL (vs. commandeering an already-legitimately-linked device, which I guess is what you're imagining). That sounds like a legitimate flaw. But there are no details.
Related Multiple Russia-aligned threat actors actively targeting Signal Messenger (836 points, 37 days ago, 317 comments) https://news.ycombinator.com/item?id=43102284
Any application that does cross-device authentication is vulnerable to QRLJacking (this type of vulnerability) to some extent, the same way any application with username/password authentication is vulnerable to phishing.
What's ironic is that the document is marked For Official Use Only, and typically shouldn't be distributed without being officially released.
Makes you wonder if the NSA has a team updating the screenshots of these bulletins as new versions of the apps and operating systems are released.
It's been a few years since I retired and gave up my clearances, but AFAIK FOUO should not be posted to the Internet.
The vulnerability is that Signal doesn’t inform the user when there are additional devices added to their account?
It does, about three hours later? Or it did when I added a device a couple weeks ago.
https://www.soc.mil/IdM/publications/docs/general/Id_Privacy...