Nun sind in den 100 Millionen Euro auch die Kosten für die neue Hardware mit drin, aber ein paar Euro für erfahrene Webentwickler hätten da durchaus noch übrig bleiben können. Doch diese wollte man sich entweder sparen oder Icomera, die das System nicht nur für die Deutsche Bahn umgesetzt haben, konnten entsprechend qualifiziertes Personal nicht finden.
Bereits im Oktober letzten Jahres wurde von nexus vom CCC Hannover ein ausführlicher Proof of Concept veröffentlicht, der zeigte, wie einfach man dank einer Reihe von unglücklichen Designentscheidungen über eine Website einen Besucher, der das ICE-WLAN nutzt, aus diesem ausloggen kann. Oder aber alternativ auslesen, wo der Zug gerade steckt, die MAC-Adresse des Nutzers, welche Datenmengen der Nutzer aktuell schon über das WIFIonICE genutzt hat und weitere Informationen zum WLAN sowie dessen aktuelle Anbindung an Mobilfunknetze. Wie das aussehen kann, zeigt eine eigens eingerichtete Website (wenn man gerade in einem ICE-WLAN surft) oder dieser Screenshot:
Jetzt kann man natürlich der Meinung sein, dass das alles ja nun keine so kritischen Daten wären und natürlich ist diese Meinung durchaus legitim. Es gibt jedoch ein paar Punkte, die dann schon nachdenklich stimmen:
- Es sind Daten, die man auch mit weiteren Daten verknüpfen kann, es dürfte sicher noch andere WLAN-Zugänge geben, die ähnlich gesprächig sind.
- Es dürfte nicht nur weitere ähnlich gesprächige Systeme geben, es gibt sie zum Beispiel bei der Bahn in Schweden, auch in diesem Fall von Icomera, dort funktionierte der beschriebene Angriff ohne Änderung.
- Das Unternehmen bietet entsprechende WIFI-Lösungen weltweit für unterschiedliche Verkehrsmittel an, so wie es aussieht, basieren alle auf einer einheitlichen Basis.
- Die Deutsche Bahn will den Internetzugang per WLAN in Zukunft auch in weiteren Zügen, nicht nur im ICE anbieten – wohl auf der gleichen Basis.
Security? War vielleicht optional?
Um hier einmal nexus zu zitieren:
Es ist davon auszugehen, dass eine nicht unerhebliche Menge an Geld in die Erstellung der Captive-Portal-Software geflossen ist. Anders als ein Kiosk, der nebenher noch einen Hotspot betreibt, betreibt die Deutsche Bahn eine große Anzahl dieser Zugangspunkte. Daher ist es auch erschreckend zu sehen, wie schlecht diese Software am Ende umgesetzt wurde.
Offensichtlich wurde auf der Software auch kein Security-Audit durchgeführt sondern auf die Fachkenntnis des Herstellers vertraut. Bei letzterem fehlt es entweder an Grundlagenwissen in Bezug auf Webtechnologien oder es existiert keine Sensibilisierung für die Privatsphäre der Nutzer.
Das war im Oktober, die Bahn teilte gar nicht so viel später mit, dass die Lücke geschlossen wäre. Aber als geschlossen sehen wohl nur die Bahn und Icomera die Lücke, denn was da gemacht wurde, ist eigentlich nicht zu glauben. Man sollte meinen, dass man das System in den Zügen härtet, die Informationen über die Nutzer nicht mehr so ohne weiteres an jedes anfragende System raus lässt, sondern zumindest durch Tokens eine Art von Authentifizierung berechtigter Systeme einführt oder ähnliches.
Durch einen Zufall entdeckte nexus, dass die Lücke keinesfalls geschlossen wurde, sondern das System mehr als notdürftig gefixt wurde. Würde die Bahn ihre ICEs so reparieren, wie das Datenleck in dem System, dann würden die Züge wohl bestenfalls noch durch Gaffa-Tape zusammen gehalten.
Es wird nun das Referrer-Feld bei Anfragen ausgelesen. In diesem Feld können Browser bei einer Anfrage die Adresse der Seite mitschicken, von der sie kommen. Oder auch gar nichts mitschicken. Oder irgendwas in das Feld schreiben. Man kann dem Browser auch in einer Website mitteilen, dass er bei von dieser ausgehenden Anfragen einfach keinen Referrer mitschicken soll. Kein Referrer wird von den betroffenen Systemen aber als korrekter Referrer interpretiert. Ergebnis: Eine Zeile im HTML-Header des alten Proof of Concept ändern und schon werden wieder fleißig Daten ausgelesen.
Wie schützen?
Wenn man nun nicht möchte, dass entsprechende Informationen raus gehen, dann man sich mit einer lokalen Firewall behelfen, die alle TCP-Verbindungen zur Adresse 172.16.0.1 verbietet – aber erst nachdem man sich am WLAN eingeloggt hat. Das ist durchaus möglich, aber alles andere als komfortabel. Eine andere Möglichkeit wäre es, im Zug einfach den Browser nicht mehr zu benutzen – wobei es bei aktuellen Betriebssystemen und Apps oft nicht so ganz möglich ist, sicher zu sagen, ob da nun irgendwo im Hintergrund vielleicht ein Browser werkelt.
Ein VPN hilft in diesem Fall leider gar nicht weiter, auch wenn es natürlich ansonsten immer eine gute Idee ist, wenn man sich über öffentliche Zugangspunkte ins Internet begibt.
Fazit
Und zum Schluß? Was nexus sagt:
Beitragsfoto: Karinkarin via Pixabay, Lizenz: CC0
