Coronavirus: Covid-19-App der Telekom prüft Zertifikate nicht
Bei der Entwicklung einer App, mit der Patienten ihre Covid-19-Testergebnisse abrufen können, wurde wenig Wert auf Sicherheit gelegt.

Die von der Deutschen Telekom und der Firma BS Software Development bereitgestellte App, mit der Resultate von Covid-19-Tests kommuniziert werden, prüft bei der Verbindung zum Server das Zertifikat nicht. Damit können Angreifer die Daten mitlesen. Berichtet hatte das die Zeitschrift c't, deren Leser Nicolas Thumann hatte das Problem entdeckt.
In der App gibt man als Nutzer entweder manuell oder durch Scannen eines QR-Codes eine Kennung ein, anschließend wird eine Verbindung zum Server aufgebaut. Diese Verbindung erfolgt mittels HTTPS, dabei wird allerdings das Zertifikat nicht geprüft. Laut c't war auf dem Server zum Zeitpunkt ihres Tests ein bereits mehrere Jahre abgelaufenes Zertifikat installiert.
Beliebiges Zertifikat wird akzeptiert
Wir konnten in einem Test das Verhalten der App nachvollziehen. Wenn man sich mit einem Tool, das den Datenverkehr von Android-Apps mitliest, in die Verbindung einklinkt und dabei ein selbstsigniertes Zertifikat verwendet, wird die Verbindung trotzdem aufgebaut. Das veraltete Serverzertifikat fanden wir nicht mehr, inzwischen nutzt der Server ein gültiges Zertifikat von Let's Encrypt.
Die fehlende Zertifikatsprüfung führt dazu, dass ein Angreifer im selben Netzwerk oder auf einem System zwischen dem Nutzer und dem Server den Datenverkehr mittels eines Man-in-the-Middle-Angriffs mitlesen. Mit Hilfe der abgefangenen Testkennung, die mittels HTTPS übertragen wird, kann der Angreifer dann das Testergebnis selbst abfragen. Weitergehende Persönliche Daten wie etwa der Name des Patienten werden nicht übertragen.
Laut c't hat die Firma BS Software Development angekündigt, in Kürze eine aktualisierte Version der App zu veröffentlichen. Auf der Webseite der App finden sich bislang keine Hinweise zu den Sicherheitsproblemen.
"Zugriffsverletzung bei Adresse 000000000040EA25"
Als wir in unseren Tests mit einer ungültigen Beispielkennung, die auf einem Bild des App-Herstellers zu finden ist, ein Testergebnis abrufen wollten, zeigte sich ein weiterer Fehler. Statt einer Antwort erhielten wir eine Fehlermeldung, die vom Server stammte: "Zugriffsverletzung bei Adresse 000000000040EA25 in Modul 'QC_ServiceCom.exe'. Lesen von Adresse FFFFFFFFFFFFFFFF" - an dieser Stelle bricht die Meldung unvollständig ab.
Die Meldung deutet darauf hin, dass die Software auf dem Server abstürzt und dabei einen fehlerhaften Speicherzugriff verursacht. Möglicherweise handelt es sich um eine weitere Sicherheitslücke. Dass dem Angreifer hier die genaue Speicheradresse des Fehlers mitteilt, könnte Angriffe sogar erleichtern.
Nachtrag vom 1. April 2020, 18:36 Uhr
Ursprünglich hatten wir geschrieben, dass eine Manipulation der übertragenen Daten möglich ist. Der Geschäftsführer der Firma BS Software Development, Jürgen Bucher, hat uns dazu folgendes geschrieben: "Die gesamte Kommunikationskette ist End-2-End verschlüsselt. Es ist daher auch durch eine Man-in-the-Middle-Attacke nicht möglich, Daten einzusehen oder gar zu manipulieren."
Das war für uns allerdings nicht nachvollziehbar. Da die Testkennung über reines HTTPS ohne Zertifikatsprüfung übertragen wird kann ein Angreifer diese Kennung abfangen und dann selbst das Ergebnis abfragen. Eine Manipulation der Daten wird dadurch aber möglicherweise verhindert, daher haben wir den Text entsprechend angepasst.
Die Telekom bat uns zudem, darauf hinzuweisen, dass die App vollständig von der Firma BS Software Development entwickelt wurde, die Telekom hat als Cloud-Partner die entsprechende Serverinfrastruktur bereitgestellt.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Auch wenn in kurzer Zeit: Ein aktuelles Zertifikat bereit zu stellen ist jetzt keine...
Joa, dafür spricht auch der Server Identifier: DatasnapHTTPService/2011 Das ist von...
"Die Telekom bat uns zudem, darauf hinzuweisen, dass die App vollständig von der Firma BS...
Der server lauscht nicht auf port 80. (Was in dem Fall auch kein Problem ist da das ja...