
WhatsApp Encryption Security Flaws Could Allow Snoops to Slide into Group Chats - uptown
https://www.wired.com/story/whatsapp-security-flaws-encryption-group-chats/
======
moxie
Here's how WhatsApp group messaging works: membership is maintained by the
server. Clients of a group retrieve membership from the server, and clients
encrypt all messages they send e2e to all group members.

If someone hacks the WhatsApp server, they can obviously alter the group
membership. If they add themselves to the group:

1\. The attacker will not see any past messages to the group; those were e2e
encrypted with keys the attacker doesn't have.

2\. All group members will see that the attacker has joined. There is no way
to suppress this message.

Given the alternatives, I think that's a pretty reasonable design decision,
and I think this headline pretty substantially mischaracterizes the situation.
I think it would be better if the server didn't have metadata visibility into
group membership, but that's a largely unsolved problem, and it's unrelated to
confidentiality of group messages.

In contrast, Telegram does _no encryption at all_ for group messages, even
though it advertises itself as an encrypted messenger, and even though
Telegram users think that group chats are somehow secure. An attacker who
compromises the Telegram server can, undetected, recover every message that
was sent in the _past_ and receive all messages transmitted in the _future_
without anyone receiving any notification at all.

There's no way to publish an academic paper about that, though, because
there's no "attack" to describe, because there's no encryption to begin with.
Without a paper there will be no talks at conferences, which means there will
be no inflammatory headlines like this one.

To me, this article reads as a better example of the problems with the
security industry and the way security research is done today, because I think
the lesson to anyone watching is clear: don't build security into your
products, because that makes you a target for researchers, even if you make
the right decisions, and regardless of whether their research is practically
important or not. It's much more effective to be Telegram: just leave
cryptography out of everything, except for your marketing.

~~~
mhaymo
> I think it would be better if the server didn't have metadata visibility
> into group membership, but that's a largely unsolved problem, and it's
> unrelated to confidentiality of group messages.

Nitpick: Signal solves this problem just fine¹, by treating messages to a
group as simple pairwise messages, encrypted similarly to pairwise messages,
and sent separately to each member of the group. Group management is all done
through these e2e-encrypted messages.

¹Signal also has a group messaging bug in that the app doesn't check that
someone is a member of a group before accepting their group management
commands, but that is trivial to fix.

~~~
lann
I'm guessing that moxie has a pretty good idea of how Signal works...

------
skrebbel
Even if this is true, don't forget that in WhatsApp you don't get the message
history when you join a group. Plus, everybody sees that someone joined. That
doesn't take the problem away, but it makes the impact much smaller than it
sounds.

~~~
eqtn
"everybody sees that someone joined" i can see that xxx has joined. Is the
message coming from server or client? If it is from the server, then the
attacker could block that message right?

~~~
baby
I have looked at such implementations but don’t know you about whatsapp
specifically: you will see the notification no matter what. This makes this
attack not really an attack. Sure the servers can modify the participant list
but everyone will see it and everyone will choose to write to the new group
chat willingly.

When someone joins/leaves the group every participant generates and distribute
a new key. So as a rogue participant, the keys you’ll receive won’t allow you
to decrypt past messages.

PS: this article was posted before the speaker was even done with his talk.
This is funny?

~~~
nebulous1
I don't see how you're arguing that this isn't an attack.

However, it's clear that the severity will depend on the particular group. A
group of three friends will certainly notice when someone is added to the
membership. A larger group of people who don't know each other personally but
trust the administrator to administer membership will have to rely on the
admin both noticing and taking action, and he may be hampered in doing so by
the attacker.

~~~
baby
It's just a UX failure more than an attack imo. If you're paranoid you will
for sure see that someone has been added to the group. If you don't care
well...

------
woliveirajr
> They say that anyone who controls WhatsApp's servers could effortlessly
> insert new people into an otherwise private group, even without the
> permission of the administrator who ostensibly controls access to that
> conversation.

Given that WhatsApp isn't open source and so on, controling the WhatsApp
server, or controling some part of its code, or controling the signing keys,
all can compromise the privacy and encryption.

This study shouldn't cause much surprise.

~~~
air
You can inspect the WhatsApp binary and prevent updates. Having to trust the
server is a big deal.

~~~
FabHK
And that's indeed the point of end-to-end encryption: that you don't have to
trust the server.

~~~
UncleMeat
You still trust the server, unless the encryption is done with code that
wasn't delivered from the server. E2E prevents your content from being stolen
in a data breach or from being accessed if the server was fine when you sent a
message but compromised later.

~~~
FabHK
Good point. The (variously named) security code should allow you to withdraw
even that trust (assuming you verify the security code and the binary on your
client...), right. Or does it? If the server knows the secret, it can
invisibly MITM you, right?

------
cntlzw
So the problem is WhatsApp servers can add people to groups? I don't want to
be a cynic but aren't groups per se stored on a centralised server? Or the
definition of a group at least. So this isn't much of a surprise?

~~~
nebulous1
No. Cynic or not, I'm unsure why you're assuming the entire research results
made no sense!

The administrator of a group should sign the "add member" messages, and group
members should only believe that a member has joined if they have such a
signed message authorizing the member. You are correct in so far as this is
apparently not what happens at the moment.

------
axau
Hah! Meanwhile in Facebook group chats, anyone can add anyone, and they get to
see the whole conversation history immediately and completely irrevocably
(even if someone removes them later, they get to keep the history until their
removal, and you can’t delete Facebook messages either).

------
StavrosK
Hmm, this is interesting. I would expect that members would at least have some
sort of room key (or at least signed assertion) that they would need to send
to a new member, to ensure that the server couldn't unilaterally add
participants.

~~~
baby
They don’t but this can easily be fixed by having the admin send a special
encrypted message to the group as proof that someone was added/removed.

~~~
StavrosK
A malicious server admin would probably be able to just intercept and stop
that. I don't know how they do group encryption, but I imagine they either
have a room key (although with forward secrecy that sounds unlikely) or they
do 1:M sending. In any case, it sounds that, since the server doesn't have the
group chat keys, they could just check for authorization from the admin (ie a
signed message verifying that they're the ones adding the user) before adding
a new user to the chat.

~~~
baby
> A malicious server admin would probably be able to just intercept and stop
> that

Which would stop anyone from being invited to the group

> or they do 1:M sending

That's what they do. When you join a group you generate a key that you
distribute to all the other participants via a 1-on-1 encrypted session, you
then use it to derive keys in a normal chaining-key thingy to encrypt messages
to all other participants.

> they could just check for authorization from the admin

So you mean the admin would be in on it?

~~~
StavrosK
> Which would stop anyone from being invited to the group

No, just the malicious server adding the malicious user.

> So you mean the admin would be in on it?

I mean WhatsApp could patch this attack vector by requiring the new member to
get a signed assertion from the group admin, proving to the other members that
the group admin was the person who added the user.

~~~
baby
> I mean WhatsApp could patch this attack vector by requiring the new member
> to get a signed assertion from the group admin, proving to the other members
> that the group admin was the person who added the user.

this is related to what I was talking about, except that in my scenario the
admin distributes the proof

~~~
StavrosK
Ah okay, I think we're talking about the same thing then.

------
Buttes8
This is a big nothing burger, you could practically infer the design from the
fact that they supported encrypted group chats _at all_. Very sensible design
IMO.

------
satyanash
WhatsApp has some decent decisions even after the complexity of being tied
down to a single device at a time.

WhatsApp Web is essentially a hack where any message you send through the web
app is _always_ routed through your phone (which is why it needs to be
connected all the time).

Earlier you could not even view the media on the web client without first
downloading it on your phone. But now it looks like they've hacked it further
such that you can view the E2E encrypted message on the web app without
downloading it to your phone. I guess it achieves this via shipping the
decryption key to the web app (just for the current session) where it allows
it to decrypt messages in the browser and using the phone just as a router of
sorts. This is just speculation based on apparent behavior though.

------
dmitrygr
Potential solution: all participants will only start sending new messages to
new participant/key if his "joined" message was signed by chat administrator
(which they can verify). Server cannot fake this sig as it does not have
administrator's key.

------
draggnar
If you are using WhatsApp, make sure you deactivate your account if you change
phone numbers. I recently got a new phone number and when I logged in, I
assumed a non-deactivated profile previously attached to my new number.

------
mkagenius
In case someone is wondering the unique group link is of length 22. Made of
A-Z|a-z|0-9 . You can also refresh a link, there isn't any limit on number of
refreshes it seems but won't be able to reach 62^22.

------
excalibur
I don't get why people even consider using WhatsApp for secure messaging.
Everybody knows it's owned by Facebook, and everybody knows how they operate.

~~~
praneshp
> and everybody knows how they operate.

Yep! Painless to use, and truly cross platform. WhatsApp operates like a
charm.

~~~
dingo_bat
As much as I hate facebook, their social messaging products (IG, messenger,
whatsapp) are top-notch, truly a cut above anything else.

------
gruez
how do other apps prevent this? short of everybody in the group manually
adding the new participant's key, I don't see why this flaw can't be
replicated in other chat apps

~~~
FabHK
From looking at the paper [1], the basic mitigation seems to be that the group
admin that adds someone to the group sends the "add this account to the group"
message to all group members end-to-end encrypted.

In Signal, apparently some malicious users that are not a group member (such
as a former group member) could add users to a group. In Threema and WhatsApp,
a malicious server can add further users, but Threema has apparently fixed
that already.

[1]
[https://eprint.iacr.org/2017/713.pdf](https://eprint.iacr.org/2017/713.pdf)

~~~
dbrgn
Not 100%. In Threema, a malicious server could replay an old add-this-user
message after that user has been removed from the group to re-add it to the
group. But it could never add new users (since add messages are encrypted by
the admin). Also, the server can't tell group control messages from regular
text messages, making this even harder. Replay protection has been added in
the meantime.

------
joannexxx
interesting post! But only the idea is kind of creepy... Anyways, if someone
new enters the group this person is usually not able to see all the previous
posts...

~~~
jwilk
"Usually"?

~~~
jkmangang
Not usually, it never allowed to see the message history.

~~~
joannexxx
yes you can never see the old messages

------
brndnmtthws
The most interesting part of this (to me at least) is that even our 'secure'
messaging systems rely entirely on trusted entities. I don't think Signal is
immune to this problem either, as you still need to communicate with their
servers. As a distributed trust system, WhatsApp and Signal are single points
of failure.

Messaging is analogous to money in a lot of ways. Perhaps we'll see a good
distributed peer to peer messaging protocol at some point in the future.

~~~
craftyguy
> Perhaps we'll see a good distributed peer to peer messaging protocol at some
> point in the future.

The Matrix protocol is actually fairly promising, as long as you only use it
for Matrix<->Matrix communication. Things fall to pieces when you try to
bridge it with IRC.

It's certainly more user-friendly for non-tech. folks than, say, the awkward
key exchange/setups of XMPP clients, but it's still a far cry from something
like Signal in terms of 'ease of use'

~~~
Shoothe
> awkward key exchange/setups of XMPP clients

What do you mean by that? Conversations.im establishes e2e secure session
without any fingerprint approving interaction whatsoever. Of course you can
manually scan barcodes for paranoid mode but that's not necessary.

For me it's a perfect balance between convenience and security. Read more at
[https://gultsch.de/trust.html](https://gultsch.de/trust.html)

~~~
craftyguy
Hmm, I'll check this out, thanks.

I was mainly speaking to previous experiences trying to set up Conversations
on one device, Pidgin on another, there not being any good way to use a
consistent key for my user on both, and trying to walk non-technical family
members through that fiasco. This was about 2 years ago, maybe the situation
has improved!

~~~
Shoothe
Keep in mind that Pidgin supporting many protocols means "lowest common
denominator" in several cases. For OMEMO E2E I'd recommend Gajim or (still in
alpha but promising) dino.im

------
snvzz
That anybody uses these proprietary "chat apps" for anything baffles me.

~~~
roywiggins
What else are you supposed to use to communicate on a phone? Unauthenticated
cleartext SMS?

~~~
snvzz
Some chat system that isn't an "app", but rather, where the "app" is just an
open source client for a documented, reasonably secure system.

EFF's recommendation list is being remade: [https://www.eff.org/secure-
messaging-scorecard](https://www.eff.org/secure-messaging-scorecard)

But the old one is still reachable from it.

WhatsApp is the one that got bought by facebook, which should be a red flag
for those sensible.

~~~
blackoil
>How to use WhatsApp on Android or iOS.

From the EFF page you have linked. :D

~~~
snvzz
EFF recommending Facebook for IM?

I want my donations back.

------
EGreg
_" If you build a system where everything comes down to trusting the server,
you might as well dispense with all the complexity and forget about end-to-end
encryption," says Matthew Green, a cryptography professor at Johns Hopkins
University who reviewed the Ruhr University researchers' work. "It's just a
total screwup. There's no excuse."_

Someone was asking about blockchains. THIS is why you use blockchains. So you
don't trust just the server. Actually _everything_ on the Web trusts the
server. That's just how the Web was designed.

Now, one way to mitigate this - and also improve security in open source
projects - is to implement a blockchain hosted by many organizations which
can't all be compromised easily.

At Qbix, we are working on a drop-in data structure that would implement
arbitrary business rules in a secure way. The nice thing is you don't need
everyone to adopt it, for it to help you secure your network.

For example, some guy starts a group so he has all the access and privileges,
and he uses them to invite others and assign privileges. Then he repudiates
his own privileges in the group. Now everyone can verify and be SURE that
everyone has the same privileges - rules are added for different types of
Messages posted on the Stream and are are enforced by the blockchain.

That is how you do governance. It ain't easy but there can be packages made,
of different governance types.

PS: However when you have end-to-end encryption, you don't need the blockchain
to be hosted on servers. You can have the server relay messages between
clients and enforce rules on the clients.

If you don't need consensus, sometimes you don't even need a blockchain! For
example, with Reddit, you can just have an append-only Merkle Tree and have
clients pass each other comments.

But what if you wanted to expand more comments? Do you have read permission?
Do you have write permission?

One way to do it is on a per-thread basis. Each thread is owned by its OP. The
rules are enforced by the OP and the messages are published by the OP. So then
you trust the OP to be available (online) and accept and broadcast your reply
etc.

But if you have MORE THAN ONE user involved in governance of a Stream (our
terminology) then you need a blockchain. At the very least, to verify there
are no malicious forks of a stream.

If you want to find out more you can look in my profile (about) and email me.

------
williamscales
This was a deliberate design decision by WhatsApp. I even remember going to a
talk by a WhatsApp engineer when they announced end-to-end encryption and he
spent a fair amount of time detailing the method WhatsApp had implemented to
allow for adding new users to groups while allowing these new users to read
old messages. So I'm pretty sure this has been known from the start. Don't use
Facebook products if you care about real security.

~~~
jkmangang
Whatsapp never allowed new users to read message history. Never!

