WhatsApp Security Vulnerability
schneier.com
schneier.com
The attacker first try to duplicate the mobile phone number of the first victim, probably by social engineering their phone company. This part may look difficult to do, but it is not hard if you realize you do not need to target anyone special - everyone uses WhatsApp, so any number gives a high probability of success.
After getting the first victim number, the attacker install WhatsApp, which gladly verifies the user via SMS - WA has no login, no password, so anyone receiving the SMS can impersonate anyone else.
As Whatsapp does not send any alert of key change by default, the attacker is free to impersonate to person - in this case, he simply asks for some borrowed money to be transferred to a bank account, which will be paid soon. The recipient has no reason to distrust the message - it is being sent by his friend in the same chat window as they always talked to, even the logs are there. There is no message to warn about the potential issue, by design!
This is no hypothesis - this is actually happening for some time, now.[1] This design feature surely has some loyal users.
[1]http://www.correiobraziliense.com.br/app/noticia/cidades/201...
People love to blame WhatsApp, but what can anyone realistically do?
"Wow, he is asking me in excess of USD500 just after WhatsApp warned me his cell phone has changed. Weird".
The simple alert shown in moxie's own blog post [1], perhaps less cryptically written, would probably do the job.
Heck, if this happened between me and girlfriend last week, I would most probably fall, as I did not know this was disabled in WhatsApp. Now, at least, I have turned the notification on.
[1] https://whispersystems.org/blog/images/whatsapp-keychange.pn...
That said, my reasoning went along the lines of:
Where I live at least people rarely switch phone numbers and I have yet to hear about a single person that I know or have worked with who have had their phone number hijacked.
So, lets say that other people are less lucky than me and this warning will pop up twice a year, -will that be enough to trigger warning fatigue?
IMO, probably not.
Will we still have a problem with warning fatigue? Yes. Why? Because of the sticker and warning requirements created by American lawsuits and EU cookie law. (Oh, and IIRC my country isn't much better in this regard, just smaller so less of a problem.)
While not a citation I hope this explains my reasoning.
First, it's not about people switching phone numbers. It's about switching devices. This can be something as innocuous as uninstalling/reinstalling the WhatsApp app. Or upgrading their phone on a one or two year cycle. Or because they broke their phone and are using a friend's old phone for a few weeks. Or wanting to send and read messages on their laptop too. And their work laptop. Except they also had their work laptop reinstalled because of a virus, or because IT needed to do an upgrade, or whatever.
This shit happens all the time.
> …and I have yet to hear about a single person that I know or have worked with who have had their phone number hijacked.
I think this proves my point. The signal-to-noise ratio for this type of message is precisely zero for greater than 99.999% of WhatsApp users who are not being singled out by a nation-state for surveillance. And he number of these users who actually bothers to confirm keys out-of-band is, while not precisely zero, near enough as to make no difference.
For users who do anticipate being singled out, there are two plausible options: they are savvy enough to look into the settings and ensure the toggle is enabled, or they're not savvy enough to look for this type of option, and they're probably screwed anyway because actually achieving practical privacy against a highly-funded and highly-motivated governmental adversary is brutally hard and requires significantly more active involvement than merely toggling a switch on a messaging app.
> So, lets say that other people are less lucky than me and this warning will pop up twice a year
Twice a year times fifty contacts adds up to seeing this message frequently enough that you learn to subconsciously ignore it. People still try to bypass virtually every TLS warning browsers throw at them even though that number for most people is less than once per year, and even though browsers have made it painfully difficult to do so.
At least that way, everyone will become aware at least once and make their choice.
Literally everyone not tech savvy, this what happens on signal.
That sounds like a fatal flaw. Could not any GNU Radio user dump these by the thousands?
You'll need to be next to the actual phone number user when you request, and the victim will receive the SMS. Also, the victim would be shut out of WhatsApp (it allows only one client to be active), which would probably trigger some reaction.
Sounds like a nice hack, nevertheless.
Seriously, even for good friends and family, I'd expect a phone call when asked for money, not a message. It's basically a matter of respect.
Also the messages implies that is not really a lending, just to pay someone else and the money will be transferred soon enough.
The attacker needs to know the phone number and be able to read SMS messages from the phone number. Even very weak methods like the typical security questions would make this much more difficult.
I don't think that's the case. AFAIK WhatsApp does warn people about key changes with this warning message by default: https://cldup.com/QdUQmjJoF9.png
In fact working with software, at least once a month someone will ask me "Hey, what is this 'Security code has changed' message that pops up every so often about? Do I need to worry about it?"
WhatsApp backdoor allows snooping on encrypted messages, https://news.ycombinator.com/item?id=13389935
There is no WhatsApp 'backdoor', https://news.ycombinator.com/item?id=13394900
> [WhatsApp's representative is] technically correct. This is not a backdoor. This really isn't even a flaw. It's a design decision that put usability ahead of security in this particular instance.
This security application is not secure but it is usable.
Either your security will or won't be compromised by a given threat model. This is binary, but there's lots of different threat models one could have.
e.g. If you care about the Russian government impersonating you, it's a different threat model than if you care about the US government reading your communication, which is a different threat model than if you care about a private actor encrypting all your data and holding it ransom.
This is then complicated by the fact that we can't see into the future (sufficiently complicated code is likely to have bugs, we need to predict if those bugs will be exploited before they are fixed; large government attackers may or may not know about math that the public crypto community doesn't; which governments will successfully compel a third party to do various things or reveal various secrets &c.) so each binary value for the security becomes probabilistic.
> How serious this is depends on your threat model. If you are worried about the US government -- or any other government that can pressure Facebook -- snooping on your messages, then this is a small vulnerability. If not, then it's nothing to worry about.
"He (Moxie) said: “The choice to make these notifications ‘blocking’ would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn’t, effectively telling the server who it could man-in-the-middle transparently and who it couldn’t; something that WhatsApp considered very carefully.”
This claim is false. Those “blocking” clients could instead retransmit a message of the same length that just contains garbage and this message would just not be displayed by the receiver’s phone. Encryption guarantees the garbage or real messages are indistinguishable in the encrypted form. Hence, this technique would make identifying users with the additional security enabled on a large scale impossible."
This was raised in the previous WhatsApp vuln thread but as far as I'm aware, Moxie is yet to address this criticism. Would be good to get a response on this.
[1] https://www.theguardian.com/technology/2017/jan/16/whatsapp-...
Presumably any message which would be detectable enough as garbage to not be displayed on the reader's phone could be treated as them having this feature enabled, allowing the information-leak Moxie mentioned.
(To be clear, I do think there's a argument to be had over which of these leaks is worse. I just don't think this suggested approach actually addresses Moxie's concern.)
I know nothing of the signal protocol, but whether the server can tell the message is garbage depends on what the receiver client tells the server. An ideal client would acknowledge receipt to the server but show the user an error (or silently drop the garbage message). From the quote it seems like this is the case, in which case the server can't tell a true message receipt from receipt of garbage and the correlation doesn't work.
You're forgetting that the server is the one telling the sender what the new key is. If the key is under the control of the attacker/server, they can read the message and determine if it's garbage or not.
Given that WhatsApp brokers the initial key exchange, lawful interdiction can take place at WhatsApp under subpoena. What we hope is the case is that WhatsApp would fight these orders in court, claiming that the keys are merely forwarded and aren't stored by design. But if they fought and lost, then presumably they'd comply with the orders and the provision not to reveal the order. Do we really think that WhatsApp and/or Facebook have the conviction of Ladar Levison?
It would seem that all new accounts created at WhatsApp after that theoretical warrant is executed are at risk.
1) Police arrest a drug dealer, who manages to turn his phone off by smashing it on the floor and the battery pops out, in the same step also locking the data from readout if the device is using FDE
2) Cops now take the SIM card, compel the provider to provide the PUK to unlock the SIM card and insert it into their own smartphone
3) Cops activate WhatsApp and now can read any messages sent after the arrest, thus discovering potential clients. They can also impersonate the drug dealer and arrange sting operations.
There's really no way to avoid out-of-band key verification in end-to-end encrypted messaging unless you fully trust the service. Other than that, the best you can hope for is after-the-fact detection of MitM attacks through something like Key Transparency, but that still requires that someone's actively looking for that.
But only for messages sent by the sender AFTER the key-change notification. Those still in the send queue get re-encrypted with the new key of the cop phone and then resent without confirmation, and this is the attack window and the bug!
Oh, and most people don't enable the key-change notification anyway so they won't even know that their dealer got arrested.
... and that notification would be shown after that potential client's WhatsApp client had re-encrypted the undelivered messages and re-sent them.
I don't see how WhatsApp would be vulnerable in this scenario assuming they change this behaviour, but OP claims there's still a big gaping hole.
It's not like SSH in which separate and discrete components generate the keypair and verify fingerprint on connection.
I also don't see the difference between this and SSH. If your SSH server or client is backdoored/compromised, you have no control over what happens with your plaintext, no matter what the fingerprint verification tells you. The only difference is that one is open source, so the likelihood that a backdoor is detected is probably higher, though I don't think this means a) there is no backdoor and b) a backdoor in a closed-source app cannot be detected.
What the security community has spent the last 20 or so years coming to grips with is that it's very hard to cover every attack surface, and not wind up with a product that nobody outside of a select few are smart or dedicated enough to use (e.g., GPG), or that people don't just blindly click through endless warnings (e.g., the not-so-distant days of TLS). What we can do is make incremental improvement over the existing tools that people use by covering more in the threat model or improving the usability such that more people use it and/or fewer people ignore important concerns.
As a mass-market anti-surveillance and privacy-enabling chat app, WhatsApp is an incredible success. It's not replacing GPG with a carefully-curated web of trust. It's replacing plaintext SMS.
There are better tools if you know your threat model includes targeted, high-budget attacks the FSB, NSA, or CIA.
I wasn't able to find proof for attacker's ability to provide pregenerated key, can you please provide link with/or quote? I also wasn't able to find description of WhatsApp key changing procedure, and intuitively it would be more than strange not to require new identity key be signed with previous one.
The scenario is that someone changes the public key associated with the recipient on WhatsApp's server, which then causes the re-transmission "vulnerability" I described. This could be done either because the government forces them to, or because the server is compromised.
> it would be more than strange not to require new identity key be signed with previous one.
This would not work in practice. Phones can be lost, stolen and/or broken. There would be no way to sign the new key with the old one in any of these scenarios, since the key is only stored on the (lost) device. Forcing the users to back up the keys is not practical either for an app that wants to be an easy replacement for SMS, and depending on how users store those keys, might be less secure.
1) WhatsApp makes user X appear offline
2) User Y sends user X a message
3) WhatsApp sends user Y an indication that user X's key has changed, along with the public key for which they have the corresponding private key
With these steps, user Y's message will be resent with the new key that WhatsApp knows, and so they can read the message. There is a configuration setting that will display a notification that the key changed, but no way to prevent an undelivered message from automatically being resent with the new key.