Vivy akzeptiert beliebigen Schlüssel
Problematischer wurde es, wenn der Arzt das Dokument noch nicht abgerufen hat. Dann konnte der Angreifer dem Server einen öffentlichen Schlüssel schicken. Der Server leitete diesen Schlüssel ohne jede Prüfung an den Client weiter, das Dokument wurde damit verschlüsselt. Anschließend konnte das verschlüsselte Dokument heruntergeladen werden. Da der Angreifer selbst den Schlüssel setzen konnte, besaß er auch den passenden privaten Schlüssel.
Das Zeitfenster für einen solchen Angriff ist im Normalfall gering, da es üblicherweise so gedacht ist, dass der Arzt ein geteiltes Dokument direkt abruft. Ein gezielter Angriff wäre daher schwierig. Doch ein Angreifer hätte einfach wahllos nach gültigen Kennungen suchen, wenn möglich Dokumente herunterladen und somit potenziell Kenntnis von privaten Patientendaten erlangen können.
Ein weiteres Problem: Die Kennung für die Dokumente wurde gleich an vier externe Dienstleister weitergeleitet, deren Services in der Vivy-App integriert sind. Diese hätten den Angriff dann sehr schnell durchführen und potenziell auf Dokumente zugreifen können.
Schlüssel auslesen mit Cross-Site-Scripting
Bei der Verschlüsselung gab es bei Vivy eine ganze Reihe von Problemen. Vivy wirbt damit, dass die Daten Ende-zu-Ende-verschlüsselt werden. Theoretisch ist das korrekt, doch bei der Implementierung wurde eine ganze Reihe von Fehlern gemacht und auch fragwürdige Designentscheidungen getroffen.
Auf Seiten des Arztes ist Vivy im Moment als Webanwendung implementiert. Generell ist die Verwendung von Webanwendungen in Kombination mit einer Ende-zu-Ende-Verschlüsselung nicht allzu sinnvoll. Denn eine Ende-zu-Ende-Verschlüsselung soll davor schützen, dass der Betreiber die Daten selbst lesen kann. Doch bei einer Webanwendung kann der Betreiber jederzeit einem bestimmten Nutzer eine veränderte Webseite unterschieben, die dann die Daten unverschlüsselt ausliest.
Ein weiterer Effekt, auf den Modzero hinweist: Wenn ein Angreifer eine Cross-Site-Scripting-Lücke in der Webanwendung findet, kann er den privaten Schlüssel des Arztes einfach auslesen. Das hätte man vermeiden können, wenn man die in modernen Browsern vorhandene Webcrypt-API verwendet; die sieht nämlich nicht extrahierbare Schlüssel vor. Doch darauf hatte Vivy ursprünglich verzichtet.
Modzero fand gleich eine ganze Reihe von Cross-Site-Scripting-Lücken in Vivy. So konnte man in Dokumenten selbst HTML-Code unterbringen, etwa in einer SVG-Datei. Auch Profilfotos von Patienten konnten HTML-Dokumente sein. Und in den Feldern für den Vor- und Nachnamen von Patienten können diese HTML-Code eintragen, der bei der Ausgabe in der Arzt-App nicht gefiltert oder codiert wurde.
Die Verschlüsselung selbst nutzte veraltete Technologien. So wurden die Daten mit dem CBC-Modus verschlüsselt und es kam keinerlei Authentifizierung zum Einsatz. Dieser Modus verschlüsselt Daten zwar, er schützt sie aber nicht vor Manipulation. Diese Schwäche war die Grundlage für den Efail-Angriff, der im Frühjahr Schwachstellen in OpenPGP und S/MIME aufzeigte.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Krankenkassen: Vivy-App gibt Daten preis | Vivy wurde von mehreren Sicherheitsfirmen geprüft |
Und das beurteilt wer? Könnte sich ein Arzt und halt dann auch ein Apotheker lückenlos...
TÜV überprüft ja tatsächlich nicht die Sicherhet eines Produktes, sondern einfach nur ob...
Kann ich dir sagen. Das o.g. Problem lässt sich sogar sehr einfach lösen. Man verwendet...
Ihre Analyse ist im Artikel verlinkt. Die letzten fünf Absätze des Artikels beziehen...
Ja stimmt schon, selbst wenn die Pin nicht lang genug ist, jede Bank sperrt den Zugang...