Vor einiger Zeit haben wir uns bereits Clubhouse angeschaut.
Nun gibt es einen neuen, bislang sehr exklusiven deutschen Stern am Audio-Chat-Himmel: Dive – dieser Klon von Clubhouse legt laut Gründer*innen besonders großen Wert auf Datenschutz.

Nachdem ein Zerforschungsmitglied eine Einladung für Dive bekommen hat, haben wir routinemäßig mal in den Datenverkehr geschaut und leider schon wieder Schlimmes gefunden. Nur so viel schonmal: Viel besser als Clubhouse ist das nicht.

Schon als wir das erste Mal in den Traffic geschaut haben, wunderten wir uns: Alle Profilbilder wurden unverschlüsselt über HTTP geladen – völlig grundlos, weil die Bilder von Amazon S3 geladen werden, das TLS unterstützt.

Wer nutzt eigentlich Dive?

Bei Clubhouse gab es eine Lücke, mit der alle User aufgelistet werden konnten. Dive ist so ein guter Klon, sie haben das direkt mit kopiert.

Sucht man über den Such-Endpunkt nach *, liefert dieser alle Nutzer*innen.

{
    "results": [
        {
            "type": "USERS",
            "items": [
                {
                    "item": "UserResult",
                    "type": "USER",
                    "userId": "{USER_UUID}",
                    "username": "{USERNAME}",
                    "description": "{DESCRIPTION}",
                    "firstName": "{FIRST_NAME}",
                    "lastName": "{LAST_NAME}",
                    "profilePhotoUrl": "https://s3.eu-central-1.amazonaws.com/dive-photo-profile/live/{...}",
                    "live": false
                },
                ...
            ],
            "total": 1843
        }
    ]
}

Nachdem wir die Lücke an Dive gemeldet haben, konnte man nicht mehr nach * suchen, um eine Liste aller Nutzer*innen zu bekommen. Stattdessen geht aber ** 🙃

Haben wir alle Usernames, können wir die Profile anfragen. Dort steht jeweils, von wem man eingeladen wurde. So lässt sich sehr einfach der Einladungsgraph rekonstruieren.

Wie ist deine E-Mail-Adresse?

Dive nutzt an vielen Stellen UUIDs, also zufällig generierte, global eindeutige IDs. Das ist schonmal besser, als einfach nur hochzuzählen.

Fragt man über die Dive-API das eigene Profil an, so steht in der URL auch die eigene Nutzer*innen-UUID: /users-service/users/{USER_UUID}

Verwendet man hier eine fremde UUID, die man zum Beispiel in der Suche gefunden hat, so erhält man auch das Profil einer*s anderen Nutzer*in. Dort sind auch einige Informationen enthalten, die sonst nicht öffentlich sichtbar sind, z.B. die E-Mail-Adresse und die Einladungscodes. Dadurch kann man sich von einem beliebigen anderen Account, der noch ungenutzte Einladungscodes hat, einladen lassen. Ein zerforschungs-Mitglied hat seinen Test-Account von “@dive” einladen lassen 🙃.

Wir denken, dass dies eine Verletzung der Datenschutzerklärung ist, in der es heißt: “We may share the following information with all members, as well as with our business partners and the general public: public information such as your username, name and profile pictures;” Eine Veröffentlichung der E-Mail-Adresse ist dort nicht erwähnt.

Du heißt jetzt Horst!

Auch den Endpunkt zum Bearbeiten des Profils haben wir angesehen. An diesen wird ein POST-Request mit einem JSON-Object des folgenden Formats übertragen:

{
    "lastName": "{Nachname}",
    "firstName": "{Vorname}",
    "description": "{Beschreibung}",
    "id": "{USER_UUID}"
}

Sendet man hier statt der eigenen User-UUID die eines*r anderen Nutzers*in, wird stattdessen dessen*deren Profil bearbeitet.

Die Passwörter anderer Nutzer*innen konnten wir nicht ändern. Das liegt einfach daran, dass es diese Funktion in der App (noch?) nicht gibt.

Welche Räume hat dive offen?

Dive nutzt WebRTC für die Audiochats und MQTT für das Signaling. Nachdem man in der App einen Raum betritt, wird durch einen Request die aktuelle MQTT-Config geladen. Die Config scheint für alle Nutzer*innen die gleiche zu sein.

{
  "port": 1883,
  "host": "notify-broker.diverail.com",
  "user": "poc",
  "password": "{PASSWORD}",
  "tls": true
}

Über diesen MQTT-Server lassen sich auf einen Schlag alle aktuell geöffneten Räume abrufen – und wer wann in welchem Raum ist. Auch einzelne Aktionen in den Räumen (Ton an/aus, “Klatschen”) sieht man so.

Dives Reaktion

Wir haben Dive natürlich schnell Bescheid gesagt und um ein Statement gebeten. Dive ist auf unsere Hinweise eingegangen und hat die meisten Sicherheitslücken geschlossen. Nur der MQTT-Server ist noch offen und mit den gleichen Credentials erreichbar. Dies ist laut Dive kein Problem.

Auf die Frage, seit wann die Sicherheitslücken bekannt sind, antwortete uns Dive:

Wir hatten die Vermutung derer Existenz [sic!] und planten, diese zu schließen. Bis zu eurem Bericht hatten wir keinen Vorfall.

Nach Art 33 und Art 34 DSGVO müssen Betroffene und die zuständigen Datenschutzbehörden bei “Verletzungen des Schutzes personenbezogener Daten” informiert werden, wenn bestimmte Bedingungen erfüllt werden.

Diese sieht Dive nach eigener Aussage nicht erfüllt, hat die zuständige Datenschutzbehörde “im Interesse der Transparenz” aber trotzdem benachrichtigt. Sie haben nicht vor, die betroffenen Nutzer*innen zu informieren.

Das finden wir sehr schade und die Berliner Beauftragte für Datenschutz und Informationsfreiheit schrieb zu einem anderen Fall:

Ungeachtet dieser gegebenenfalls vorliegenden Pflicht zur Benachrichtigung Betroffener empfiehlt die Datenschutzbeauftragte prinzipiell, die betroffenen Personen über den Vorfall zu informieren, um möglichst schnell größtmögliche Transparenz herzustellen. Unsere Erfahrungen zeigen, dass Betroffene es bei allem Unmut über einen Datenschutzverstoß ganz überwiegend positiv anerkennen, wenn der Verantwortliche zu seinem Fehler steht und von sich aus und vor allem zeitnah über den Sachverhalt aufklärt.

Für später in diesem Jahr plant Dive ein Bug Bounty Programm.

Fazit

Das ist nun schon das zweite Audio-Chat-Startup, bei dem wir Sicherheitslücken finden. Gerade wenn man sich als datenschutzkonforme Alternative zu Clubhouse anpreist, sollte man auf sowas ganz besonders achten. Und wenn man schon ahnt, dass es solche Lücken gibt, sollte man das Produkt nicht veröffentlichen; auch nicht für eine semi-private Beta.

Die Gründer*innen von Dive haben davor bereits andere Startups gegründet, zB den Scooter-Anbieter circ. Von solchen SerientäternSerial Entrepreneurs hätten wir mehr Erfahrung erwartet und fürchten uns jetzt etwas um die Sicherheit ihrer anderen Dienste.

Dass uns regelmäßig extrem offensichtliche Lücken in Apps deutscher Startups auffallen, schafft kein Vertrauen in die Sicherheit deutscher Softwarekunst.