Die schweizerische Covid-Politik hat ihre Ups und Downs, das BAG hat die Digitalisierung verschlafen und die Kantone greifen teilweise zu sehr datenintensiven Massnahmen im Contact Tracing. Da geht dann schnell mal vergessen, dass der Bund bereits bei der Einführung der Covid-App auf Datensparsamkeit und Transparenz Wert legte. Mit dem Covid-Zertifikat ging es im selben Stil weiter: einerseits wurde der gesamte Source-Code auf Github veröffentlicht, andererseits zu einem öffentlichen Security-Test eingeladen.
Nach sechs Wochen liegen nun die ersten Ergebnisse des Security-Tests vor, wir haben den Report angeschaut. Insgesamt wurden 136 Befunde veröffentlicht (mehrere kritische Mängel werden noch analysiert und aus Sicherheitsgründen vorerst nicht publiziert) und wie folgt klassifiziert:
| Klassifikation | Anzahl | Beschreibung |
| Ongoing | 53 | Das im Befund beschriebene Problem wird als solches anerkennt, die Behebung dauert aber noch an |
| Fixed | 44 | Das im Befund beschriebene Problem wurde behoben |
| Wontfix | 35 | Das im Befund beschriebene Problem wird nicht behoben |
| False Positive | 4 | Das im Befund beschriebene Problem hat sich bei näherer Betrachtung als nicht-problematisch herausgestellt |
Zu 24 Befunden liegen Details vor, 112 Befunde stammen vom nationalen Testinstitut für Cybersicherheit (NTC) welches die Details in einem eigenen Bericht beschreiben wird. Aufgrund der Themen der NTC-Befunde ist anzunehmen, dass einige davon Duplikate der detailliert beschriebenen Befunde sind.
Zu den Befunden im Detail
Unter den dokumentierten Befunden sind einige Klassiker der Softwareentwicklung:
Direkt im Code enthaltene Passwörter
Im Quellcode der diversen Covid-Applikationen sind an mehreren Stellen hard-codierte Passwörter zu finden, d.h Passwörter welche direkt im Code festgeschreiben sind. Ist ein derart festgelegtes Passwort erst mal im produktiven Einsatz, ist es später nur mit grossem Aufwand möglich, dieses zu ändern (da dann für jede Passwort-Änderung eines Accounts auch eine neue Version der Software installiert werden muss). Glücklicherweise stellen diese, sofern die Serverinfrastruktur an sich richtig abgesichert ist, nicht direkt einen ausnutzbaren Angriffspunkt dar, sind aber nichtsdestrotrotz ein Risiko, welches man nach Möglichkeit aus dem Weg räumen sollte.
Zum Hintergrund: Passwort-Management ist aufwändig, und während der Entwicklung greift man gerne mal auf im Softwarecode direkt definierte Passwörter zurück um sich das Leben einfach zu machen, vor allem wenn der Zeitdruck hoch ist. Das ist grundsätzlich kein Problem, heikel wird es aber wenn die Zeit nicht mehr reicht um den Code rechtzeitig vor dem Go-Live entsprechend anzupassen. Als Alternative bietet sich der Einsatz von zertifikats-basierten Logins an, oder zumindest das Ablegen des Passwort in einem (hoffentlich verschlüsselten) Konfigurationsfile (welches einfacher austauschbar ist als ein ganzes Softwarepaket).
Verwendung von nicht verifizierten Zusatzkomponenten
Moderne Web- und Smartphone-Applikationen sind oft unabhängig von der Funktionalität nach demselben Schema aufgebaut, und werden auch auf dieselbe Art für die Installation auf dem jeweiligen Server bzw. der Veröffentlichung in den AppStores zusammengebaut. Es ist daher nicht überraschend dass bei diesem Zusammenbauen auf Standardfunktionalitäten von GitHub zurückgegriffen wird (technisch gesprochen auf Aktions innerhalb von Workflows). Das riskante daran ist, dass diese Funktionalität nicht unter Kontrolle der App-Entwicklerin steht, ein böswilliger Angreifer hier also Schadcode einspielen könnte.
Zur besseren Absicherung muss die Entwicklerin nicht zwingend sämtliche Zusatzkomponenten in die eigene Code-Basis kopieren. Es reicht, beim Einbinden Funktionalität die Versionsnummer der Zusatzkomponente explizit zu benennen und eine Prüfsumme über den Code zu bestimmen (welche dann mit einer vorab erstellten Prüfsumme der als “gut” erkannten Version verglichen wird). Bei Unstimmigkeiten (also bei unerwarteten Veränderungen in der Zusatzkomponente) wird der Entwicklerin dann eine Fehlermeldung angezeigt bevor eine allenfalls böswillige Veränderung Schaden anrichten kann.
Verwendung von nicht mehr zeitgemässen Verschlüsselungsalgorithmen
Für den Zugriff auf die Webseite, mit welcher die Covid-Zertifikate ausgestellt werden können, werden Verschlüsselungsalgorithmen eingesetzt, welche das Ende ihrer Nutzungsdauer erreicht haben. Dies bedeutet meist, dass die verwendete Schlüssellänge auf moderner Hardware keinen ausreichenden Schutz mehr bietet (d.h. verschlüsselte Daten innert nützlicher Frist entschlüsselt werden können). Auch wenn keine konkreten Angriffe auf diese Algorithmen bekannt sind, ist es angebraucht sie zu entfernen.
Zum Hintergrund: Bei der Verwendung von https gibt es eine ganze Reihe von Verschlüsselungsalgorithmen welche Webserver und Browser grundsätzlich einsetzen können. Typischerweise wird beim Verbindungsaufbau (also beim Zugriff auf die Webseite) der jeweils beste/sicherste Algorithmus ausgehandelt welcher von beiden Seiten unterstützt wird. Heikel wird es zum Beispiel, wenn ein Besucher mit einem alten Browser (der nur schwache Algorithmen unterstützt) auf Seiten zugreift, da dann einer dieser schwachen Algorithmen der gemeinsam “beste” ist. Die Sicherheit der Verbindung ist dann nicht gewährleistet.
Ungenügende Validierung von Eingabewerten
Validierungen von Eingabewerten (also die Überprüfung ob ein Eingabewert plausibel ist, also niemand als Geburtstag den 29.2.2013 nennt oder in 1001 St. Gallen wohnt) gehen gerne mal vergessen. Bei Texteingaben führt das unter Umständen zu Cross Site Scripting-Attacken oder Buffer Overflows (mit welchen sich Programmcode verändern lässt), bei numerischen Werten eher zu unerwarteten Rechenergebnissen. Im Falle der Covid-Zertifikate wird das Geburtsjahr bei der Erstellung auf ein einen Wert zwischen 1900 und 2099 validiert. Während die Untergrenze wohl kein Problem darstellen sollte, erlaubt die Obergrenze zumindest grundsätzlich die Erstellung von Zertifikaten für noch nicht geborene Personen. Natürlich ist das kein Sicherheitsrisiko, aber recht einfach vermeidbar indem für die Obergrenze das aktuelle Jahr verwendet wird.
Ins selbe Thema fällt die Tatsache, dass bei der Erstellung von Zertifikaten die für Name und Adressen verwendeten Eingaben nicht speziell eingegrenzt werden sondern jedes über die Tastatur eingebbare Zeichen erlaubt ist. Dies erlaubt die Eingabe von Unicode-Sonderzeichen wie Zeilenumbrüchen, Wechseln der Schreibrichtung auf links-nach-rechts etc. welche anschliessend bei der Erstellung des Zertifikat-PDFs zu Problemen führen und im PDF selbst nicht angezeigt werden. Da das Problem zum Beispiel auch chinesische Zeichen betrifft (und nicht auszuschliessen ist, dass ein in der Schweiz geimpfter Chinese ein Zertifikat mit chinesischen Zeichen wünscht), besteht hier ein potentiell ein reales Problem für die Anwendung.
Hinzu kommen dann noch zwei Schwachstellen welche direkt mit der Funktionalitität der Zertifikat-Apps im Zusammenhang stehen:
- Die Schweiz verwendet für die Signierung der Zertifikate einen anderen Algorithmus als sämtliche EU-Länder. Zwar sieht der europäische Standard beide Algorithmen vor, der von der Schweiz eingesetzte RSASSA-PPS-Algorithmus (PDF) sollte aber nur verwendet wenn ECDSA (der primäre Algorithmus) für die im jeweiligen Land geltenden Vorgaben eine zu grosse Hürde darstellt (für die Schweiz ist dies kaum der Fall). Auch wenn Verifikationsapplikationen grundsätzlich beide Algorithmen akzeptieren müssen, besteht hier das Risiko dass sich das eine oder andere Land auf die EU-Länder und ECDSA beschränkt. Schweizer Touristen könnten dann in solchen Ländern ihr Impfzertifikat nicht verifizieren lassen
- Das Zertifikat an sich enthält einiges mehr an Daten als die offizielle Verifikationsapp anzeigt, unter anderem sieht man die Impftermine, Details zur Impfung und auch persönliche Details. Diese zusätzlichen Daten sind für die EU-Kompatibilität notwendig, der geimpften Person ist die Informationsfülle aber nicht direkt bewusst. Mit geeigneten Apps sind diese Daten problemlos auslesbar (wer es sich einfach machen will, fotografiert fremde Zertifikate und wertet sie später aus). Für die eigentliche Funktion des Zertifikats (Nachweis des Immunitäts- oder Teststatus) reicht ein minimales Datenset (Name zum Vergleich mit offiziellem Ausweis, Immunitätgrund oder Test, Gültigkeitsdauer), das entsprechende Covid-Zertifikat light ist allerdings nur innerhalb der Schweiz gültig.
Was heisst das jetzt?
Die erste gute Nachricht vorneweg: Keiner der Befunde scheint so kritisch zu sein, dass die Sicherheit der Impfzertifikate gefährdet ist. Auswirkungen auf die Nutzer bestehen vor allem aufgrund der beiden Punkte mit Bezug zur Funktionalität (Algorithmus zur Signierung sowie Übermass an Informationen im QR-Code), beide wurden als “ongoing” klassifiziert was hoffen lässt dass hier in absehbarer Zeit eine verbesserte Lösung vorliegen wird.
Die zweite gute Nachricht ist, dass sich Offenheit und Transparenz lohnt. Die kritische Prüfung durch die interessierte Öffentlichkeit hat einige Schwachstellen aufgezeigt welche behoben werden müssen. Gleichzeitig steigt das Vertrauen in die Gesamtlösung da sich jeder technisch interessierte ein Bild sowohl der Software an sich wie auch deren Qualität machen kann. Wir würden uns wünschen, dass das für staatliche Software insgesamt der Standard wäre.
Offen bleiben momentan die Details der 112 vom NTC identifizierten Schwachstellen. Aufgrund der Titel hat es da einige spannende Befunde darunter, wir sind zum Beispiel gespannt darauf, was sich hinter “Swiss digital COVID certificate impersonation and theft possible” oder “SQL injection in immunity request backend” verbirgt und wieso der Bund beide Befunde als “wontfix” klassifiziert hat. Fortsetzung folgt!
