Einer der beliebtesten und als besonders sicher angepriesener Messenger, Threema, geriet diese Woche in den Mittelpunkt eines Skandals. Forscher der ETH Z\u00fcrich, einer \u00f6ffentlichen Forschungsuniversit\u00e4t in der Schweiz, fanden sieben (7!) Sicherheitsl\u00fccken in den Protokollen von Threema. Die Entwickler der App spielten die Bugs herunter und erkl\u00e4rten in einem Blogbeitrag, dass sie \u201ealle Probleme innerhalb weniger Wochen behoben\u201c h\u00e4tten und \u201ekeines der Probleme jemals nennenswerte Auswirkungen auf die reale Welt gehabt h\u00e4tte\u201c. Was steckt dahinter, und sollten Sie nun sofort zu Signal wechseln?<\/p>\n
Forscher der ETH Z\u00fcrich, einer \u00f6ffentlichen Forschungsuniversit\u00e4t in der Schweiz, fanden 7 Sicherheitsl\u00fccken in den Protokollen von #Threema.<\/p>Tweet<\/a><\/blockquote>\n
Es ist schwierig, dem Threema-Skandal auf den Grund zu gehen, denn das Verhalten beider Seiten ist zwar zivilisiert, aber trotzdem nicht ideal. Das Team der ETH Z\u00fcrich hat die Bedeutung seiner Arbeit<\/a>, die nicht nur Schwachstellen, sondern auch hypothetische Exploit-Szenarien beschreibt, eindeutig \u00fcberbewertet, w\u00e4hrend die Entwickler von Threema die Schwere der Schwachstellen eindeutig herunterspielen<\/a>, indem sie behaupten, dass es nahezu unm\u00f6glich sei, diese auszunutzen.<\/p>\n
Sollten Sie nur an den praktischen Erkenntnissen interessiert sein, empfehlen wir Ihnen, direkt zum Ende unseres Beitrags zu springen <\/a>. <\/a><\/p>\n
Threema-Schwachstellen<\/h2>\n
Alle Schwachstellen wurden im Oktober verantwortungsbewusst offengelegt und umgehend behoben. Nach Angaben beider Seiten wurde keine dieser Schwachstellen in freier Wildbahn ausgenutzt; es gibt daher keinen Grund, sich vor der Ver\u00f6ffentlichung der Informationen \u00fcber diese Schwachstellen zu f\u00fcrchten. Einen Grund zur Sorge gibt es dennoch.<\/p>\n
Konzentrieren wir uns auf das, was sich aus einer sorgf\u00e4ltigen Lekt\u00fcre des ETH-Berichts, dem Statement von Threema und anderen \u00f6ffentlich zug\u00e4nglichen Studien \u00fcber die Threema-App und ihre Protokolle ableiten l\u00e4sst.<\/p>\n
Die App verwendet starke kryptografische Algorithmen mit robuster, standardisierter NaCl-Implementierung, all das verpackt in Threemas eigenem Informationsaustauschprotokoll, dessen Implementierung unvollkommen ist. So besteht die M\u00f6glichkeit verschiedener theoretischer Angriffe (wie das Versenden einer Nachricht in einem Gruppenchat, die f\u00fcr verschiedene Empf\u00e4nger unterschiedlich aussieht), aber auch einiger praktischer Angriffe. So kann beispielsweise jeder mit physischem Zugriff auf das Ziel-Smartphone relativ einfach die Threema-Datenbanken und -Backups darauf lesen \u2013 wenn keine Passphrase zum Schutz der App festgelegt wurde. Zudem ist es m\u00f6glich, eine Threema-ID zu klonen, was Angreifern erm\u00f6glicht, Nachrichten im Namen des Opfers zu versenden (wenn auch nicht gleichzeitig). Nat\u00fcrlich sind alle Szenarien, die einen physischen Zugriff auf ein Smartphone mit sich bringen, f\u00fcr jede App das Worst-Case-Szenario, und nur schwer zu verteidigen.<\/p>\n
Einige der vorgeschlagenen hypothetischen Angriffe \u00fcber die neuen Schwachstellen w\u00fcrden nur funktionieren, wenn Angreifer die volle Kontrolle \u00fcber das Netzwerk zum Datenaustausch haben. Das allein reicht jedoch nicht aus; es sind noch weitere komplexe Exploit-Bedingungen erforderlich. Ein Szenario erfordert beispielsweise, dass das Opfer gezwungenerma\u00dfen eine Nachricht mit sehr seltsamen Inhalten \u00fcber Threema verschickt. Das wird in der Praxis wohl kaum funktionieren.<\/p>\n
Von den Schwachstellen des Kommunikationsprotokolls selbst ist das Fehlen einer Forward und Future Secrecy<\/a> besonders beunruhigend. Das bedeutet, dass bei Entschl\u00fcsselung einer Nachricht auch sp\u00e4tere Nachrichten entschl\u00fcsselt werden k\u00f6nnen. Diese Schwachstelle ist schon seit einiger Zeit bekannt<\/a>, weshalb Threema im Dezember eine grundlegend neue, sicherere Version seines Protokolls angek\u00fcndigt hat. Dieses neue Protokoll \u2013 Ibex \u2013 muss sich noch unabh\u00e4ngigen Sicherheitsaudits unterziehen. Wir k\u00f6nnen die Entwickler nur beim Wort nehmen, wenn sie sagen, dass es alle Facetten der modernen praktischen Kryptographie abdeckt. Threema w\u00e4re gut beraten, den Rat der ETH Z\u00fcrich zu beherzigen, die Protokolle in den fr\u00fchen Entwicklungsphasen extern pr\u00fcfen zu lassen \u2013 und nicht erst nach ihrer Ver\u00f6ffentlichung.<\/p>\n
Um einige der Schwachstellen auszunutzen, m\u00fcsste der Threema-Server kompromittiert werden und jemand auf Betreiberseite absichtlich versuchen, ausgetauschte Daten zu stehlen oder die Kommunikation zu st\u00f6ren. Dies ist vor allem f\u00fcr Unternehmen wichtig, die Threema Work nutzen: Wenn ein Unternehmen seine Daten nicht einmal einem hypothetischen Risiko aussetzen kann, sollte es einen Wechsel zu Threema OnPrem in Erw\u00e4gung ziehen, wo es seinen eigenen internen Threema-Server hat. In diesem Fall m\u00fcssen die Administratoren nach M\u00f6glichkeiten suchen, die Sicherheit des Servers zu erh\u00f6hen (auch H\u00e4rten<\/em> genannt).<\/p>\n
Auch App-Entwickler m\u00fcssen aus dieser Situation ihre Lehren ziehen. \u201eDenkt euch keine eigenen kryptographischen Algorithmen aus\u201c schreien Kryptographie-Experten seit jeher unaufh\u00f6rlich (Telegram zum Beispiel hat das v\u00f6llig ignoriert). Doch die Entwickler von Threema haben bew\u00e4hrte kryptografische Algorithmen mit ihrer korrekten Standardimplementierung verwendet! Durch den Einsatz von Standardkryptographie im urspr\u00fcnglichen Client-Server-Kommunikationsprotokoll, das anstelle von Standard-TLS verwendet wird, konnten sich eine Reihe von Bugs einschleichen. Es scheint fast so, als h\u00e4tten die Experten schreien sollen: \u201eEntwickelt weder eure eigenen kryptografischen Algorithmen noch Protokolle!\u201c<\/p>\n
Praktische Tipps<\/span><\/h2>\n
Wenn Sie sich f\u00fcr Threema entschieden haben, weil Sie gedacht haben, es sei der \u201emeistverschl\u00fcsselte Messenger\u201c, es Ihnen aber nichts ausmacht, Ihre Telefonnummer mit einem Instant Messenger zu verwenden, und Sie nichts von technischen Details wissen m\u00f6chten, sollten Sie besser zu Signal wechseln. Wie echte Hacks<\/a> und Gerichtsbeschl\u00fcsse<\/a> gezeigt haben, sind die Kryptografie und die Datenspeicherung von Signal robuster und widerstandsf\u00e4higer. Wenn Sie Threema als Ihren Hauptarbeits-Messenger verwenden m\u00fcssen oder Sie die Tatsache m\u00f6gen, dass Ihre Threema-ID nicht mit Ihrer Telefonnummer verkn\u00fcpft ist, k\u00f6nnen Sie den Messenger nat\u00fcrlich auch in Zukunft verwenden \u2013 den Risiken sollten Sie sich jedoch bewusst sein. Sie m\u00f6gen zwar hypothetisch sein \u2013 aber sie sind nicht v\u00f6llig auszuschlie\u00dfen. Stellen Sie sicher, dass Sie die Threema-IDs neuer Kontakte doppelt \u00fcberpr\u00fcfen und offline verifizieren, und verwenden Sie Passphrasen f\u00fcr eine sichere Anmeldung.<\/p>\n
Mittlere und gro\u00dfe Unternehmen, die Threema in ihren Gesch\u00e4ftsprozessen einsetzen, sollten ernsthaft \u00fcber eine Migration zu Threema OnPrem nachdenken, um die volle Kontrolle \u00fcber die Messenger-Server zu haben.<\/p>\n","protected":false},"excerpt":{"rendered":"
Was, wenn Ihr geheimer Messenger nicht ganz so geheim ist, wie es scheint?<\/p>\n","protected":false},"author":2722,"featured_media":29670,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[6,10],"tags":[2103,984,130,1654,156],"class_list":{"0":"post-29669","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-news","8":"category-tips","9":"tag-encryption","10":"tag-messenger","11":"tag-privatsphare","12":"tag-tips","13":"tag-verschlusselung"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/7-threema-vulnerabilities\/29669\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/7-threema-vulnerabilities\/25074\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/7-threema-vulnerabilities\/20568\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/7-threema-vulnerabilities\/10437\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/7-threema-vulnerabilities\/27657\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/7-threema-vulnerabilities\/25397\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/7-threema-vulnerabilities\/25714\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/7-threema-vulnerabilities\/28287\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/7-threema-vulnerabilities\/34527\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/7-threema-vulnerabilities\/46772\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/7-threema-vulnerabilities\/20011\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/7-threema-vulnerabilities\/20584\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/7-threema-vulnerabilities\/33163\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/7-threema-vulnerabilities\/25764\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/7-threema-vulnerabilities\/31437\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/7-threema-vulnerabilities\/31150\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/encryption\/","name":"Encryption"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29669","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=29669"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29669\/revisions"}],"predecessor-version":[{"id":29671,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29669\/revisions\/29671"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/29670"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=29669"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=29669"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=29669"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}