10 ms·

WhatsApp Security Vulnerability

100 points by c0rtex 10y ago

folex 10y ago
I didn't quite grasp why attacking entity (e.g. government) has the ability to read messages. What does "WhatsApp has the ability to force the generation of new encryption keys for offline users" mean? Does it mean that WhatsApp backend has the ability to force sender to use pregenerated compromised key provided by attacker? In terms of WhatsApp security whitepaper, does that mean that attacker can force sender to use newly generated (by attacker) S_recipient, O_recipient and the main one, I_recipient? I'm asking because "force the generation of new _encryption_ keys" doesn't really specify who would generate keys, or what about identity key that signs everything.
- pfg 10y ago
  WhatsApp has the ability to change the identity key associated with a user. That's the key they give anyone who wishes to send a message to that user. This is necessary in case the device is lost, wiped or replaced. Changing the identity key triggers a notification for other parties in a conversation if they have enabled that option. However, WhatsApp also automatically re-encrypts any messages that have not been marked as delivered using the new identity key. An attacker that could force WhatsApp to change the identity key to one under their control could then read those re-encrypted messages, but not any messages that were already marked as delivered (or any future messages, assuming the notification causes the chat parties to re-verify the keys out of band before continuing their conversation).
  - folex 10y ago
    > to one under their control 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.
    - pfg 10y ago
      The key is generated on device. WhatsApp acts as a kind of key server (if we want to compare it to GPG) where a sender can look up the public (identity) key of the recipient, which is then used to encrypt the message for the recipient. I'm simplifying a bit here, but the details are not important in this context. 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.
      - folex 10y ago
        So the main problem is that the only way to make something secure is to introduce authentication factors, e.g. passphrase or biometrics
- aidenn0 10y ago
  Let's say WhatsApp wants to read the next message sent to user X: 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.
  - deleted 10y ago
    [deleted]
  - folex 10y ago
    So the main problem is that on _identity_ key change, the new one isn't required to be signed with previous identity key? If so, that's plain stupid, isn't it?
    - aidenn0 10y ago
      It's a natural consequence of "My phone got run-over/lost/stolen"
- leshow 10y ago
  They don't have the ability to flat out read messages. If they were to impersonate a contact, you would see that the key had changed (assuming you had this on) and you could choose not to talk to that contact until you verified.
  - folex 10y ago
    That's what I understood too. AFAIK, they only could 'break' contact, and not control the actual public identity key, so no way to read user messages.
wyldfire 10y ago
Even if they changed this specific design decision/vulnerability, it seems like there's a big gaping hole (or I'm missing something). 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.
- ikeboy 10y ago
  I'd assume the keys are generated on device.
  - tptacek 10y ago
    They are, so I'm not sure I understand the attack upthread.
    - mschuster91 10y ago
      A plausible attack scenario, outlined in multiple steps: 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.
      - pfg 10y ago
        That's why WhatsApp allows you to verify your recipient's key out of band. The scenario you describe would cause the identity key to change and trigger a notification if one of the potential clients has that option enabled. 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.
ckastner 10y ago
The article mostly just quotes two other sources that have already been discussed here: WhatsApp backdoor allows snooping on encrypted messages, https://news.ycombinator.com/item?id=13389935 https://news.ycombinator.com/item?id=13389935 There is no WhatsApp 'backdoor', https://news.ycombinator.com/item?id=13394900 https://news.ycombinator.com/item?id=13394900
- beambot 10y ago
  Yep, this is an analysis by a trusted individual in the security field. His ultimate summary: > [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.
  - frabbit 10y ago
    Or to re-phrase: This security application is not secure but it is usable.
    - noja 10y ago
      There is no "secure", it's a scale from "no security" to just "very high security".
      - aidenn0 10y ago
        Security isn't either a scale or a binary; from one point of view a large number of binary values. 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.
aylons 10y ago
While people discuss about a possible state-actor stronghanding WhatsApp and the semantics of backdoor, the "design feature" of not showing the key changes are making real victims, at least in Brasil: 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/2016/05/11/interna_cidadesdf,531298/brasilienses-caem-em-fraudes-cometidas-atraves-de-aplicativo-de-celula.shtml http://www.correiobraziliense.com.br/app/noticia/cidades/201...
- StavrosK 10y ago
  Unfortunately, if WhatsApp did defend against this, it would be such a big hassle that users would disable it. How many people do you know that wouldn't just click "accept" on "this user's keys changed", or wouldn't just ask the attacker "hey did you get a new phone?" "yes" "oh okay"? People love to blame WhatsApp, but what can anyone realistically do?
  - aylons 10y ago
    It does not need to be a modal form - a notification message, embedded in the the chat log, just before a "Hey, could you send me some money", could make some people think twice before transferring: "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.png https://whispersystems.org/blog/images/whatsapp-keychange.pn...
agd 10y ago
The question for me is that posed by the hacker who discovered the vulnerability. Here's what he said [1]: "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-vulnerability-facebook https://www.theguardian.com/technology/2017/jan/16/whatsapp-...
- pfg 10y ago
  The blocking would occur when the server changes the identity key of a user. If the server does that with the goal of finding out if the user has enabled safety number change notifications, it could just change the identity key to one under the server's control and see whether it receives any garbage.
- kemayo 10y ago
  I think you're using a different meaning of "blocking" than Moxie is. I believe they mean "blocking" in the sense of waiting for the user to confirm that the message should be re-sent -- i.e. blocking on the user's input. Whereas you're using "blocking" to mean refusing to re-encrypt the message. 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.)
  - 10y ago
arrakeen 10y ago
conspicuously missing from this discussion is the self-healing capabilities of the signal protocol, which as far as i understand is a major feature. when marlinspike says, "This is called a \"man in the middle\" attack, or MITM, and is endemic to public key cryptography, not just WhatsApp," i find it odd that he wouldn't even address the fact that the signal protocol has protections against this built into the protocol.
eridius 10y ago
If your threat model is the government compelling Facebook, then you should be using a different product that's geared specifically towards security, such as Signal. WhatsApp is a mass-market product aimed at the whole world, which means it makes different tradeoffs, providing a less comprehensive threat model in favor of higher usability. And that's a perfectly fine thing for this app to do.
- stouset 10y ago
  Yes, thank you. So many people in this thread are making the absurd assertion that security is a binary thing — it's either totally secure against all threats, or it's insecure. 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.

100 points by c0rtex 10y ago

folex 10y ago

I didn't quite grasp why attacking entity (e.g. government) has the ability to read messages. What does "WhatsApp has the ability to force the generation of new encryption keys for offline users" mean? Does it mean that WhatsApp backend has the ability to force sender to use pregenerated compromised key provided by attacker? In terms of WhatsApp security whitepaper, does that mean that attacker can force sender to use newly generated (by attacker) S_recipient, O_recipient and the main one, I_recipient? I'm asking because "force the generation of new _encryption_ keys" doesn't really specify who would generate keys, or what about identity key that signs everything.

pfg 10y ago
WhatsApp has the ability to change the identity key associated with a user. That's the key they give anyone who wishes to send a message to that user. This is necessary in case the device is lost, wiped or replaced. Changing the identity key triggers a notification for other parties in a conversation if they have enabled that option. However, WhatsApp also automatically re-encrypts any messages that have not been marked as delivered using the new identity key. An attacker that could force WhatsApp to change the identity key to one under their control could then read those re-encrypted messages, but not any messages that were already marked as delivered (or any future messages, assuming the notification causes the chat parties to re-verify the keys out of band before continuing their conversation).
- folex 10y ago
  > to one under their control 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.
  - pfg 10y ago
    The key is generated on device. WhatsApp acts as a kind of key server (if we want to compare it to GPG) where a sender can look up the public (identity) key of the recipient, which is then used to encrypt the message for the recipient. I'm simplifying a bit here, but the details are not important in this context. 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.
    - folex 10y ago
      So the main problem is that the only way to make something secure is to introduce authentication factors, e.g. passphrase or biometrics
aidenn0 10y ago
Let's say WhatsApp wants to read the next message sent to user X: 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.
- deleted 10y ago
  [deleted]
- folex 10y ago
  So the main problem is that on _identity_ key change, the new one isn't required to be signed with previous identity key? If so, that's plain stupid, isn't it?
  - aidenn0 10y ago
    It's a natural consequence of "My phone got run-over/lost/stolen"
leshow 10y ago
They don't have the ability to flat out read messages. If they were to impersonate a contact, you would see that the key had changed (assuming you had this on) and you could choose not to talk to that contact until you verified.
- folex 10y ago
  That's what I understood too. AFAIK, they only could 'break' contact, and not control the actual public identity key, so no way to read user messages.

wyldfire 10y ago

Even if they changed this specific design decision/vulnerability, it seems like there's a big gaping hole (or I'm missing something). 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.

ikeboy 10y ago
I'd assume the keys are generated on device.
- tptacek 10y ago
  They are, so I'm not sure I understand the attack upthread.
  - mschuster91 10y ago
    A plausible attack scenario, outlined in multiple steps: 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.
    - pfg 10y ago
      That's why WhatsApp allows you to verify your recipient's key out of band. The scenario you describe would cause the identity key to change and trigger a notification if one of the potential clients has that option enabled. 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.

ckastner 10y ago

The article mostly just quotes two other sources that have already been discussed here: WhatsApp backdoor allows snooping on encrypted messages, https://news.ycombinator.com/item?id=13389935 https://news.ycombinator.com/item?id=13389935 There is no WhatsApp 'backdoor', https://news.ycombinator.com/item?id=13394900 https://news.ycombinator.com/item?id=13394900

beambot 10y ago
Yep, this is an analysis by a trusted individual in the security field. His ultimate summary: > [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.
- frabbit 10y ago
  Or to re-phrase: This security application is not secure but it is usable.
  - noja 10y ago
    There is no "secure", it's a scale from "no security" to just "very high security".
    - aidenn0 10y ago
      Security isn't either a scale or a binary; from one point of view a large number of binary values. 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.

aylons 10y ago

While people discuss about a possible state-actor stronghanding WhatsApp and the semantics of backdoor, the "design feature" of not showing the key changes are making real victims, at least in Brasil: 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/2016/05/11/interna_cidadesdf,531298/brasilienses-caem-em-fraudes-cometidas-atraves-de-aplicativo-de-celula.shtml http://www.correiobraziliense.com.br/app/noticia/cidades/201...

StavrosK 10y ago
Unfortunately, if WhatsApp did defend against this, it would be such a big hassle that users would disable it. How many people do you know that wouldn't just click "accept" on "this user's keys changed", or wouldn't just ask the attacker "hey did you get a new phone?" "yes" "oh okay"? People love to blame WhatsApp, but what can anyone realistically do?
- aylons 10y ago
  It does not need to be a modal form - a notification message, embedded in the the chat log, just before a "Hey, could you send me some money", could make some people think twice before transferring: "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.png https://whispersystems.org/blog/images/whatsapp-keychange.pn...

agd 10y ago

The question for me is that posed by the hacker who discovered the vulnerability. Here's what he said [1]: "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-vulnerability-facebook https://www.theguardian.com/technology/2017/jan/16/whatsapp-...

pfg 10y ago
The blocking would occur when the server changes the identity key of a user. If the server does that with the goal of finding out if the user has enabled safety number change notifications, it could just change the identity key to one under the server's control and see whether it receives any garbage.
kemayo 10y ago
I think you're using a different meaning of "blocking" than Moxie is. I believe they mean "blocking" in the sense of waiting for the user to confirm that the message should be re-sent -- i.e. blocking on the user's input. Whereas you're using "blocking" to mean refusing to re-encrypt the message. 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.)
- 10y ago

arrakeen 10y ago

conspicuously missing from this discussion is the self-healing capabilities of the signal protocol, which as far as i understand is a major feature. when marlinspike says, "This is called a \"man in the middle\" attack, or MITM, and is endemic to public key cryptography, not just WhatsApp," i find it odd that he wouldn't even address the fact that the signal protocol has protections against this built into the protocol.

eridius 10y ago

If your threat model is the government compelling Facebook, then you should be using a different product that's geared specifically towards security, such as Signal. WhatsApp is a mass-market product aimed at the whole world, which means it makes different tradeoffs, providing a less comprehensive threat model in favor of higher usability. And that's a perfectly fine thing for this app to do.

stouset 10y ago
Yes, thank you. So many people in this thread are making the absurd assertion that security is a binary thing — it's either totally secure against all threats, or it's insecure. 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.