Datum: 17.07.2017

Chapter 2: Die Bahn, ihr Wifi und die Amateure

Es ist gar nicht so lange her, dass die Bahn ihr neues Hochglanz- und Prestigeprodukt in Betrieb genommen hat: Das „WIFIonICE“. Kurz nach Start des Testbetriebs hatte ich damals einen doch recht detaillierten Abriss über die grottige Umsetzung geschrieben. [1]

Die Bahn hatte danach in einer Hauruck-Aktion angebliche Fehler ausgemerzt. [2] Seitdem bin ich oft gefragt worden, ob ich nochmal den Text dahingehend updaten möchte, dass die Bahn die Lücken geschlossen hat. Der Grund, warum ich das nicht getan habe, ist, dass solche strukturellen Sicherheitsprobleme nicht mit einem kurzen Patch aus der Welt geschafft werden können.

Wie sehr ich damit Recht habe, wurde mir heute gewahr, seit die Bahn nun beginnt, die Drohung einer Drosselung des WLAN in der 2. Klasse wahrzumachen. Leider funktionierte das wohl nicht so gut, so dass ich auch in der 1. Klasse von der Drosselung betroffen war. Nachdem die Bahn per Twitter einige absurde Lösungsstrategien vorschlug, wie etwa das Löschen von Cookies in einem Portal, welches gar keine Cookies anbietet, machte ich mich selbst auf die Suche. Nach einem kurzen Blick auf den Netzverkehr sprangen mir bösartige Queries aus der letzten Analyse ins Gesicht.

Es gibt bestimmte „Best-Practices“, die sich in den letzten Jahren in der Webentwicklung durchgesetzt haben. Dazu gehört, dass man grundsätzlich Sicherheitsfeatures nutzen sollte, die der Browser anbietet, und keine eigenen Konzepte erfinden sollte, ohne sie zu verstehen. Bis zur Deutschen Bahn scheint dies aber noch nicht durchgedrungen zu sein. Statt meine frühere Analyse richtig zu lesen und zu analysieren, wie man entsprechende Lücken schließt, setzt die Bahn auf eine sehr eigenwillige Erfindung: Statt dem Browser das Blockieren zu überlassen, bastelt sich die Bahn eine Lösung auf Basis des „Referrer“-Feldes im Browser.

Was tut dieses Feld? Ein Browser kann über dieses optionale Feld einer Webseite mitteilen, woher er kommt. In dieses Feld wird einfach die Adresse der Ursprungsseite eingetragen, wenn der Nutzer einen Link klickt. Da dieses Feld ein Risiko für die Privatsphäre darstellen kann (Stichwort: „Tracking“), gibt es zum einen Browser-Extensions, die es erlauben, dieses Feld zu deaktivieren, und zum anderen dürfen Webseiten dieses explizit ausschalten.

Dieses Wissen ist für einen Angreifer im Falle der Bahn sehr hilfreich. So muss man nur meinen bisherigen PoC (Proof of Concept) um eine Zeile im HTML-Header ergänzen und er funktioniert wieder wie gewohnt:

<meta name="referrer" content="no-referrer" />
Die neue Version des PoC findet sich unter [3].

Conclusio

Statt wie schon damals gefordert Geld in eine geeignete Security-Analyse zu stecken, sieht es die Bahn offensichtlich bis heute nicht für erforderlich an, die Daten ihrer Kunden auch nur annähernd zu schützen. Man mache sich bewusst, dass die Bahn hier WLAN für über 100 Millionen Euro [4] eingekauft hat. Dass es bei diesem Projektbudget nicht mal für einen erfahrenen Webentwickler reicht, dem entsprechende Sicherheitskonzepte bekannt sein müssen, ist einfach peinlich.

Kontakt

Autor:nexus
Mail:nexus (at) hannover (.) ccc (.) de
Twitter:@Nexus511

Links

Chapter 1 Chapter 3 Index