Direkt zum Hauptbereich

Group Instant Messaging: Why blaming developers is not fair but enhancing the protocols would be appropriate

After presenting our work at Real World Crypto 2018 [1] and seeing the enormous press coverage, we want to get two things straight: 1. Most described weaknesses are only exploitable by the malicious server or by knowing a large secret number and thereby the protocols are still very secure (what we wrote in the paper but some newspapers did not adopt) and 2. we see ways to enhance the WhatsApp protocol without breaking its features.

We are of course very happy that our research reached so many people and even though IT security and cryptography are often hard to understand for outsiders, Andy Greenberg [2], Patrick Beuth [3] and other journalists [4,5,6,7,8] wrote articles that were understandable on the one hand and very accurate and precise on the other hand. In contrast to this, we also saw some inaccurate articles [9,10] that fanned fear and greatly diverged in their description from what we wrote in our paper. We expected this from the boulevard press in Germany and therefore asked them to stick to the facts when they were contacting us. But none of the worst two articles' [9,10] authors contacted us in advance. Since our aim was never to blame any application or protocol but rather we wanted to encourage the developers to enhance the protocols, it contradicts our aim that WhatsApp and Signal are partially declared attackable by "anyone" "easily" [9,10].

Against this background, we understand Moxie's vexation about certain headlines that were on the Internet in the last days [11]. However, we believe that the ones who understand the weaknesses, comprehend that only the malicious server can detectably make use of them (in WhatsApp) or the secret group ID needs to be obtained from a member (in Signal). As such, we want to make clear that our paper does not primarily focus on the description of weaknesses but presents a new approach for analyzing and evaluating the security of group instant messaging protocols. Further we propose measures to enhance the analyzed protocols. The description of the protocols' weaknesses is only one part of the evaluation of our analysis approach and thereby of the investigation of real world protocols. This is the scientific contribution of our paper. The practical contribution of the analyzed messengers, which is the communication confidentiality for billion users (in most cases), is great and should be noted. Therefore we believe that being Signal, WhatsApp, or Threema by applying encryption to all messages and consequently risking research with negative results is much better than being a messenger that does not encrypt group messages end-to-end at all. We do not want to blame messengers that are far less secure (read Moxie's post [11] if you are interested).

Finally we want note that applying security measures according to the ticket approach (as we call it in the paper [12]) to the invitation links would solve the issues that Facebook's security head mentioned in his reply [13] on our findings. To our knowledge, adding authenticity to group update messages would not affect invitation links: If no invitation link was generated for a group, group members should only accept joining users if they were added by an authentic group update message. As soon as a group invitation link was generated, all joining users would need to be accepted as new group members with the current design. However there are plenty ways how WhatsApp could use invitation links without endowing the server with the power to manage groups without the group admins' permission:
One approach would be generating the invitation links secretly and sharing them without the knowledge of the server. An invitation link could then contain a secret ticket for the group and the ID of the group. As soon as a user, who received the link, wants to join the group, she can request the server with the group ID to obtain all current group members. The secret ticket can now be sent to all existing group members encrypted such that the legitimate join can be verified.

Of course this would require engineering but the capability of WhatsApp, shipping drastic protocol updates, can be assumed since they applied end-to-end encryption in the first place.

[1] https://www.youtube.com/watch?v=i5i38WlHfds
[2] https://www.wired.com/story/whatsapp-security-flaws-encryption-group-chats/
[3] http://www.spiegel.de/netzwelt/apps/whatsapp-gruppenchats-schwachstelle-im-verschluesselungs-protokoll-a-1187338.html
[4] http://www.sueddeutsche.de/digital/it-sicherheit-wie-fremde-sich-in-whatsapp-gruppenchats-einladen-koennen-1.3821656
[5] https://techcrunch.com/2018/01/10/security-researchers-flag-invite-bug-in-whatsapp-group-chats/
[6] http://www.telegraph.co.uk/technology/2018/01/10/whatsapp-bug-raises-questions-group-message-privacy/
[7] http://www.handelsblatt.com/technik/it-internet/verschluesselung-umgangen-forscher-finden-sicherheitsluecke-bei-whatsapp/20836518.html
[8] https://www.heise.de/security/meldung/WhatsApp-und-Signal-Forscher-beschreiben-Schwaechen-verschluesselter-Gruppenchats-3942046.html
[9] https://www.theinquirer.net/inquirer/news/3024215/whatsapp-bug-lets-anyone-easily-infiltrate-private-group-chats
[10] http://www.dailymail.co.uk/sciencetech/article-5257713/WhatsApp-security-flaw-lets-spy-private-chats.html
[11] https://news.ycombinator.com/item?id=16117487
[12] https://eprint.iacr.org/2017/713.pdf
[13] https://twitter.com/alexstamos/status/951169036947107840

Further articles:
- Matthew Green's blog post: https://blog.cryptographyengineering.com/2018/01/10/attack-of-the-week-group-messaging-in-whatsapp-and-signal/
- Schneier on Security: https://www.schneier.com/blog/archives/2018/01/whatsapp_vulner.html
- Bild: http://www.bild.de/digital/smartphone-und-tablet/whatsapp/whatsapp-sicherheitsluecke-in-gruppenchats-54452080.bild.html
- Sun: https://www.thesun.co.uk/tech/5316110/new-whatsapp-bug-how-to-stay-safe/

Beliebte Posts aus diesem Blog

How To Spoof PDF Signatures

One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:

"How do PDF signatures exactly work?"

We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.

Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.

In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042

Printer Security

Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.

TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET Full results are available in the master thesis of Jens Müller and our paper. Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The hi…

DTD Cheat Sheet

When evaluating the security of XML based services, one should always consider DTD based attack vectors, such as XML External Entities (XXE) as,for example, our previous post XXE in SAML Interfaces demonstrates.

In this post we provide a comprehensive list of different DTD attacks.

The attacks are categorized as follows:
Denial-of-Service AttacksClassic XXEAdvanced XXEServer-Side Requst Forgery (SSRF)XIncludeXSLT