Insecurities of WhatsApp's, Signal's, and Threema's Group Chats

Recently, the theoretical and practical analysis of secure instant messenger protocols received much attention, but the focus of prior evaluations mostly lay in one-to-one communication. In this blog post we want to presents the results of our work that focuses on group chat protocols of three major instant messenger applications; namely Signal, WhatsApp, and Threema.

In this blog post, we aim to focus on the practical impact and the found weaknesses identified by our analysis. The interested reader may also look into our paper for more details.

CORS misconfigurations on a large scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers.

The issue: CORS misconfiguration

Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misconfigurations which can potentially be exploited. For more technical details on the issues read the this fine blogpost.

Misconfiguation	Description
Developer backdoor	Insecure developer/debug origins like JSFiddler CodePen are allowed to access the resource
Origin reflection	The origin is simply echoed in ACAO header, any site is allowed to access the resource
Null misconfiguration	Any site is allowed access by forcing the null origin via a sandboxed iframe
Pre-domain wildcard	notdomain.com is allowed access, which can simply be registered by the attacker
Post-domain wildcard	domain.com.evil.com is allowed access, can be simply be set up by the attacker
Subdomains allowed	sub.domain.com allowed access, exploitable if the attacker finds XSS in any subdomain
Non-SSL sites allowed	An HTTP origin is allowed access to a HTTPS resource, allows MitM to break encryption
Invalid CORS header	Wrong use of wildcard or multiple origins,not a security problem but should be fixed