- Züge des Typs Impuls 45WE des polnischen Herstellers Newag konnten nach unabhängiger Wartung trotz unauffälliger Diagnose nicht losfahren; der Wartungsbetrieb SPS beauftragte Dragon Sector mit Reverse Engineering der Bordcomputer
- Die Forschenden analysierten den CAN-Bus, erstellten Speicherdumps der TriCore-basierten Systeme, verbesserten Ghidra und fanden schließlich Sperr-Flags sowie Startbedingungen in der Software, wodurch die Züge wieder bewegt werden konnten
- In Teilen des Zugcodes fanden sich Bedingungen, die den Start verhindern, wenn ein Zug mehr als 10 Tage an GPS-Koordinaten bestimmter Werkstätten steht, außerdem Sperren nach Teiletausch, eine Ausfallbedingung nach 1 Mio. km sowie eine datumsbasierte Meldung eines Kompressordefekts
- Insgesamt wurden 29 Züge untersucht; bei allen bis auf 5 wurden „surprises“ außerhalb der offiziellen Betriebsanweisungen gefunden, und die Probleme weiteten sich auf mehrere Regionen aus, darunter Wrocław, Opole, Kraków, Szczecin und Warschau
- Der Fall führte zu Klagen und Ermittlungen der Strafverfolgungsbehörden, konkrete Maßnahmen der Verbraucher- und Wettbewerbsbehörde oder der Eisenbahnverkehrsbehörde sind jedoch nicht bekannt
Newag-Impuls-Züge bleiben nach der Wartung stehen
- Der Fall begann im Frühjahr 2022, als der erste von 11 vom Newag hergestellten Impuls 45WE-Zügen der Lower Silesian Railways nach der vorgeschriebenen Wartung bei 1 Mio. km nicht mehr losfahren konnte
- Die Wartung übernahm der unabhängige Dienstleister Serwis Pojazdów Szynowych (SPS)
- Newag nahm ebenfalls an der Ausschreibung teil, das Angebot des Herstellers war jedoch rund 750.000 Dollar teurer
- SPS erhielt den Zuschlag für die Wartung der 11 Züge zu einem Preis von rund 5,5 Mio. Dollar
- SPS zerlegte, prüfte und montierte die Züge gemäß dem vom Hersteller bereitgestellten Wartungshandbuch mit rund 20.000 Seiten; dennoch bewegte sich der Zug nicht, obwohl der Bordcomputer einen normalen Zustand anzeigte
- Der Wechselrichter versorgte die Motoren nicht mit Spannung, und die Wartungstechniker konnten die Ursache allein mit Handbuch sowie elektrischen und mechanischen Prüfungen nicht finden
Wiederholte Stillstände und wachsendes Vertragsrisiko
- Auch der zweite Zug blieb nach derselben Wartung auf die gleiche Weise stehen, und der Hersteller Newag verweigerte Hilfe
- Der dritte Zug verpasste die Prüfung wegen eines Batterieproblems, sodass stattdessen der vierte Zug in die Werkstatt kam
- Als der vierte, normal fahrende Zug mit dem stillstehenden Zug verbunden wurde, blieb auch der funktionierende Zug stehen
- Die Ursache dafür ist bis heute nicht geklärt
- Auch in einer anderen Werkstatt in Szczecin gab es Fälle, in denen ein Impuls-Zug nach der Wartung nicht startete
- Weil sechs lange Garnituren der Lower Silesian Railway ausfielen, kam es zu Fahrplankürzungen, Ersatzzügen und Überfüllung in kürzeren Garnituren
- Newag erklärte, die Züge seien durch ein „Sicherheitssystem“ blockiert worden, doch im 20.000 Seiten umfassenden Handbuch wurde ein solches System nicht erwähnt
- Für jeden in der Werkstatt stillstehenden Zug fielen vertragliche Strafzahlungen von mehr als 1.000 Dollar pro Tag an, was den Druck auf SPS erhöhte
Reverse Engineering durch Dragon Sector
- SPS suchte nach „Polish hackers“ und fand das aus CTFs bekannte Team Dragon Sector; beide Seiten schlossen einen Vertrag
- Am Projekt beteiligt waren Michał „Redford“ Kowalczyk, Sergiusz „q3k“ Bazański und Kuba „PanKleszcz“ Stępniewicz
- Redford und q3k sind für Toshiba-Laptop-Hacks bekannt
- Kuba hatte Erfahrung mit Industrieautomatisierung
- Vor Ort erhielten die Forschenden einen nicht fahrenden Zug, zwei Ersatzcomputer und SDK-Dateien des Computerherstellers
- Die erste Analyse begann mit dem Abgriff des CAN-Bus, doch ohne Protokolldokumentation war die Interpretation des Traffics schwierig
- Das SDK unterstützte nur das Hochladen neuer Software, aber keine Dump-Funktion für vorhandene Software
- Als sie eine gefundene ältere Softwareversion auf den ersten Ersatzcomputer aufspielten, reagierte dieser nicht mehr
- Die Forschenden arbeiteten daraufhin mit dem einen verbliebenen Ersatzcomputer weiter
- Schließlich fanden sie eine Debugging-Schnittstelle und luden den Gerätespeicher Byte für Byte herunter
- Der Bordcomputer basierte auf der auch im Automobilbereich eingesetzten TriCore-Architektur; da es an guten Disassemblern mangelte, verbesserten sie Ghidra teilweise, um den Code zu analysieren
Startbedingung kurz vor Fristablauf gefunden
- Nach rund eineinhalb Monaten konnte Lower Silesian Railway nicht länger warten und entschied sich, Newag mit der Reparatur der defekten Züge und der weiteren Wartungszusammenarbeit zu beauftragen
- Die Kündigung des Vertrags mit SPS wurde für eine Woche später erwartet, und die Forschenden mussten innerhalb der verbleibenden Zeit Ergebnisse vorweisen
- Die Forschenden verglichen Speicherabbilder der Computer funktionierender und defekter Züge
- Da jeder Zug andere Funktionsumfänge und Softwareversionen hatte, war ein einfacher Vergleich schwierig
- Sie fanden Unterschiede, bei denen Werte in manchen Zügen gesetzt waren, während sie in anderen 0 betrugen
- Auch wenn der Computer aus dem Zug ausgebaut war, ließ er sich kurzzeitig starten, um die Betriebsbereitschaft des Wechselrichters zu prüfen; so waren Tests auf dem Schreibtisch möglich
- Weniger als einen Tag vor Ablauf der Frist fanden sie eine Flag-Konfiguration, mit der sich der Zug möglicherweise bewegen ließ, doch während eines Experiments brannte ein Kondensator des letzten funktionsfähigen Bordcomputers durch
- Nach Versuchen, zwei beschädigte Computer zu kombinieren, reparierten sie den durchgebrannten Computer und konfigurierten ihn um 2 Uhr morgens für den Zugstart
- Ein Forscher fuhr mit dem Computer zur Werkstatt, doch der Zug verspätete sich, und auch mit dem vor Ort angeschlossenen Computer startete der Zug zunächst nicht
- Nach weiterer Diskussion fanden sie ein fehlendes Flag, und um 8:42 Uhr gelang der Zugstart
- Um 9:30 Uhr sah die Delegation der Lower Silesian Railway, dass der Zug wiederbelebt werden konnte, und kündigte den Vertrag mit SPS nicht
Im Code versteckte Sperrbedingungen
- Durch monatelange Analyse und Reverse Engineering wurden in der von Newag gelieferten Software mehrerer Züge Bedingungen entdeckt, die eine plötzliche Fahruntüchtigkeit auslösen konnten
- Zahlen wie
53.13845und17.99011im Code waren GPS-Koordinaten und zeigten auf das PESA-Gelände nahe dem Bahnhof Bydgoszcz Główny - Später wurden auch Koordinaten anderer Wartungs- und Reparaturwerkstätten in Polen gefunden
- Im Code befand sich eine Bedingung, die die Startfähigkeit deaktivierte, wenn ein Zug mindestens 10 Tage in einem bestimmten Werkstattbereich stand
- Eine der Koordinaten gehörte zu Newags eigener Werkstatt
- Für die Koordinaten der Newag-Werkstatt war eine andere logische Bedingung definiert, vermutlich zu Testzwecken
- In anderen Zügen wurden weitere Sperrbedingungen gefunden
- Wenn ein bestimmtes Bauteil ausgetauscht wurde, wurde der Zug über eine Prüfung der Seriennummer des Bauteils blockiert
- Es gab eine Option, die Sperre durch eine bestimmte Tastenfolge im Führerstand und auf dem Bildschirm des Bordcomputers aufzuheben
- Nachdem die erfolgreiche Inbetriebnahme des Impuls in die Medien gelangt war, erhielten die Züge ein Softwareupdate, das diese „fix“-Option entfernte
- In einem anderen Zug wurde Code entdeckt, der nach 1 Mio. km einen „Defekt“ auslösen sollte
Kompressordefekt-Meldung durch Datumsbedingung
- Ein anderer Zug verweigerte am 21. November 2022 den Betrieb, obwohl er nicht in Wartung war
- Der Computer meldete einen Kompressordefekt, doch die Wartungstechniker sahen kein Problem am Kompressor
- Die Codeanalyse ergab folgende Bedingung
- Tag ist 21 oder höher
- Monat ist 11 oder höher
- Jahr ist 2021 oder höher
- dann wird ein Kompressordefekt gemeldet
- Der Zug war ursprünglich für eine Wartung im November 2021 vorgesehen, kam tatsächlich aber früher in die Werkstatt und kehrte erst im Januar 2022 zurück
- Im November 2021 wurde die Bedingung zufällig nicht ausgelöst; erst am 21. November 2022 wurde die geplante Ausfallbedingung erfüllt
In der Hardware gefundenes Gerät mit GSM-Verbindung
- Nicht nur in der Software, sondern auch in der Hardware wurde ein ungewöhnliches Gerät gefunden
- In einer Zuggarnitur entdeckten die Forschenden ein Gerät mit der Aufschrift „UDP<->CAN converter“
- Es schien eine Fernkommunikation mit dem Zug zu ermöglichen
- Durch Entfernen des Geräts fiel keine Funktion aus
- Der Bordcomputer sendete Informationen zum Sperrzustand an dieses Gerät, das wiederum mit einem GSM-Modem verbunden war
Ausweitung auf mehrere Regionen und Umfang der Analyse
- Die Nachricht, dass SPS Newags „defekte“ Züge repariert hatte, verbreitete sich bei anderen Unternehmen, und ähnliche Probleme stellten sich als verbreitet heraus
- In Wrocław wurden 13 Impuls-Züge analysiert
- Auch in anderen Regionen wurden betroffene Züge identifiziert
- 1 bei Kolej Mazowieckie
- 2 in Opole
- 4 in Kraków
- 1 in Zielona Góra
- 4 in Szczecin
- 1 in Warschau
- Das von den Forschenden entwickelte Tool entfernte die Software-Sperre des Bordcomputers, und die einzelnen Züge konnten repariert werden
- Insgesamt wurde die Software von 29 Zügen analysiert; bei allen bis auf 5 fanden sich Elemente außerhalb der offiziellen Betriebsanweisungen
Nachwirkungen und Umfang der Veröffentlichung
- In dieser Angelegenheit laufen Klagen
- Ob das polnische Amt für Verbraucher- und Wettbewerbsschutz oder die Eisenbahnverkehrsbehörde konkrete Maßnahmen ergriffen haben, ist nicht bekannt
- Die Forschenden meldeten ihre Erkenntnisse an CERT Polska
- CERT Polska informierte die „zuständigen Behörden“
- Der Fall wird von Strafverfolgungsbehörden behandelt
- Dieser Text ist eine Kurzfassung der Inhalte, die Jakub Stępniewicz, Sergiusz Bazański und Michał Kowalczyk am 5. Dezember 2023 auf der Konferenz Oh My H@ck vorgestellt haben
- Der Originaltext ließ einen großen Teil der vollständigen technischen Analyse aus und erklärte, man hoffe, dass die Forschenden ein separates technisches Dokument erstellen und veröffentlichen würden
1 Kommentare
Meinungen auf Hacker News
Es gibt auch einen neueren verwandten Beitrag: Polish trains lock up when serviced in third-party workshops – https://news.ycombinator.com/item?id=38530885 – Dezember 2023, 347 Kommentare
Es ist kaum zu fassen, wie dreist das ist. Code, der eine Lokomotive bricked, wenn ihre GPS-Koordinaten länger als 10 Tage auf dem Gelände eines konkurrierenden Wartungsbetriebs bleiben.
Das geht weit über Dinge hinaus, die Reparaturen erschweren, wie undokumentierte Schnittstellen oder kryptografisch signierte Firmware; für mich kommt das böswilliger Sachbeschädigung nahe. Ich kenne das polnische Rechtssystem nicht, aber ich kann mir nicht vorstellen, wie das einfach durchgehen kann.
Die Züge existieren bereits und müssen fahren, aber Wartungs- und Reparaturfirmen können die Software wegen des Urheberrechts nicht legal ändern. Eine völlige Zwickmühle. Ich hoffe, dass das Unternehmen enorme Geldstrafen bekommt und sogar strafrechtlich belangt wird, aber ich bezweifle, dass es tatsächlich so kommt.
Ein motiviertes Rechtsteam könnte hier vermutlich schwerwiegende anwendbare Vorwürfe finden. Insbesondere dann, wenn diese Züge oder Lokomotiven zur kritischen Infrastruktur gehören, wobei das nicht garantiert ist.
Einen geheimen Handshake einzubauen und Verfahrensdokumentation so schlecht zu machen, dass die Konkurrenz inkompetent wirkt, ist etwas völlig anderes, als das eigene Produkt absichtlich kaputtzumachen, nur weil es in die Werkstatt eines Wettbewerbers gekommen ist.
Der Titel ist etwas irreführend. Das „Gate“ in diesem Fall besteht nicht darin, wie bei Dieselgate unter künstlichen Bedingungen die Zulassung zu bestehen, indem man Umweltfreundlichkeit vortäuscht, sondern darin, einen falschen Defekt zu simulieren.
Das Unternehmen hatte einen Algorithmus fest einprogrammiert, der anhand von Standortdaten erkannte, dass ein anderes Unternehmen den Zug repariert hatte, dann bei normal funktionierenden Teilen wie dem Kompressor einen Defekt meldete und den Zug außer Betrieb setzte.
Natürlich können die beiden Fälle nicht völlig identisch sein, aber es ist klar, warum diese Analogie gezogen wurde.
Die eine bestand darin, dass der Zug nach 10 Tagen an einem konkurrierenden Wartungsstandort, basierend auf GPS, funktionsunfähig gemacht wurde. Die andere bestand darin, dass in einer bestimmten Firmware fest einprogrammiert war, einige Tage nach der nächsten geplanten Wartung einen Kompressordefekt vorzutäuschen.
Am schlimmsten ist die Stelle: „In Polen ist es schwer, eine Institution zu finden, die mehr als höfliches Interesse an der Sache gezeigt hat. Ich weiß auch nicht, ob das Amt für Verbraucher- und Wettbewerbsschutz oder das Eisenbahnverkehrsamt irgendwelche Maßnahmen ergriffen haben.“
Verbraucherschutzbehörden haben nicht so weitreichende Befugnisse wie diese Behörden.
Auch die Diskussion zum früheren Beitrag über den verwandten Artikel ist lesenswert: https://news.ycombinator.com/item?id=38530885
Die Lösung für merkwürdige Probleme bei Motorsteuerungen wie Manipulationen von Abgastests oder die Behinderung von Reparaturen durch Dritte könnte die Standardisierung der Schnittstellen solcher Systeme sein.
Wenn Sensorausgaben standardisiert sind, kann man verschiedene Komponenten austauschen und überprüfen, ob das System die Regulierungsbehörden nicht täuscht.
[1]: https://wheelsports.co/formula-1s-standardised-ecu-explained...
Ich habe einen Freund mit einem WRX; das Auto hat keinen Kat, einen großen Turbo und ein Tuning und dürfte niemals eine Abgasprüfung bestehen. Aber weil die Sensordaten synthetisch erzeugt werden und die relevanten Teile steuern, gibt es keine Fehlercodes, und es kommt jedes Mal problemlos durch.
Es wäre gut, das schwarze Loch namens Firmware zu beseitigen und Audits zu ermöglichen.
Vollständige Standardisierung ist gar nicht nötig; Offenheit würde schon reichen. Aber grundsätzlich ist das die richtige Richtung.
Es sieht so aus, als hätten sie per Software absichtliche Sabotage betrieben, um zu verhindern, dass günstigere Drittanbieter-Services statt des Herstellerservices genutzt werden.
Ich bin gespannt auf die Entscheidung des Gerichts.
Es ist ein Problem, dass Gesetzgeber, Gerichte und Öffentlichkeit bei technischen Fragen den Überblick verlieren, aber dieses Verbrechen dürfte gut unter bestehende strafrechtliche Vorschriften zu Sabotage fallen. Die Methode ist „neu“, das Verbrechen selbst aber klassisch.
Der Eindruck ist, dass die Qualität von Zug-Firmware insgesamt nicht besonders gut ist; hoffentlich führt dieser Skandal zu strengeren Prüfungen.
Vor drei Jahren beschwerte sich die Deutsche Bahn öffentlich über „skurrile“ Softwareprobleme bei neu gelieferten Bombardier-Zügen. Wenn der Lokführer etwa die Fahrtrichtung wechselte, stürzte die Zugsoftware ab, und der Neustart dauerte eine Stunde [0]. In der Schweiz gab es 2018 ähnliche Probleme [1].
Als Informatiker ist mir das peinlich. Man kann es mit alten ostdeutschen Zügen aus den 1980ern [2] vergleichen, die hier bis vor Kurzem westdeutsche Reisezugwagen aus den 1950ern [3] zogen. Digitale Elektronik gab es kaum oder gar nicht, und es gab keine Bootzeit. Sie funktionierten einfach. Und wenn nicht, wusste der Lokführer meist, wo er am Motor mit dem Hammer draufschlagen musste, damit es wieder ging. Man kann vom Lokführer nicht erwarten, die Zug-Firmware zu hacken und gdb zu starten, um herauszufinden, warum der Zug sich nicht bewegt.
[0] https://www.sueddeutsche.de/wirtschaft/deutsche-bahn-ic-1.47...
[1] https://bahnblogstelle.com/33872/twindexx-swiss-express-soft...
[2] https://de.wikipedia.org/wiki/DR-Baureihe_243
[3] https://de.wikipedia.org/wiki/N-Wagen
Unternehmen, die Dinge mit Software darin bauen, bewegen sich nicht in einem Markt, der bereit ist, Softwareleuten das Zwei- bis Dreifache von früher zu zahlen. Übrig bleiben Menschen, die den Spaß als Teil der Differenz in der Gesamtvergütung akzeptieren, und Menschen, die keinen besser bezahlten Job bekommen. Die meisten sicherheitskritischen Systeme, die wir nutzen, werden von solchen Leuten gebaut. Vergleicht man die Entwicklervergütung bei X und SpaceX, sieht man, wie der Markt funktioniert. Spaß zählt zwar zur Gesamtvergütung, aber es führt auch dazu, dass Leute, die keine guten Entwickler sind, in diesem Bereich neue Prozesse und Werkzeuge entwerfen. Es würde mich nicht wundern, wenn sie einem schon überholten Full-Stack-Hype hinterherlaufen und versuchen, ihn auf Zug-Firmware anzuwenden. In Jira steht zehnmal so viel Text wie in Git, es wird Scrum-Wasserfall-Entwicklung betrieben, und in sicherheitskritische Embedded-Systeme werden REST-APIs oder serviceorientierte Architekturen eingebaut.
Abgesehen vielleicht von Beckhoffs Tc3 ist man noch nicht einmal bei Objektorientierung angekommen, und das ganze Feld steckt in der Bluescreen-Mine der Vergangenheit fest. Komplexität wird mit dünnen Normdokumenten verwaltet, Versionskontrolle gibt es nicht, während Maschinen auf der Sensor- und Aktorenseite immer komplexer werden. Man kann moderne Maschinen nicht wie kleine Embedded-Hobbygeräte behandeln, aber die Branche tut genau das. Externe Programmierer kommen hinein und verdienen gutes Geld damit, die Probleme von gestern mit ordentlicher Softwarearchitektur und C-Entwicklungspraxis zu lösen. Aber die Branche lernt nicht daraus. Für sie wird Softwareentwicklung nie ein Berufsfeld sein.
Viele moderne Züge haben Probleme mit grundlegender Fahrsoftware [0] und Verzögerungen bei der Softwarezulassung [1]. Den schlimmsten Rückschritt sehe ich aber im Verlust der Kompatibilität. Moderne Triebzüge funktionieren faktisch nur zusammen mit Triebzügen desselben Pakets. Selbst wenn es dasselbe Modell ist, passen sie oft nicht zusammen, wenn zwei Unternehmen sie getrennt bestellt haben; und wenn die Betreiber verschieden sind oder die Bestellungen mehr als zehn Jahre auseinanderliegen, kann man den gemeinsamen Einsatz fast vergessen. Vor der Digitalisierung war es dagegen üblich, Straßenbahnen unterschiedlicher Generationen zusammen einzusetzen und die Verkabelung entsprechend anzupassen. Alte Reisezugwagen funktionieren problemlos miteinander, aber IC2 und Railjet oder RailJet und ICE-L zusammen zu betreiben, ist nicht einfach. Oft funktionierten auch nur bestimmte Lokomotiven mit bestimmten Wagen.
Computerisierte Systeme miteinander zum Laufen zu bringen, ist wegen ihrer höheren Komplexität und Undurchsichtigkeit viel schwieriger. Klassische Logikplatinen lassen sich meist leicht rückentwickeln, Software-Reverse-Engineering ist dagegen eine hochspezialisierte Arbeit. Dieses Phänomen ist auch in anderen Bereichen deutlich zu sehen, in denen der Wechsel zu proprietären digitalen Protokollen die Interoperabilität stark verschlechtert hat.
Das liegt auch daran, dass Software undurchsichtig ist und deshalb schwerer zuzulassen als frühere Technik, aber auch an tatsächlich mangelnder Qualität. Einer der Gründe, warum Bombardier in große Schwierigkeiten geriet, war ebenfalls schlechte Software; sogar ein Vertrag über mehr als 40 Fahrzeuge wurde gekündigt ([2]).
Ich denke, zuverlässige und verständliche Software zu bauen ist viel schwieriger als der Bau von Logikschaltungen oder mechanischen Systemen. Eine Lösung kenne ich nicht, aber das Problem besteht schon seit Langem.
[0]: https://www.vrt.be/vrtnws/de/2013/02/12/belgische_bahn_storn...
[1]: https://www.augsburger-allgemeine.de/augsburg/Neue-Zuege-auf...
[2]: https://de.wikipedia.org/wiki/Bombardier_Talent_3#%C3%96BB
Ich konsumiere nur englischsprachige Inhalte. Inhalte aus anderen Ländern bekomme ich nur mit, wenn sie über große Medien nach außen dringen.
Da fragt man sich, wie viele gute Inhalte es geben könnte, die übersetzt werden könnten.
Allerdings ist Englisch – zumindest in den besser gebildeten Teilen der Welt – inzwischen ironischerweise zur Lingua franca geworden, und selbst Menschen, denen ihre Muttersprache angenehmer ist, lassen ihre besten Arbeiten oft ins Englische übersetzen, damit sie breiter gelesen werden. Wissenschaftliche Arbeiten sind ein typisches Beispiel. Vielleicht ist Englisch das größte Geschenk, das Großbritannien der Welt gemacht hat.
Von dieser ganzen Anbieterbindung bei den Zügen habe ich aber zuerst auf HN erfahren. Sonst hätte ich es entweder gar nicht mitbekommen oder erst Wochen oder Monate später.