Advisory für StashCat

1. Übersicht

• CIPHRON-ID: CIPH-2017-1
• Produkt: heinekingmedia StashCat
• Status: Patch verfügbar
• Betroffene Versionen:
  • Android: <= 1.7.5
  • Web: <= 0.0.80w
  • Desktop <= 0.0.86
• Hersteller-URL: https://www.stashcat.com/
• CVE: CVE-2017-11129 bis CVE-2017-11136

Während einer eigenständigen Recherche fanden Researcher von CIPHRON Schwachstellen in kryptographischen und sicherheitsgebenden Funktionen des Instant Messengers StashCat der heinekingmedia GmbH.

CIPHRON hält sich an die Grundsätze des Responsible Disclosure und hat heinekingmedia vorab informiert. heinekingmedia hat sich der Lösung der Befunde bereits angenommen. Es stehen Patches zur Verfügung die sukzessive verteilt werden.

CIPHRON folgt bei seinem Disclosure-Prozess einer hauseigenen Disclosure-Policy. Diese ist unter folgenden Link zu finden:

https://ciphron.de/vulnerability-disclosure-policy

2. Softwarebeschreibung

StashCat wird von der heinekingmedia GmbH entwickelt und hat zum Ziel seinen Kunden einen Instant Messenger zu bieten, der die Kommunikation zwischen verschiedenen Geräten Ende-zu-Ende verschlüsselt, wie es zum Beispiel inzwischen auch von WhatsApp oder Telegram bekannt ist. Erwähnenswert ist hierbei, dass der Messenger neben der Android- bzw. iOS-App auch einen Web- und einen Desktopclient anbietet.

Laut heinekingmedia ist der Messenger insbesondere auch für dein Einsatz bei Polizei und Behörden angedacht.

Mehr Information sind unter

https://www.stashcat.com/

erhältlich.

Laut Web-Client-Webseite unter

https://app.stashcat.com

wurde die Version 0.0.80w untersucht.

Die untersuchten Android-Versionen waren die Versionen 1.5.18 und 1.7.5 .

Der Desktop-Client hatte die Version 0.0.86 laut Installationsdatei.

3. Schwachstellenbeschreibung

Die Schwachstellen wurden durch einen halbtägigen Code-Review des Web-Clients gefunden. Dies war möglich, da dieser in Angular geschrieben ist und der Client-JavaScript-Code direkt unter

https://app.stashcat.com

einsehbar ist.

Der Desktop-Client ist mit Electron gebaut und basiert in seiner Grundfunktionalität auf dem Web-Client-Code

In der Android-App wurden ebenfalls Schwachstellen durch Reverse Engineering gefunden. Die Befunde aus dem Code-Review des Web-Clients wurden des Weiteren durch das Reverse Engineering verifiziert, soweit das Protokoll direkt betroffen war.

Die Schwachstellen haben CVEs zugewiesen bekommen. Diese sind CVE-2017-11129 bis CVE-2017-11136.

CIPHRON hat die Befunde im Laufe des Disclosure-Prozesses von einer unabhängigen dritten Partei, dem Niedersachsen-CERT (N-CERT), verifizieren lassen.

Wir haben heinekingmedia die Möglichkeit gegeben die Befunde zu kommentieren.

3.1 Kommunikation durch Anbieter entschlüsselbar

CVE-2017-11136

Es ist ersichtlich, dass der auf den Endgeräten erzeugte private Schlüssel des RSA-Schlüsselpaars, das zum Austauschen eines Passworts für die symmetrische Verschlüsselung des Kommunikationskanals genutzt wird, an die StashCat-Server übertragen wird.

Des Weiteren besteht das Passwort, mit dem der private Schlüssel selbst verschlüsselt ist, aus den ersten 32 Byte des SHA512-Hashs des Benutzerpassworts. Dieses wird aber ebenfalls an den Anbieter-Server übertragen, da es gleichzeitig das Anmeldepasswort ist.

Dies erlaubt das Entschlüsseln der privaten Schlüssel von StashCat-Nutzern womit jeder mit Zugriff auf die Anbieter-Server die eigentlich Ende-zu-Ende-verschlüsselte Kommunikation entschlüsseln kann, da das Passwort zur symmetrischen Verschlüsselung des Kommunikationskanals abgefangen werden kann.

Kommentar heinekingmedia:

Passwörter zur Sicherung des private Keys sind jetzt unabhängig von dem verwendeten Account Passwort.

RSA Keys sind jetzt zusätzlich 4096 Bit.

3.2 Es wird keine Key-Derivation-Function genutzt

CVE-2017-11131

Statt eine Key-Derivation-Function zu nutzen, um das eigentliche Passwort zur Authentifizierung zu erzeugen, wird das vom Benutzer eingegebene Passwort direkt mit SHA512 gehashed. Von diesem Hash werden wiederum nur die ersten 32 Byte genutzt. Stand der Technik ist die Nutzung einer Key-Derivation-Function, wie zum Beispiel PBKDF2 zu nutzen, um aus einer Quelle niedriger Entropie, wie es Benutzereingaben sind, ein Passwort hoher Entropie zu erzeugen.

Des Weiteren werden so Rainbow-Table-Angriffe effektiv unterbunden.

Kommentar heinekingmedia:

RSA Keys werden nach PKCS#8 verschlüsselt. PBKDF2 wird intern verwendet.

3.3 Passwörter mit math.random() erzeugt

CVE-2017-11133

Die eigentliche Kommunikation wird mit AES im CBC-Mode verschlüsselt. Die Passwörter zur Verschlüsselung des Kommunikationskanals sowie der IV, die mit dem RSA-Schlüsselpaaren der Kommunikationsteilnehmer ausgetauscht werden, werden mit math.random() erzeugt.

In neueren Versionen wird CryptoJS.lib.WordArray.random() genutzt, dass intern ebenfall math.random() einsetzt. Dieses Methode gilt nicht als kryptographisch sicher. Stattdessen müssen die so erzeugten Passwörter als deterministisch angesehen werden, was unter Umständen zu einer Kompromittierung des Kommunikationskanals führen kann.

Kommentar heinekingmedia:

Channel und Konversations Secrets werden nicht länger mit CryptoJS erzeugt.

3.4 Integrität und Authentizität nicht sichergestellt

CVE-2017-11130

Die Integrität und Authentizität von verschlüsselten Nachrichten wird nicht sichergestellt. Dies erlaubt zum Beispiel Replay-Attacken in Man-in-the-Middle-Szenarien.

Kommentar heinekingmedia:

Vom Server erzeugte Ausgaben werden signiert und können vom Client unter Verwendung des public Keys des Servers verifiziert werden.

3.5 Logouts ohne Authorisierung

CVE-2017-11135

Logouts von Benutzern sind ohne Authorisierung möglich, da nur die Device-ID benötigt wird.

Kommentar heinekingmedia:

Zum Logout eines Gerätes ist lediglich die device_id erforderlich. Dies ist ein gewolltes Verhalten und führt dazu, dass die Daten auf dem ausgeloggten Endgerät gelöscht werden.

Dies stellt nicht einmal ansatzweise eine Sicherheitslücke dar.

Kommentar CIPHRON:

Unserer Ansicht nach kann dies ein Problem darstellen, wenn ein Angreifer es schafft die Device-IDs einer Organisation zu enumerieren. Dies kann für eine Denial-of-Service-Attacke genutzt werden.

3.6 Android-Keystore nutzt hart-kodiertes Passwort

CVE-2017-11129

Der Android-Keystore nutzt ein hart einprogrammiertes Passwort. Hierdurch ist es möglich, dass Dritte direkt die hierin enthaltenen Passwörter auslesen können, sobald sie Zugriff auf den Keystore erlangen.

Kommentar heinekingmedia:

Es wird kein hart-kodiertes Passwort mehr verwendet.

Das zuvor hart-kodierte Password für den Keystore in dem sich der Datenbank-Veschlüsselungskey befand wird nun in mehreren Schritten generiert. Hierfür wird ein Random String generiert, der sich nach jedem Logout ändert, der in den shared preferences gespeichert wird und ein String der aus Manufacturer und Model erstellt wird über mehrere Schritte hin mit xor kombiniert und als Encryption-Key verwendet. Danach wird aus diesem Key und der Device ID ein weiterer Key generiert, der als Password für den Keystore verwendet wird.

3.7 Kein Certificate Pinning

CVE-2017-11132

Die App setzt kein Certificate Pinning ein. Stattdessen wird lediglich die Signatur der Certificate Authority überprüft. Dies erleichtert Man-in-the-Middle-Angriffe.

Anmerkung: Dieser Befund wurde unabhängig vom Disclosure-Prozess in Android-Versionen nach 1.5.18 behoben.

Kommentar heinekingmedia:

Alle Apps verwenden Certificate Pinning oder HPKP um Man-in-the-Middle-Angriffe zu erschweren.

3.8 Anmeldedaten in den Logs

CVE-2017-11134

Die Android-App speichert Anmeldedaten in den Log-Dateien was unter Umständen Angreifern Zugriff auf diese Daten verschaffen kann.

Kommentar heinekingmedia:

In Fällen von Exceptions wurde die Aufruf in das Log auf dem Gerät gespeichert.

Diese Log Einträge werden jetzt im Vorfeld von Zugangsdaten bereinigt.

4. Lösung

heinekingmedia hat sich der Befunde angenommen und wird sukzessive Patches verteilen, die bereits zur Verfügung stehen.

5. Credits

Der Code-Review und das Reverse Engineering wurden durch Karsten König von CIPHRON durchgeführt. Sebastian Horzela und Lennart Henke unterstützten hierbei.

Das Niedersachen-CERT verifizierte als unabhängige dritte Partei die Befunde von CIPHRON.

6. Greets

Grüße an das Team bei CIPHRON, insb. Martin, Jan und Frithjof für die guten Gespräche und die gute Stimmung im Büro.

7. Disclosure-Protokoll

10.03.2017 Hersteller kontaktiert

15.03.2017 Zweite Kontaktaufnahme, da keine Antwort erhalten

15.03.2017 Telefonat mit heinekingmedia

15.03.2017 Befunde übermittelt

06.06.2017 Mitteilung, dass die Befunde gelöst sind

28.06.2017 Übersendung des zu veröffentlichen Berichts zur Abstimmung

11.07.2017 Bericht an N-CERT übergeben, da keine Rückmeldung an CIPHRON

17.07.2017 Abstimmung mit heinekingmedia zum weiteren Vorgehen

18.07.2017 Kommentare zu den Befunden an CIPHRON durch heinekingmedia übergeben

19.07.2017 Anmerkungen zu den Kommentaren an heinekingmedia gesendet

19.07.2017 Übergabe angepasster Vorabversion des Berichts inkl. Kommentare

19.07.2017 Abstimmung zur Veröffentlichung des Berichts

19.07.2017 Meldung, dass Befunde bis Ende der nächsten Woche behoben sein werden

28.07.2017 Meldung, dass Patches für Befunde entwickelt wurden

28.07.2017 Mündliche Besprechung der Patches

31.07.2017 Veröffentlichung des Berichts

8. Über CIPHRON

Die CIPHRON GmbH ist ein 2003 gegründetes Beratungsunternehmen für Informationssicherheit mit Sitz in Hannover, Deutschland. Als Dienstleister für Informationssicherheit führt CIPHRON unter anderem Penetrationstests, Code-Reviews und individuelle Forschung zu Sicherheitsthemen durch.

Mehr Informationen sind unter

https://ciphron.de

zu finden