Mein Kommentar zur Stellungnahme des Kantons St. Gallen zum E-Voting-Hack, gesendet am 8.11. per E-Mail:
----- Original message -----
Subject: Kommentar zu E-Voting Stellungnahme St. Gallen
Date: Thu, 8 Nov 2018 16:34:22 +0100
Hallo Benedikt
Über die Medien habe ich von eurer Stellungnahme zum "E-Voting-Hack" erfahren. Dieser möchte ich klar widersprechen. Ich halte mehrere Aussagen darin für falsch und gefährlich. Ich hoffe, du nimmst dir die Zeit, diese etwas langen technischen Ausführungen durchzulesen. E-Voting ist ein technisches System. Deshalb ist es wichtig, sich eingehend mit den technischen Sicherheitsgrundlagen zu befassen.
Zusammenfassung (TLDR):
- Die Stimmgeheimnis-Verletzung ist definitiv möglich, Stimmen-Manipulation ist potentiell möglich
- Es spielt keine Rolle, ob kommunale Wahlen involviert sind oder nicht
- Die Lücke ist bisher nicht behoben (dafür müsste HSTS Preloading aktiviert werden und am besten auch DNSSEC aktiviert werden)!
- Es ist nicht in Ordnung, die Verantwortung auf den Bürger abzuschieben und grundlegende Sicherheitsvorkehrungen zu ignorieren
> Das aufgezeigte Vorgehen ist nicht neu
Korrekt. Deshalb könnte man davon ausgehen, dass die beteiligten Parteien entsprechende Gegenmassnahmen ergreifen.
> und ermöglicht weder einen Bruch des Stimmgeheimnisses noch eine
> Manipulation von Stimmen.
Hier würde ich klar widersprechen. In der Theorie mag das stimmen, die Theorie geht jedoch davon aus, dass jeder Stimmbürger die Anweisungen penibel befolgt. Wenn ein Stimmbürger jedoch bereits nicht bemerkt, dass er auf eine andere Seite umgeleitet wurde, bemerkt er sicher auch nicht, wenn sonst etwas im Prozess nicht stimmt.
Ein E-Voting-System muss nicht bloss theoretisch sicher sein, es muss sich auch unter realistischen Praxisbedingungen bewähren, da es von Leuten angewandt wird, die nicht technikaffin sind.
> Der Chaos Computer Club hat gegenüber Schweizer Radio und Fernsehen aufgezeigt,
> wie ein Stimmberechtigter, der die Internetadresse des E-Voting-Systems nicht
> korrekt in die Adresszeile eingibt, auf eine falsche Internetseite umgeleitet
> werden kann.
Mit "nicht korrekt eingibt" ist hier gemeint, dass das Protokoll (https://)
nicht eingetippt wird, sondern nur der Teil dahinter. Aus Praxiserfahrung weiss
ich, dass praktisch wie niemand https:// vor der Domain eintippt, denn der
Browser "leitet einem ja automatisch auf die HTTPS-Version um". Es ist
illusorisch davon auszugehen, dass die vollständige URL samt Protokoll von
einer Mehrheit der Stimmbürger korrekt eingegeben wird.
> Es handelt sich bei diesem Vorgehen aus Sicht der Staatskanzlei nicht um
> einen Hack des Systems, sondern um eine Simulation, wie User in die Irre
> geführt werden könnten.
Wenn mit "das System" die Kryptografie und Protokolle gemeint sind, dann mag das stimmen. In der Praxis ist das aber irrelevant, da der Browser und der Benutzer ebenso zum Gesamtsystem gehören und deshalb in die Risikobewertung eingeschlossen werden müssen! Anscheinend wird dies nicht gemacht.
Und nun zum technischeren Teil:
> Diese Vorgehensweise wird bereits im Anhang der Verordnung der Bundeskanzlei
> vom 13. Dezember 2013 über die elektronische Stimmabgabe (Abschnitt 3.1) als
> ein Szenario beschrieben, für das Vorkehrungen zu treffen sind. Die
> Erkenntnisse sind also nicht neu.
Dann müsste man also davon ausgehen können, dass entsprechende Gegenmassnahmen ergriffen wurden, korrekt? Leider ist dem offenbar nicht so.
Etwas Hintergrundinformationen: Das HTTPS-Protokoll wurde viele Jahre nach dem HTTP-Protokoll eingeführt. Während HTTP unverschlüsselt ist, wird mit HTTPS der Datenverkehr verschlüsselt. Verschlüsselung verhindert auch die einfachsten Man-in-the-Middle-Attacken, wie sie vom CCC demonstriert wurde. Der User musste jedoch bisher immer explizit wählen, ob er eine http://- oder eine https://-Seite besucht.
Mit den Jahren wurde HTTPS immer verbreiteter. Seitenbetreiber begannen damit, Leute vom http://-Protokoll auf https:// weiterzuleiten. Dies geschieht mit einer serverseitigen Weiterleitung. Dafür gibt es zwei Methoden: Entweder mit dem Statuscode "302" (temporäre Weiterleitung) oder mit dem Statuscode "301" (permanente Weiterleitung). Wird eine permanente Weiterleitung erstellt, kann der Browser davon ausgehen, dass diese auch in Zukunft bestehen wird, und kann die Weiterleitung speichern (sogenanntes "Caching"). Wird der Benutzer einmal von "http://www.evote-ch.ch/" auf "https://www.evote-ch.ch/" weitergeleitet, wird der Browser in Zukunft bei Eingabe von "www.evote-ch.ch" immer sofort die HTTPS-Version der Seite laden. Hier liegt schon der erste Fehler der Seitenbetreiber: Es wurde eine temporäre Weiterleitung (Statuscode "302") verwendet, so dass die Weiterleitung nicht durch den Browser gespeichert und künftig immer angewandt wird. Das ist ein Anfängerfehler und dürfte nicht passieren.
Mit den Jahren hat man gemerkt, dass es diverse Angriffsmöglichkeiten gibt, die darauf abzielen, Benutzer umzuleiten, bevor sie auf die verschlüsselte HTTPS-Seite weitergeleitet werden.
Normalerweise müsste eine Weiterleitung auf die sichere Seite so aussehen:
- User gibt "www.evote-ch.ch" im Browser ein. Das wird vom Browser als "http://www.evote-ch.ch/" interpretiert, diese URL wird daher geladen.
- Der Webserver von "http://www.evote-ch.ch/" sendet dem Browser eine Anweisung (HTTP 301), auf "https://www.evote-ch.ch/" umzuleiten
- Der Browser ruft nun also https://www.evote-ch.ch/ auf und die Verbindung ist ab dann verschlüsselt
Bei einem Angriff läuft jedoch folgendes ab:
- User gibt "www.evote-ch.ch" im Browser ein. Das wird vom Browser als "http://www.evote-ch.ch/" interpretiert, diese URL wird daher geladen.
- Der Angreifer leitet den Benutzer von www.evote-ch.ch auf einen anderen Server um. Dies ist möglich, weil die Verbindung immer noch unverschlüsselt erfolgt. Praktisch geht das z.B. mit der demonstrierten DNS Cache Poisoning Attacke, oder aber auch durch Manipulation der Hosts-Datei auf dem Computer, oder mit vielen anderen Methoden. Dabei muss keine kritische Infrastruktur unterwandert werden!
- Der Webserver des Angreifers sendet dem Browser die Anweisung (HTTP 301), auf "https://www.fake-evote-ch.ch/" umzuleiten
- Die Verbindung ist nun verschlüsselt, aber mit dem falschen Server.
Das Grundproblem liegt darin, dass die Verbindung nicht von Anfang an verschlüsselt erfolgt. Die gängige Lösung dafür sind sogenannte "HSTS-Header" sowie "HSTS-Preloading". Bei einem HSTS-Header teilt der Webserver dem Browser mit, dass er in Zukunft immer nur verschlüsselt kommunizieren möchte, und dass der Browser nie unverschlüsselt mit diesem Server kommunizieren soll. Dies schützt den User noch nicht beim ersten Seitenaufruf, aber bei allen zukünftigen Seitenaufrufen. Bei HSTS-Preloading trägt man die Domain zusätzlich auf eine Liste ein, die die gängigen Browser dazu verwenden, um zu wissen, welche Websites gleich von Anfang an nur verschlüsselt geladen werden sollen.
Diese Methoden hätten den demonstrierten Angriff des CCC verhindert. Es sind grundlegende Sicherheitsmechanismen, welche aber im Livesystem des E-Voting-Systems nicht angewandt wurden. Das ist fahrlässig. Zu sagen, dass bereits seit Jahren ein Schutz gegen diese Attacken besteht und dass der Benutzer dafür verantwortlich ist, ist einerseits falsch und andererseits unverantwortlich.
WICHTIG: HSTS Preloading wird aktuell immer noch nicht implementiert! Die Lücke ist daher also noch gar nicht behoben.
Und bisher haben wir erst über HSTS gesprochen. DNSSEC ist eine weitere seit Jahren existierende Methode um DNS-Anfragen abzusichern, welche vom Kanton Genf nicht angewandt wird. Man darf als Betreiber nicht einfach die Verantwortung auf die Benutzer abschieben, wenn man selbst grundlegende Sicherheitstechniken nicht anwendet.
> Eine Umleitung der Internetverbindung auf eine falsche Seite reicht zudem
> nicht aus, um das Stimmgeheimnis zu brechen oder Stimmen zu manipulieren.
Das stimmt nicht. Das Stimmgeheimnis ist sofort gebrochen, da der Angreifer die Stimme der Zielperson mitlesen kann. Auch eine Manipulation der Stimme ist sofort möglich. Eine unbemerkte Manipulation ist dann möglich, wenn man den Benutzer dazu bringt, die Verifikationscodes nicht zu überprüfen, oder sogar einzugeben. Mit Social Engineering ist das kein Problem, das weiss man schon lange aus der Forschung zu IT-Sicherheit und User-Awareness.
Dass die Kern-Algorithmen dabei nicht gebrochen wurden, ist hier irrelevant, die Sicherheit von E-Voting muss sich immer auf das Gesamtsystem beziehen.
> Eine Irreführung wäre vor allem dann sehr einfach zu erkennen, wenn eine
> kommunale Abstimmung beziehungsweise Wahlen oder Kreisgerichtswahlen
> stattfinden würden. Denn die Angreifer können aufgrund der bekannten Angaben
> nicht erkennen, aus welcher Gemeinde oder aus welchem Wahlkreis die oder der
> Stimmberechtigte stammt. Daher könnten auch nicht die korrekten kommunalen
> Abstimmungsfragen oder Kandidaten angezeigt werden.
Das ist schlichtweg falsch. Der erste Schritt im E-Voting-Prozess ist die Eingabe der Stimmrechtsausweis-Nummer. Wird diese Nummer gegenüber dem Server des Angreifers eingegeben, kann dieser die Nummer einfach an die echte Seite weiterleiten und kriegt damit die richtigen Fragen geliefert, die er dann an die abstimmende Person weiterleitet. Das führt höchstens zu einer nur unwesentlichen Verzögerung und ist vom Benutzer nicht bemerkbar.
> Der Kanton St. Gallen habe richtigerweise erkannt, dass das Aufrufen der
> betreffenden Seite über Google eine wichtige Fehlerquellen sein könne.
Wenn dies so ist, könnte man erwarten, dass der Kanton alles unternimmt, um diese Fehlerquelle zu unterbinden, nicht? Anscheinend nicht, denn die Möglichkeit zum Ausschluss der Seite von Google (https://www.evote-ch.ch/robots.txt) wird nicht angewandt.
> «Der Vorfall ist eindeutig ein Sicherheitsproblem, aber Abstimmungsdaten wurden keine manipuliert.»
Natürlich wurden keine echten Daten manipuliert. Man weiss ja wie das endet: https://www.nzz.ch/schweiz/doppeltes-e-voting-rts-journalist-wegen-wahlbetrugs-verurteilt-ld.132463
Ich bin gerne weiterhin offen für einen faktenbasierten Diskurs. Ein solcher bedingt aber, dass Fehler offen zugegeben werden. Das Zugeben (und sofortige Beheben) von Fehlern schafft Vertrauen. Von der Kommunikation bisher (Statements, dass nie ein Problem bestanden hat und dass der Benutzer verantwortlich ist, obwohl die Betreiber einfachste Sicherheitsvorkehrungen treffen könnten) bin ich jedoch leider bisher sehr enttäuscht.
Grüsse aus Rapperswil,
Danilo