Ein Sturm im Wasserglas

Seit einigen Tagen herrscht Aufruhr in den schweizerischen sozialen Medien, weil im E-Voting-System vom Kanton Genf eine «Schwachstelle» aufgedeckt wurde. Ein Beitrag darüber wurde zuerst im Deutschschweizer Fernsehen SRF ausgestrahlt. Seither hagelt es Kritik, und das Thema wird politisch instrumentalisiert, indem es etwa heisst: «Beim E-Voting ist die Sicherheit nicht gewährleistet». Für mich sind die meisten dieser Beiträge populistische Reaktionen (die ehrlichen Bürger müssen vor dem bösen Internet geschützt werden) von Menschen, die nur oberflächliche Kenntnisse vom Thema haben. Was ist die «Schwachstelle» aus technischer Sicht? Ein Gastbeitrag von Kevin Chollet.

Die Schwachstelle aus Sicht des Anwenders

1. Verbindung über das E-Voting-Portal mit einer URL vom Typ www.evoting-ch.ch
2. Umleitung auf eine URL vom Typ https://hacked-evoting.ch
3. Die angezeigte Site sieht aus wie die echte, damit kein Verdacht aufkommt. Dies ist die Haupttaktik für diesen sogenannten Man-in-the-Middle-Angriff.

Die eigentliche Schwachstelle ist Punkt 2: die Umleitung von www.evoting-ch.ch auf https://hacked-evoting.ch. Dies ist ein Angriff vom Typ Cache Poisoning. Um verstehen zu können, was bei dieser Angriffsart passiert, muss man genau betrachten, was im Moment einer Anfrage passiert, also dann, wenn der Anwender eine Website aufruft.

Welchen Weg durchläuft eine Webanfrage?

Das geht in der Regel so:

Es handelt sich hier um eine maximal vereinfachte Darstellung einer Anfrage. Der Schritt DNS ist leider ein wenig komplizierter. Man muss die Abläufe etwas besser kennen, um zu verstehen, was bei diesem Angriff passiert.

Kurz erklärt: Die DNS-«Übersetzung» erfolgt nach einem Delegationsprinzip: Der «DNS-Server-Resolver» (in der Regel der DNS-Server des Anbieters) generiert eine Anfrage an die für «.ch» zuständigen Stelle, um zu erfahren, welcher Server sich um evoting-ch.ch kümmert. Daraufhin macht er eine Anfrage beim entsprechenden Server, um zu erfahren, wie www.evoting-ch.ch aufzulösen ist.

Der DNS-Poisoning-Angriff

Der DNS-Poisoning-Angriff (DNS Cache Poisoning) zielt in der Regel auf den DNS-Server-Resolver ab (beim roten Punkt im vorherigen Schema). Dieser Server verwendet nämlich einen Cache (um die pendenten Anfragen zwischenzuspeichern). Der Angriff besteht darin, den Cache zu manipulieren, damit die Anfragen anschliessend auf einen «böswilligen» Server umgeleitet werden.

Wie kann man sich dagegen schützen?

Nach der Veröffentlichung der Schwachstelle wurden die Verantwortlichen des E-Voting-Systems grösstenteils scharf kritisiert. Es existieren tatsächlich Mechanismen (DNSSEC) gegen solche Angriffe, die Diensterbringer einbauen können, aber damit ist es nicht getan, denn das ist die effizienteste Art, die Endnutzer aus der Verantwortung zu entlassen.

DNSSEC

Durch den DNSSEC-Mechanismus kann die rechtmässige Auflösung der DNS verifiziert werden. In einem früheren Artikel habe ich das Konzept und seine Umsetzung in bestimmten Kontexten erklärt.

Heute spielt die Verwendung von DNSSEC aber eine marginale Rolle: Gemäss Zahlen von nic.ch verwenden nur 2,8% der «.ch»-Sites DNSSEC.

HTTPS als Standard

Die aufgezeigte Schwachstelle führt dazu, dass die URL http://www.evoting-ch.ch nach https://hacked-evoting.ch umgeleitet wird. Wird hingegen die Site explizit via https://www.evoting-ch.ch aufgerufen, erfolgt keine Umleitung (es wird ein Zertifikatsfehler angezeigt).

HSTS und HSTS Preload

HSTS ist ein Mechanismus, der den Browser dazu zwingt, sich automatisch per HTTPS zu verbinden. Nach dem erstmaligen Verbinden legt er anhand eines Headers fest, dass die Verbindung zwingend per HTTPS zu erfolgen hat. Dadurch wird die Gefahr des DNS Cache Poisoning gebannt. Damit ist jedoch das Problem der Erstverbindung nicht gelöst. Aus diesem Grund wurde das HSTS durch einen HSTS Preload ergänzt – eine Liste, die von den Browsern automatisch konsultiert wird und diese dazu zwingt, alle Verbindungen mit einer bestimmten Domain per HTTPS durchzuführen.

Eigenverantwortung der Anwender stärken

Dieser Angriff funktioniert ähnlich wie das Phishing. Heutzutage ist die Wachsamkeit der Anwender unerlässlich: Eine optische Überprüfung der URL ist zwar mühsam, aber unumgänglich, um sich vor derartigen Problemen zu schützen.

Der zweiten Darstellung ist zudem zu entnehmen, dass dieser Angriff bei Elementen aus dem Anwenderumfeld ansetzt: Der Endnutzer ist verantwortlich dafür, dass sein Endgerät nicht gefährdet ist. Im vorliegenden Fall kann die Verantwortung für den Fehler den Diensterbringern angelastet werden, aber im Fall eines verseuchten Endgerätes, oder wenn der Anwender einen manipulierten Browser verwendet, gibt es nur eine einzige Antwort: Die wahre Schwachstelle muss auf der Seite des Endgeräts behoben werden. Der Anwender wählt, mehrheitlich ohne es zu wissen, DNS-Server aus, denen er vertraut, um im Internet zu surfen (die Wahl kann er explizit treffen oder sein Anbieter wählt für ihn). Wenn der entsprechende DNS-Server nicht zuverlässig ist, dann muss diese Wahl in Frage gestellt werden und nicht der externe Dienst, über den der Zugriff erfolgt.

Dieser Artikel wurde zuerst auf dem Blog blog.cholletk.me publiziert.