De l’utilité des tests d’intrusions sur les navires

De l’utilité des tests d’intrusions sur les navires

Dans un article publié hier, la société Pen Test Partners, connue pour ses articles de blog sur la cybersécurité maritime, a publié un nouvel article un peu anxiogène sur le sujet.

Bon, il parait qu’il ne faut plus tenir de discours anxiogène, donc on va (essayer) de l’analyser sereinement.

La société, présente au Royaume-Uni et aux Etats-Unis, mène notamment des tests d’intrusions à la demande de ses clients sur différents types de navires. Dans leur article, ils précisent que, à chaque fois, ils parviennent à découvrir des systèmes d’informations que peu – voire aucun membre d’équipage – ne connait, ou qu’ils n’en connaissent pas l’utilité. Même si cela peu surprendre. Pourtant, il y peut y avoir des explications (que l’article ne souligne pas, préférant – un peu trop à mon goût – le buzz). Je vous donne quelques possibilités d’explication :

  • Un navire, c’est un équipage, mais qui n’est pas nécessairement constitué de manière permanente : il peut évoluer au fur et à mesure des besoins et constituer un véritable patchwork. L’article ne le précise pas. Pour avoir eu l’occasion de travailler sur les sujets cyber sur quelques navires cyber, je peux vous au contraire, que, à chaque fois, chez les armateurs rencontrés, l’équipage était parfaitement informé du rôle des différentes machines présentes en passerelle et ailleurs.
  • Un armateur n’est ni le concepteur, ni l’intégrateur d’un navire : on lui livre un navire répondant à ses critères. Il n’a donc pas nécessairement une connaissance intrinsèque du navire (câblage, fonctionnement intime des systèmes d’information, etc…). Cela peut surprendre, mais ne nous trompons pas : c’est aussi le cas dans de nombreux autres secteurs (quelle entreprise – non informatique – connait parfaitement le câblage de tous ses bâtiments ?
  • Les maintenanciers déposent effectivement régulièrement des équipements à bord des navires pour réaliser des opérations de maintenance préventive ou corrective, notamment pour comprendre l’usure ou les dysfonctionnements d’une installation. Rien de surprenant, le maintenancier ne pas pas maintenir à bord du navire du personnel de maintenance. D’où Teamviewer, pour disposer d’un accès à distance à la machine en question.

Alors suis-je surpris/choqué ? Non. La vulnérabilité, dans ce sujet, est surtout le maintenancier, qui n’a, on est d’accord, pas pris les mesures de sécurité qui s’imposent sur les opérations de maintenance à distance. Donc là où l’article considère que ce type de découverte dans le monde maritime, c’est  » business as usual », d’abord c’est un peu exagéré, et deux, c’est méconnaître aussi les raisons intrinsèques du pourquoi : on traite encore une fois les conséquences et non les causes : le problème reviendra donc.

Mais continuons sur l’article.

Côté armateur à terre, l’article souligne que personne n’a connaissance de l’existence de cette machine. Bon, surprenant ? Non. Suivant la taille du navire, l’armateur ne dispose bien souvent d’aucun expert en systèmes d’information, le recours à la sous-traitance étant particulièrement important.

Installé par un tiers ? Oui, on en a parlé au-dessus : pas de surprise. Pas d’étiquetage, OK, pas complètement surprenant car il s’agit peut-être d’un poste temporaire (l’article ne le dit pas). En revanche, effectivement, si sa vocation est de rester en permanence à bord du navire, c’est moins légitime. Mais si les contrats fixés par l’armateur ont « laissé la main » au maintenancier, ce n’est pas surprenant.

Autre défaut, qui a contribué à l’oubli de la machine en passerelle, le poste informatique en question ne disposait pas d’un mode « nuit ». Or, en passerelle, afin de permettre aux équipes de quart de mieux voir ce qui se passe à l’extérieur la nuit, les équipements disposent de fonctions permettant de réduire la luminosité des écrans. L’équipage a donc « couvert » l’écran pour éviter toute perturbation lumineuse.

Deux câbles RJ-45 sortent du PC en question. Les pentesteurs décident de le déconnecter (après une analyse de risques) et l’utiliser un dispositif TAP (Test Access Port) pour récupérer le trafic circulant sur le réseau de manière sûre. Ils identifient la diffusion de trafic de type NMEA0183 en UDP sur ce réseau. D’après l’entreprise, c’est un cas assez classique sur les réseaux industriels. Là, je suis plus ou moins d’accord : sur des navires récents ou de taille moyenne, pourquoi pas, sur des navires anciens ou soumis à des règles particulières de navigation, c’est moins sûr. Ce qui est possible, c’est que certains éléments figurant dans la trame NMEA étaient nécessaires à l’équipement ou à l’installation distante (par exemple : la vitesse ou le cap), ou que les ordres entre les équipements en passerelle et les installations distantes se font en NMEA (par exemple : les ordres du pilote automatique).

L’en-tête des trames NMEA indiquait « $IN », généralement utilisé par les instruments de navigation en passerelle. Après vérification, l’entreprise a identifié que l’un des quatre systèmes ECDIS en passerelle émettait la même information sur un port série sur lequel juste le fil TX (émission) ếtait câblé.

Connecté à la « boîte mystère » était connecté un convertisseur série Moxa, comme celui-ci, non étiqueté, et un câble blindé en sortait. Ce type de câble est très difficile à suivre dans un navire pour en déterminer la provenance/destination. Après une analyse de risques, l’équipe décide d’écouter ce qui transite sur ce câble et y détecte du trafic Modbus, avec un équipement « maître » lisant des registres d’un équipement en mode « esclave ». La lecture de ces valeurs montre une valeur de 169, le navire faisant route à 16,9 nœuds, il y a des chances que les deux valeurs soient liées… il pourrait donc s’agir d’informations échangées entre la passerelle et, par exemple, la machine.

Après un retour à quai, l’équipe investigue la machine en question, qui fonctionne sous Windows et joue le rôle de maître Modbus et interroge régulièrement un esclave pour obtenir des informations. La difficulté d’une connexion Modbus est qu’elle nécessite l’émission et la réception d’information sur la connexion Modbus : il n’est pas possible de déconnecter le câble d’émission, par exemple : il est donc vraisemblable que, depuis la passerelle, la machine sous Windows puisse potentiellement écrire des registres en utilisant ce protocole. Lors des essais réalisés par l’équipe, une action d’écriture/lecture depuis le poste en passerelle confirme la chose. En parallèle, l’équipe cherche l’origine de la connexion et la retrouve, 11 ponts plus bas, sur une interface série donnant sur un automate, non documenté, et ne disposant pas d’adresse IP mais d’autres connexions, potentiellement vers d’autres automates de la machine. La machine Windows, elle, disposait the Team Viewer et n’était pas à jour.

Après enquête, il apparaît que le contrat avec le sous-traitant avait été arrêté il y a plusieurs années. Il s’agissait d’un système (c’est très à la mode d’ailleurs, vous savez, faire des « data lakes » partout) chargé de récupérer des informations de conduite de la machine et d’ailleurs (ECDIS…) pour déterminer si les performances du navire étaient « économiques » et efficaces et tenter de les optimiser.

Les commentaires sont fermés.