Des trains polonais NEWAG se verrouillaient après des réparations dans des ateliers tiers

• Des chercheurs ont passé environ un an à rétroconcevoir le code PLC des trains NEWAG Impuls EMU en Pologne afin d’analyser un problème où ils s’arrêtaient après une maintenance dans des ateliers tiers
• Le constructeur attribuait la cause à une erreur de maintenance et affirmait que l’entretien devait être effectué par lui-même, mais le code contenait une logique qui verrouillait les trains avec de fausses erreurs dans certaines conditions
• Certaines versions du contrôleur tentaient d’identifier les ateliers tiers à l’aide de coordonnées GPS, et il était possible de lever le verrouillage avec une combinaison de touches non documentée dans la cabine
• Par la suite, les logiciels PLC ont supprimé le déverrouillage par combinaison de touches, mais la logique de verrouillage est restée, et après certaines mises à jour l’HMI affichait même un avertissement de violation du droit d’auteur
• Le dispositif de télémétrie GSM du train transmettait les conditions de verrouillage, et dans certains cas il semblait même possible de verrouiller le train à distance

---

Rétroconception du code PLC des NEWAG Impuls EMU

• q3k, redford et mrtick ont rétroconçu pendant environ un an le code PLC des NEWAG Impuls EMU
• Les trains concernés présentaient des symptômes de verrouillage arbitraire après avoir été entretenus dans des ateliers tiers
• Le constructeur affirmait que la cause venait d’une erreur de maintenance dans ces ateliers et soutenait que l’entretien devait être réalisé par lui plutôt que par un tiers

Les conditions de verrouillage présentes dans le code

• Le code PLC contenait une logique qui verrouillait le train avec de faux codes d’erreur
  • Le verrouillage pouvait se produire après une certaine date
  • Il pouvait aussi se déclencher lorsque le train n’avait pas circulé pendant une certaine durée
• Une version du contrôleur contenait des coordonnées GPS, utilisées pour limiter ce comportement aux ateliers tiers

Méthode de déverrouillage non documentée et changements ultérieurs

• Il était possible de déverrouiller le train en appuyant sur une certaine combinaison de touches sur le pupitre de conduite
• Cette méthode de déverrouillage n’était pas documentée
• Dans des versions plus récentes du logiciel PLC, le déverrouillage par combinaison de touches a été supprimé, mais la logique de verrouillage est restée en place

Avertissement HMI et télémétrie GSM

• Après certaines mises à jour de NEWAG, le pupitre de conduite affichait un message d’avertissement lié à une violation du droit d’auteur
  • Le message apparaissait lorsque l’HMI détectait une partie des conditions dans lesquelles le verrouillage aurait dû s’activer, alors que le train continuait de circuler
• Le train disposait d’un dispositif de télémétrie GSM
  • Cet appareil transmettait les conditions de verrouillage
  • Dans certains cas, il semblait possible de verrouiller le train à distance

[GN⁺]

Avis sur Hacker News

• Ces trains sont utilisés de manière assez exclusive par de nombreuses compagnies ferroviaires régionales en Pologne. Les niveaux de maintenance vont de P1 au plus complexe, P5 ; auparavant, seules les grandes entreprises prenaient en charge les niveaux P3 et supérieurs, mais depuis quelques années, l’Agence de l’Union européenne pour les chemins de fer a ouvert le marché, et de plus petits concurrents ont commencé à remporter des appels d’offres à des prix bien plus bas.
  L’affaire a commencé quand quatre trains entretenus par SPS Mieczkowski n’ont même plus pu démarrer ; l’entreprise a dû payer 500 000 € d’amende, et les trains ont été renvoyés chez Newag. Dans le même temps, des trains d’autres sociétés, qui n’étaient même pas passés en maintenance, se sont aussi retrouvés immobilisés simplement parce qu’ils étaient restés trop longtemps au même endroit. SPS Mieczkowski a finalement engagé Dragon Sector pour enquêter, et plusieurs routines distinctes de désactivation des trains ont été découvertes.
  L’affaire fait l’objet d’une enquête du Bureau central anticorruption polonais, mais il est permis de douter qu’elle porte un coup sévère à Newag. L’Office polonais du transport ferroviaire, qui inondait les compagnies de réclamations et émettait des injonctions pour de petites erreurs dans les horaires, s’est retiré de cette affaire ; et l’achat de trains étant soumis à des procédures d’appel d’offres très strictes, les compagnies ferroviaires ont très peu de marge de manœuvre.

  • Cela ressemble clairement à une infraction de sabotage au titre de l’article 254a du code pénal polonais. La procédure d’appel d’offres n’est pas importante dans cette affaire ; il faut simplement un procureur compétent.
    https://sip.lex.pl/akty-prawne/dzu-dziennik-ustaw/kodeks-kar...
  • L’Agence de sécurité intérieure enquête aussi, et il semble difficile pour Newag d’échapper à de gros ennuis. En interne aussi, l’affaire est prise extrêmement au sérieux.
    Il existe une quantité énorme de preuves de ce qui s’est passé, donc les chances qu’ils s’en sortent sont minimes. Ils essaient malgré tout de se défendre en affirmant avoir été piratés. En gros, des hackers auraient flashé le firmware de trains entretenus par un concurrent pour les briquer, mais les coordonnées GPS de tronçons ferroviaires concurrents étaient littéralement codées en dur.
  • Le modèle plus récent, Impuls 2, est aussi utilisé hors de Pologne. La FSE italienne en exploite 11.
    Cela dit, si l’on considère que Newag voulait continuer à se développer en Italie, il semble peu probable qu’ils aient aussi saboté ces trains-là. Bien sûr, ils ont peut-être aussi estimé qu’ils pouvaient se permettre de griller de nouveaux clients.

• Des liens vers un article plus long et des détails supplémentaires sont enfouis dans les commentaires.
  En polonais :
  https://zaufanatrzeciastrona.pl/post/o-trzech-takich-co-zhak...
  https://wiadomosci.onet.pl/kraj/awarie-pociagow-newagu-haker...
  En anglais :
  https://zaufanatrzeciastrona-pl.translate.goog/post/o-trzech...
  https://wiadomosci-onet-pl.translate.goog/kraj/awarie-pociag...
  Pour ajouter un peu de contexte, la Pologne est divisée en 16 voïvodies et, depuis les réformes du début des années 2000, presque chaque région possède sa propre compagnie ferroviaire régionale, avec des coopérations entre elles. Le fait qu’il se passait quelque chose de suspect avec les trains Newag était en pratique connu de tout le monde depuis plus d’un an. Les pannes se succédaient sur des trains appartenant à plusieurs compagnies, qui faisaient appel à des prestataires de maintenance tiers plutôt qu’à Newag. C’est pourquoi l’un de ces prestataires a engagé des hackers, et il a fallu du temps pour comprendre exactement ce qui se passait par rétro-ingénierie.

  • Étant polonais, je savais ce que signifiait województwo, mais j’ignorais qu’il existait un équivalent anglais, voivodship. J’ai trouvé intéressant de lire l’article Wikipédia à ce sujet.
    https://en.wikipedia.org/wiki/Voivodeship

• Cela m’a rappelé le « crash » AARD que Microsoft avait utilisé à l’époque pour saboter de fait la concurrence de DR-DOS
  Le code AARD était un fragment de code inclus dans les versions bêta de Microsoft Windows 3.1, destiné à déterminer si Windows s’exécutait non pas sur MS-DOS ou PC DOS, mais sur un compatible concurrent comme DR-DOS, et à afficher dans ce cas un message d’erreur obscur. Ce code en langage machine chiffré par XOR, automodifiant et volontairement obscurci utilisait plusieurs structures et fonctions DOS non documentées
  https://en.wikipedia.org/wiki/AARD_code
  https://www.geoffchappell.com/notes/windows/archive/aard/drd...
  https://news.ycombinator.com/item?id=36042213

  • De la part de Microsoft, ce serait crédible. C’est bien la société qui avait dit à Compaq que s’ils vendaient ne serait-ce qu’un PC avec OS/2 Warp installé, ils ne pourraient plus jamais vendre de PC avec Windows
    Ce sont toujours les humains qui finissent par empêcher les bonnes choses de durer. OS/2 Warp était un excellent système d’exploitation
  • Le code AARD était un avertissement non fatal qui n’empêchait pas l’utilisation de Windows, et il n’a même jamais été livré tel quel. Dans la version finale, il avait été patché de sorte à être inatteignable, probablement via un patch binaire pour éviter les régressions et réduire les longs temps de build. Il y avait aussi un gros problème de packing lié à l’optimisation de la disposition sur disquettes
    Pour mémoire, DR-DOS était déjà une impasse dès sa sortie. Il était très clair que les gens et les OEM n’achèteraient pas deux systèmes d’exploitation à la fois : un OS graphique, et un DOS faisant office de bootloader pour cet OS graphique. L’idée qu’il existerait pendant une durée significative un marché autonome du DOS 16 bits uniquement texte relevait du pur fantasme, et DR-DOS n’a jamais pesé en volume de ventes. Même si le code AARD avait été présent dans les versions finales réelles de Windows 3.x, cela n’aurait rien changé
  • Ce n’est pas vraiment la même chose que ce cas-ci. Le crash AARD était une rupture de compatibilité intentionnelle ; ici, on est plutôt proche de l’obsolescence programmée
    Désactiver un train parce qu’il est resté immobilisé « trop longtemps » : j’imagine que Microsoft aurait aussi aimé contrôler sa plateforme à ce point
  • D’après l’article, la fonctionnalité n’était pas activée ; dans ce cas, je ne vois pas bien comment elle aurait pu servir à saboter la concurrence de DR-DOS
  • 280 millions de dollars de règlement en échange de plusieurs années de domination mondiale des systèmes d’exploitation, c’est plutôt bon marché

• L’action Newag a pas mal chuté après la publication du billet ; serait-ce le premier exemple de correction de prix déclenchée par Mastodon ?
  https://g.co/kgs/WVku4C

  • Elle reste tout de même à +10 % sur un mois et +25 % sur trois mois
  • Les médias polonais en ont aussi parlé, donc ce n’est pas uniquement dû à Mastodon

• Le 21 novembre 2022, il y a eu une situation assez cocasse avec une autre rame, qui n’était même pas en service mais refusait de fonctionner. L’ordinateur signalait une panne de compresseur, mais après vérification par les techniciens, le compresseur n’avait aucun problème. Pourtant, le train ne levait pas son pantographe, et l’analyse du code de l’ordinateur a révélé une condition qui déclenchait artificiellement la panne
  En gros, si le jour était supérieur ou égal à 21, le mois supérieur ou égal à 11, et l’année supérieure ou égale à 2021, il fallait signaler une panne de compresseur

  • En interprétant cela charitablement, le fabricant du compresseur a peut-être intégré une date d’expiration pour garantir le remplacement de pièces critiques. Mais il s’agit probablement simplement d’une pratique commerciale douteuse
  • Le vrai crime, c’est de ne pas avoir utilisé une bibliothèque date/heure standard et une simple comparaison > 2021-11-21
  • La raison pour laquelle le code a été écrit ainsi pourrait être d’éviter qu’une date précise apparaisse directement dans le code compilé

• Ce constructeur n’a-t-il pas, en paralysant une infrastructure critique, littéralement pris la Pologne en otage ? C’est un crime d’une audace incroyable, et je ne suis pas vraiment convaincu qu’ils puissent s’en tirer sans conséquences

  • Ce n’est pas l’atelier de maintenance, mais le constructeur. L’atelier a simplement remporté l’appel d’offres, et le fournisseur a décidé de se venger

• Le monde est petit. J’ouvre HN et je tombe sur une histoire digne d’un film concernant des trains que j’ai pris plusieurs fois. Il est même possible que je sois passé à bord de l’un de ces trains effectivement immobilisés
  En tout cas, cela veut dire qu’il n’y a pas eu de revue de code, ou bien que les reviewers l’ont acceptée pour une raison ou une autre. Je ne sais pas trop laquelle de ces deux possibilités est la plus inquiétante

  • Tu veux dire une revue de code par un tiers ? Est-ce que ça se fait normalement ?
    Ici, il semble évident que le constructeur du train l’a voulu et a demandé l’écriture de ce code. On n’est pas dans un cas où un hacker l’aurait glissé en cachette sans que les responsables le sachent. Je me demande donc de quelle revue de code, par qui, il serait question
    En lisant les autres commentaires, il semble que l’article en tête sur HN ait changé, et que certains commentaires aient été écrits à partir d’un article qui contenait beaucoup moins d’informations. C’est probablement pour cela que les commentaires prêtaient à confusion
  • Le code a probablement été correctement relu et a sans doute fait l’objet de tests assez sérieux. On peut le deviner au fait qu’il existe un géorepérage avec des conditions de déclenchement supplémentaires

• Malheureusement, les trains Newag sont d’une qualité nettement supérieure à ceux de l’autre constructeur polonais, Pesa. Ils étaient visiblement tellement fiables qu’il a fallu leur fabriquer des pannes artificielles

• Je me demande qui a codé ces conditions malveillantes, et qui était au courant. Personne n’a envisagé de lancer l’alerte ?
  Pour référence, il existe une page d’avis anonymes d’employés sur l’entreprise : https://www.gowork.pl/opinie_czytaj,19587
  Cela ressemble à un environnement de travail toxique

  • En tant que développeur logiciel, si on vous demande de faire ce genre de chose, il faut absolument exiger des instructions écrites

• Il sera intéressant de voir l’effet de cette situation sur le contrat avec la société européenne de services ferroviaires Akiem. Akiem a signé avec Newag un contrat de 164 millions d’euros pour des services et des trains destinés à la France
  [1] https://biznes.pap.pl/pl/news/all/info/3509606,newag-inks-eu...