Vous vous souvenez du Dieselgate, le scandale selon lequel certains véhicules diesel détectaient un test d’émissions et fonctionnaient plus proprement, « trichant » le test ? Traingate pourrait simplement mettre cela en perspective. Nous raconterons l’histoire depuis le début, mais attachez votre ceinture pour une aventure sauvage et étonnante. Tout commence par une révision de maintenance des trains polonais. Ces trains ont été construits par Newag, qui a soumissionné pour le contrat de maintenance, mais le contrat a été remporté par une autre société, SPS. Ce type de révision implique de décomposer chaque train en ses composants, de l’inspecter, de le lubrifier, etc., et de tout remonter. Le premier train a suivi ce processus, a été entièrement remonté, puis a refusé de bouger. Après avoir épuisé toutes les mesures de dépannage conventionnelles, SPS a fait appel aux pirates.
Dragon Sector est un groupe de recherche polonais qui a attiré l’attention du monde entier grâce à ses travaux sur la sécurité du BIOS des ordinateurs portables Toshiba. Et il s’avère que c’était le groupe idéal pour ce travail. Qu’il s’agisse de bricoler du matériel ou d’améliorer la prise en charge par Ghidra de l’architecture Infineon TriCore, beaucoup de travail a été effectué pour même mettre un pied dans les systèmes du train. Mais finalement, ils ont pu faire des vidages de mémoire et comparer le train en panne avec ceux qui fonctionnaient. Il y avait un ensemble d’indicateurs de configuration qui semblaient détenir la clé. Mais ce train en particulier était absolument nécessaire en service. Newag, le constructeur d’origine, a donc finalement été contacté pour terminer la maintenance et remettre le train en marche. Cependant, les pirates ne sont rien s’ils ne sont pas persistants. Après avoir passé une nuit blanche et avec quelques minutes à perdre, Dragon Sector a réussi à écraser la mémoire du train en panne avec une configuration valide, et il a repris vie.
Jusqu’à présent, rien ici ne semble suspect. Les contrôles de démarrage après la maintenance pourraient facilement mal tourner, conduisant à ce genre de situation. Mais Dragon Sector a continué à creuser, à affiner ses outils et à découvrir davantage de secrets sur le micrologiciel du train. Et ce qu’ils ont découvert était étonnant. En premier lieu, il y avait les coordonnées GPS, correspondant à chaque gare de triage en Pologne capable d’effectuer ce type de révision de maintenance. Si un train était garé dans une gare de maintenance autre que celle de Newag pendant plus de 10 jours, le drapeau se déclencherait et le train serait désactivé. Il est difficile de voir cette « fonctionnalité » comme autre chose qu’une tentative flagrante de détruire tout train qui ne serait pas revenu à Newag pour maintenance. Mais attendez, il y a plus.
Le remplacement de certains composants entraînerait une casse similaire, jusqu’à ce qu’un code de triche non documenté soit saisi dans la console informatique principale du train. Dans un autre cas, un train tomberait en panne après avoir parcouru un million de kilomètres. Un autre train devait tomber en panne à cause d’un compresseur défectueux à une date donnée – et une erreur de programmation a retardé cette panne jusqu’à un an plus tard. Au total, Dragon Sector a examiné 29 trains à travers la Pologne et a trouvé ces merveilleuses petites surprises dans 24 d’entre eux. Grâce au CERT Polska de Pologne, les forces de l’ordre ont été informées de cette affaire.
En réponse, Newag a accusé Dragon Sector de calomnie et de délits informatiques, ainsi que de menace pour la sécurité ferroviaire. Tout ce que nous pouvons dire, c’est que nous espérons qu’une enquête approfondie établira la vérité sur cette affaire et demandera des comptes aux véritables criminels.
C’est toujours DNS
Vous êtes-vous déjà demandé comment un serveur DNS obtient des mises à jour sur les noms DNS ? Il s’avère qu’il existe plusieurs façons. La première consiste pour les clients à envoyer des mises à jour directement, en annonçant leur nom DNS et leur adresse IP. Les mises à jour DNS dynamiques sont prises en charge sur plusieurs serveurs DNS, y compris Active Directory (AD), et dans presque toutes les implémentations, elles disposent d’une implémentation de sécurité raisonnable. D’un autre côté, des mises à jour DNS sont également envoyées dans le cadre d’une requête DHCP. Et ceux-là… ont des problèmes.
Cet article est très axé sur Active Directory, mais cela ne nous surprendrait pas de trouver un problème similaire sur d’autres serveurs DHCP. À savoir, la mise à jour DNS n’est pas authentifiée. Tout appareil disposant d’une adresse IP peut demander un nom DNS en même temps. La façon dont cela fonctionne dans un environnement de serveur Microsoft est que le service DNS utilise ses propres informations d’identification pour transmettre la mise à jour DNS au serveur DNS. S’il s’agit de deux serveurs distincts et que le nom est déjà enregistré directement par un autre hôte, la mise à jour échouera. Mais un nom non revendiqué, ou même le nom du serveur DHCP lui-même, sont à gagner. Et dans le cas des services DNS et DHCP exécutés sur le même serveur, pratiquement n’importe quel nom DNS est en jeu. Et dans un environnement AD, cela permet toutes sortes d’attaques supplémentaires contre l’authentification.
Ces problèmes ont été signalés à Microsoft, qui les considère comme des problèmes connus, ne méritant pas vraiment un correctif de sécurité. Il est utile de les connaître lors de la création d’un réseau AD. Pour nous éviter des ennuis, Akamai a écrit Invoke-DHCPCheckup comme un outil PowerShell pour vérifier les problèmes.
Faites la diapositive JMP
Il existe une technique utilisée lors de l’écriture d’exploits, la diapositive NOP. Il s’agit d’une série de commandes No Operation suivies du shellcode cible. L’idée est qu’une vulnérabilité sautera quelque part dans cette zone mémoire contrôlée par l’attaquant, mais la destination exacte peut varier. Ceci est utilisé si souvent que les blocs de 0x90 dans les données sont l’un des indices indiquant qu’ils peuvent être malveillants. il y a un problème avec la diapositive NOP, dans la mesure où cela peut prendre plus de temps que vous le souhaitez pour parcourir toutes les instructions NOP pour accéder au shellcode juteux. Et c’est là que la diapositive JMP entre en jeu.
La base est que nous savons combien d’octets restent dans la diapositive, nous pouvons donc utiliser les instructions JMP pour accéder directement à la charge utile. C’est génial, sauf pour l’alignement. À savoir, le code machine x86 mélange librement instructions et arguments. Si vous ne savez pas exactement où l’instruction atterrira dans votre tampon, comment savoir si vous êtes sur le point d’exécuter un jmp ou d’exécuter le décalage en tant qu’instruction ? Il existe plusieurs manières évidentes d’aborder cela, comme utiliser les valeurs 0x90 comme argument de JMP, suivies d’une zone de glissement NOP beaucoup plus petite pour capturer le JMP.
Celui-ci constitue également un défi, car la commande JMP est basée sur des décalages qui peuvent être positifs ou négatifs, et 0x90 se trouve être un décalage négatif. Cela peut fonctionner, mais la totalité de la charge utile du shellcode doit être construite à l’envers pour la gérer. Il existe une autre option, les opcodes JCC de saut conditionnel. Ce sont 0x70-0x7F dans le code machine, qui parvient à être des décalages positifs. Le seul problème est que ces sauts sont conditionnés à une valeur de registre inconnue. La solution finale consiste à utiliser l’opcode Jump if Greater deux fois, suivi de l’opcode Jump if Less or Equal deux fois. Les deux sont des compensations positives, et tous deux progressent régulièrement dans la diapositive JMP pour finalement atterrir dans une petite diapositive NOP pour enfin exécuter le shellcode. Intelligent!
Bits et octets
Après avoir été licencié, il peut être tentant de brûler les ponts en sortant. Si cela implique d’effacer des référentiels de code, de supprimer des fichiers journaux, de récupérer du code propriétaire, de voler un ordinateur portable de travail et de se faire passer pour des collègues… peut-être pas. Un ingénieur logiciel de la First Republic Bank n’a tout simplement pas pu résister à la tentation. Il purgera deux ans de prison, trois ans de probation et paiera 529 000 $ de dédommagement pour dommages. Cela n’en vaut vraiment pas la peine.
Et pour un rappel brutal pourquoi tout n’a pas besoin d’être connecté au réseau ou à Internet, voyez les conséquences d’une cyberattaque contre Kyivstar en Ukraine. Ce fournisseur de téléphonie et d’accès Internet a été fermé mardi, dans ce qui semble être une attaque dévastatrice d’effacement de données. Les banques et les magasins sont fermés en raison d’un problème de traitement des paiements, et au moins une ville a dû débrancher manuellement ses lampadaires du réseau électrique, car le contrôleur logiciel a été désactivé à la suite de l’attaque. Peut-être que les vieilles minuteries mécaniques étaient meilleures après tout.
