There is a WhatsApp 'backdoor'
tobi.rocks
There is a WhatsApp 'backdoor'
1–9 of 9 posts
Re: There is a WhatsApp 'backdoor'
#2Still not sure if the vulnerability is intended, but the idea of sending garbage is great. The vulnerability is definitely fixable even if you want to have security disabled by default.
Edit: after some thought, it is not that easy. If you resend garbage of the same size and then after some time you click "resend" and send batch of messages of the same size, then you likely have confirmation enabled.
So users who have confirmations disabled should send garbage too, when they open the application after some messages were resent.
Again, the idea is great, but needs more thought to make a working solution. Cover traffic is not simple.
Re: There is a WhatsApp 'backdoor'
#3[deleted]
Re: There is a WhatsApp 'backdoor'
#4Still not sure if the vulnerability is intended, but the idea of sending garbage is great. The vulnerability is definitely fixable even if you want to have security disabled by default. Edit: after some thought, it is not that easy. If you resend garbage of the same size and then after some time you click "resend" and send batch of messages of the same size, then you likely have confirmation enabled. So users who hav…
Good point. You could:
If notifications/blocking disabled (newbie setting):
Send re-keyed ciphertext immediately.
Random time later send garbage (automatically discarded by client)
If blocking enabled:
Send re-keyed garbage immediately.
When consumer notices the popup some (random) time later,
- and clicks "re-send": send re-keyed ciphertext
- and clicks "discard": send re-keyed different garbage.
However, note that if a compromised server MITM, they will probably be able to tell the difference between garbage and actual message (because the server provides the bad key, so can decrypt the immediate response message). It's really not trivial. Don't roll your own crypto... :-)
Re: There is a WhatsApp 'backdoor'
#5Still not sure if the vulnerability is intended, but the idea of sending garbage is great. The vulnerability is definitely fixable even if you want to have security disabled by default. Edit: after some thought, it is not that easy. If you resend garbage of the same size and then after some time you click "resend" and send batch of messages of the same size, then you likely have confirmation enabled. So users who hav…
Good point. You could: If notifications/blocking disabled (newbie setting): Send re-keyed ciphertext immediately. Random time later send garbage (automatically discarded by client) If blocking enabled: Send re-keyed garbage immediately. When consumer notices the popup some (random) time later, - and clicks "re-send": send re-keyed ciphertext - and clicks "discard": send re-keyed different garbage. However, note that…
Good idea of extending the technique.
I want to address you last concern. moxie's specific concern is that without the extra measure I explained in the blog article, WhatsApp could find out on a large scale, covertly (!!!), who has this setting enabled or not. Simply because after a while pretty much every client will have to face the decision whether or not to retransmit for a benign reason.
Of course if they MITM, they can distinguish the re-send text from the garbage text, but the point is that then they are MITMing already and risk being detected. So instead they could've just MITM the conversation from the beginning on with risking of being detected.
Re: There is a WhatsApp 'backdoor'
#6> Signal does not have this vulnerability, but WhatsApp has it.
That might need a footnote or something. TheGuardian is reporting: Moxie Marlinspike of OWS said Signal planned to make blocking notifications an option for some users and use non-blocking notifications by default.
https://www.theguardian.com/technology/2017/jan/14/whatsapp-...
Re: There is a WhatsApp 'backdoor'
#7Still not sure if the vulnerability is intended, but the idea of sending garbage is great. The vulnerability is definitely fixable even if you want to have security disabled by default. Edit: after some thought, it is not that easy. If you resend garbage of the same size and then after some time you click "resend" and send batch of messages of the same size, then you likely have confirmation enabled. So users who hav…
Good point. You could: If notifications/blocking disabled (newbie setting): Send re-keyed ciphertext immediately. Random time later send garbage (automatically discarded by client) If blocking enabled: Send re-keyed garbage immediately. When consumer notices the popup some (random) time later, - and clicks "re-send": send re-keyed ciphertext - and clicks "discard": send re-keyed different garbage. However, note that…
> Random time later send garbage
Random is bad because you need some random distribution and by gathering statistics server can determine if your distribution of delays match. Delay until really clicking the button would be highly individual. That is why I said "when they open the application".
Re: There is a WhatsApp 'backdoor'
#8> Signal does not have this vulnerability, but WhatsApp has it. That might need a footnote or something. TheGuardian is reporting: Moxie Marlinspike of OWS said Signal planned to make blocking notifications an option for some users and use non-blocking notifications by default. https://www.theguardian.com/technology/2017/jan/14/whatsapp-...
With this option it is still possible to use the app securely. WhatsApp is insecure for everyone.
Re: There is a WhatsApp 'backdoor'
#9Earlier quoted context omitted.
Good point. You could: If notifications/blocking disabled (newbie setting): Send re-keyed ciphertext immediately. Random time later send garbage (automatically discarded by client) If blocking enabled: Send re-keyed garbage immediately. When consumer notices the popup some (random) time later, - and clicks "re-send": send re-keyed ciphertext - and clicks "discard": send re-keyed different garbage. However, note that…
> Random time later send garbage Random is bad because you need some random distribution and by gathering statistics server can determine if your distribution of delays match. Delay until really clicking the button would be highly individual. That is why I said "when they open the application".
True, if you did this, you'd want to either match the (empirical) distribution, or, as I believe you are suggesting, just pretend the (non-existing) button was pressed shortly after the user opens the app next time.