Seit ein paar Wochen stellt die Bahn nach und nach das WLAN im ICE auf das neue WLAN auf Basis einer „Multi-Provider-Technologie“ um. Das neue WLAN soll zum einen deutlich stabiler, zum anderen auch in der 2. Klasse kostenlos verfügbar sein.
Da ich regelmäßig mit der Bahn unterwegs bin und dort das WLAN auch regelmäßig nutze, wollte ich mir an sich nur ein Script bauen, welches mir einen Login für das WLAN ermöglicht, ohne meinen Browser öffnen zu müssen. Die gute Nachricht: Das ist einfacher als gedacht. Die schlechte Nachricht: Das liegt daran, dass dort Menschen „gefrickelt“ haben, denen offensichtlich grundlegende Angriffe wie Cross-Site-Request-Forgery vollkommen unbekannt sind oder denen die Privatsphäre der Nutzer im Zug-WLAN vollkommen egal ist.
Dass Webseiten Formulare und Eingabedaten versenden können ist kein Geheimnis, sondern ein notwendiges Grundkonzept für jegliche Form dynamischer Webseiten. Seit der Einführung von Web 2.0 Technologien wie AJAX u.ä. können Webseiten zudem auch im Hintergrund Requests ausführen. Zum Datenversand werden Eingabedaten in einem HTTP-Aufruf an eine definierte Adresse übertragen und dort ausgewertet.
CSRF-Angriffe nutzen nun aus, dass Requests über Seitengrenzen hinweg verschickt werden können. Statt das Formular der Originalseite kann ein Angreifer ein eigenes Formular an einer anderen Stelle bereitstellen und sogar unbemerkt im Hintergrund verschicken. Ist der Benutzer beispielsweise auf der Seite an die das Request geschickt wird eingeloggt, so werden die Aktionen unter dessen Account durchgeführt.
Da dies seit vielen Jahren bekannt ist, gibt es verschiedene Sicherheitsmechanismen, die solche Angriffe verhindern. Für Formulare werden beispielsweise Token mitgesendet, die als unsichtbares Feld beim Absenden des Formulars übertragen werden. Ohne Kenntnis dieses Token kann ein Angreifer auch keine Aktionen per CSRF triggern.
Für AJAX haben die Browser-Entwickler indes schon bei der Definition festgelegt, dass Cross-Site-Zugriffe nicht zulässig sind. Dies bedeutet: Eine Seite auf Domain A kann nicht einfach Inhalte von Domain B requesten.
Außerdem sichern viele Frameworks für die Webentwicklung Formulare bereits über entsprechende Token ab, damit CSRF-Angriffe nicht mehr möglich sind.
Um das Bahn-WLAN zu nutzen muss man ein sogenanntes Captive-Portal aufrufen, in dem man dann über einen Button die Geschäftsbedingungen bestätigt und damit „online“ geht. Für den Aufruf des Captive-Portals wird der Browser auf die Adresse http://www.wifionice.de/ umgeleitet, auf welcher der entsprechende Button angezeigt wird. Klickt man den Button wird ein Request an https://www.ombord.info/ geschickt, welches den Nutzer in den „Online“-Status schickt. Dafür wird die IP- bzw. MAC-Adresse des Nutzers für Datenverbindungen freigeschaltet.
Die Netztopologie sieht dabei wie folgt aus:
Damit ist www.ombord.info sowohl der Router, als auch die Authentifizierungsstelle für den Zugriff und www.wifionice.de stellt ausschließlich eine Portalseite zur Verfügung.
Durch diesen Umstand wird klar, dass das gesamte System nur mit Cross-Site-Requests funktioniert. Genauer gesagt erfolgt die Einwahl durch ein Request auf die URL
https://www.ombord.info/hotspot/hotspot.cgi?method=login&url=http://www.wifionice.de/&onerror=http://www.wifionice.de/
Die hotspot.cgi erzeugt ihrerseits einen Redirect auf genau die URL, welche im URL-Feld angegeben wurde, nachdem die Aktivierung erfolgt ist. Dort lassen sich also beliebige URLs in den Header eintragen (vielleicht auch nicht grade geschickt). Wird keine URL angegeben, so wird http://www.wifionice.de/ als Default genutzt.
Dabei fällt auf, dass hier keine Token zur Absicherung gegen CSRF getauscht werden. So lässt sich beispielsweise folgender Code in beliebige Webseiten einbetten um Nutzer des WLAN im ICE einfach mal offline zu schalten:
<iframe src="https://www.ombord.info/hotspot/hotspot.cgi?method=logout&url=&onerror="></iframe>
Bei den betroffenen Usern kommt sicherlich wenig Freude auf, wenn deren Internet-Verbindung bei einem Seitenzugriff unbemerkt im Hintergrund getrennt wird. Ansonsten ist dieser Umstand relativ wenig kritisch, da hier noch keine persönlichen Daten von Nutzern betroffen sind.
Nachdem ja wie gesagt Cross-Site-Requests via AJAX aus Gründen der Sicherheit nicht funktionieren, gibt es natürlich findige Köpfe, die das nicht akzeptieren wollen. So entstand wohl JSONP. JSONP setzt man üblicherweise dann ein, wenn man Infrastruktur verbockt hat und sich irgendwie doch noch funktionierende Software zurechtbasteln möchte. Dabei werden keine AJAX-Requests mehr durchgeführt sondern stattdessen einfach JavaScript-Inhalte von externen Seiten mit eingebettet und ausgeführt. Diese Scripte rufen dann eine Callback-Funktion mit den gewünschten Daten auf. Dieses Konzept beinhaltet so viele potentielle Probleme, dass es einem einfach auf die Füße fallen muss.
Aufgrund der Anfälligkeit für CSRF gibt es für JSONP im Übrigen die Regel, dass es grundsätzlich mit entsprechenden Token abgesichert werden sollte.
Nun stellt das Bahn-WLAN gewisse Statusinformationen zur Verfügung, die über die Portalseite abgerufen werden. Dies sieht man dann, wenn man sich den Transfer des Portals im Inspector des Browsers anschaut. Darunter sind u.a. GPS-Koordinaten des Zugs, aktuelle Zellinformationen der LTE-Infrastruktur sowie nutzerspezifische Informationen wie IP- und MAC-Adresse der genutzten Hardware.
Diese Informationen stammen nicht etwa vom Portalserver www.wifionice.de, von dessen JavaScript sie abgerufen werden, sondern vom Gateway unter der Adresse www.ombord.info. Da wie gesagt AJAX grundsätzlich Cross-Site-Requests verbietet, hat man sich wohl gedacht: Nehmen wir halt JSONP.
Der Service bietet unter Anderem folgende Endpoints, welche sich unter der Adresse https://www.ombord.info/api/jsonp/ auch praktisch auflisten lassen:
Die Services lassen sich per cURL abfragen. Da vorallem User- und Positionsdaten interessant sind finden sich im folgenden Beispieldaten für beide Dienste:
$ curl "https://www.ombord.info/api/jsonp/user/"
({
"version":"1.7",
"ip":"172.16.XXX.XXX",
"mac":"E4:XX:XX:XX:XX:XX",
"online":"0",
"timeleft":"0",
"authenticated":"1",
"userclass":"1",
"expires":"Never",
"timeused":"4061",
"data_download_used":"10910227",
"data_upload_used":"1378087",
"data_total_used":"12288314",
"data_download_limit":"3240499",
"data_upload_limit":"216591",
"data_total_limit":"3457090",
"bandwidth_download_limit":"375000",
"bandwidth_upload_limit":"375000"
});
$ curl "https://www.ombord.info/api/jsonp/position/"
({
"version":"1.7",
"time":"1476205886",
"age":"0",
"latitude":"52.444865",
"longitude":"10.29791",
"altitude":"56.3",
"speed":"53.662",
"cmg":"252.94",
"satellites":"10",
"mode":"3"
});
Durch die Umsetzung als JSONP-Anbindung, lassen sich diese Services in beliebige Webseiten einbinden. Diese können dann nicht nur herausfinden, dass ein Nutzer aktuell in einem Zug der Deutschen Bahn sitzt, sondern auch alle Informationen der Gateway-Services abfragen. Dies beinhaltet auch die MAC-Adresse, welche im Normalfall die eindeutige Hardware-Kennung des WLAN-Adapters ist.
Versieht man eine Webseite mit einem geeigneten Script, erlaubt dies die eindeutige Erfassung und Zuordnung von Bewegungsdaten bei Seitenzugriffen. So lassen sich diese Informationen z.B. durch Werbetreibende über eingebettete Werbebanner in Seiten erfassen, die dann entsprechend Bewegungsprofile von Internetnutzern sammeln können.
Unter [1] kann eine Seite eingesehen werden, welche als Proof-of-Concept die Positionsdaten aus dem neuen ICE-WLAN abfragt. Wird diese Seite im neuen WLAN der Deutschen Bahn geöffnet, lassen sich dort die Informationen der User-, Position- und Connectivity-Services ansehen.
Wird kein Bahn-Portal gefunden, so kann unter dem Link ein Beispiel für eine Ausgabe als Screenshot angezeigt werden.
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.
Bis die Bahn dieses Datenleck geschlossen hat, kann eine Firewallregel Abhilfe schaffen, die TCP-Verbindungen zur Adresse 172.16.0.1 verbietet, nachdem der Login ins WLAN erfolgt ist. Bei aktueller Umsetzung lässt man den Browser im Zug aber vielleicht am besten einfach geschlossen.
Nachdem offensichtlich auch viele Menschen ausserhalb Deutschlands diesen Text lasen, bekam ich heute Abend eine Mail aus Schweden. Jemandem dort kam die Domain www.ombord.de sehr bekannt vor. Daraufhin hat die betreffende Person meine Scriptseite im Zug ausprobiert und freudig berichtet, dass auch das WLAN in schwedischen Bahnen für den Angriff empfänglich ist. Bedeutet: Mein Script funktioniert ohne jegliche Modifikation auch dort. Einen Screenshot findet sich unter [2].
Ein wenig Zynismus im Enterprise-Speech: Die Firma Icomera, welche das System für die Deutsche Bahn liefert [3], bezeichnet sich selbst als „the world’s leading provider of open Internet connectivity and application platforms for passenger transport and public safety“.
Bisher ist mir noch keine Liste der betroffenen Unternehmen (sprich „Referenzen“) untergekommen. Eine Suche im Internet spuckt jedoch einige Bahnunternehmen aus, die alle von diesem Anbieter beliefert werden. Ich freue mich über Eure Erfahrungsberichte aus weiteren Staaten zur Pflege einer möglichst langen Liste der betroffenen (Bahn)unternehmen.
| Autor: | nexus |
| Mail: | nexus (at) hannover (.) ccc (.) de |
| Twitter: | @Nexus511 |
