Étiquette : vulnérabilités

Véhicules maritimes autonomes et risques cyber

Les risques

Nous avons déjà évoqué le sujet des véhicules maritimes autonomes dans plusieurs articles précédents, notamment dans le cadre des premiers essais de bacs autonomes en Finlande, dans un article relatif au futur de la marétique, et avons rappelé certaines références réglementaires qui commencent à émerger sur le sujet. On rappellera que, dans le contexte maritime, on trouve et on trouvera des UAV (Unmanned Aerial Vehicles), USV (Unmanned Surface Vehicles) et UUV (Unmmaned Underwater Vehicles). Sans voir ce type de “navires” autonomes partout à très court terme, ni systématiquement à long terme (leur emploi pour le transport de passagers ou de cargaison à haute valeur, ou pour la pêche, pose de nombreuses questions). Cependant, face à une certaine congestion, aux manoeuvres complexes (et souvent dangereuses pour l’homme), dans le contexte militaire, mais aussi par exemple pour des questions de sécurité en mer (prévention anti-collision ou échouage), un certain degré d’autonomie peut être souhaitable. Cependant, qui dit autonomie dit automatisation et, potentiellement, accès à distance et, dans tous les cas, nouveaux risques cyber à prendre en compte. Il serait dommage que, une nouvelle fois, le problème soit pris à l’envers et que l’on pense d’abord aux navires ou aux ports autonomes avant de penser à leur sécurité.

De ce côté-ci de la planète bleue, Rolls-Royce et Wärtsilä sont les deux entreprises du secteur maritime à investir et démontrer leur savoir-faire dans le domaine, que ce soit pour les remorqueurs, les bacs, et les navires autonomes de plus grande taille (cf ma chaîne Youtube pour quelques exemples futuristes ou actuels). Les grands enjeux de cybersécurité sur ces navires sont :

  • l’automatisation : le recours aux automates et à l’IA (vous l’attendiez 🙂 ) vont faciliter le travail au quotidien mais la réalisation automatique de tâches ou la prise de décision automatique posent de réels enjeux de cyber-sécurité, tant au niveau des capteurs (quelle confiance leur accorder), que de l’automate ou du processeur (quelle confiance leur accorder #bis), du programme ou de l’algorithme d’apprentissage utilisés et des données d’apprentissage (#ter), notamment. Côté capteurs, on se rappellera du sujet déjà évoqué des risques liés au positionnement, par exemple. Se poste aussi la question essentielle de la résilience à la mer face à une telle complexité de systèmes ;
  • l’intégration : l’autonomie repose beaucoup sur l’interconnexion de systèmes autrefois isolés (physiquement, logiquement, fonctionnellement) les uns des autres et le recours aux technologies type big data (vous l’attendiez aussi) pour faciliter l’orchestration du navire ;
  • le contrôle et la maintenance à distance : suivant le degré d’autonomie, l’autonomie peut être locale (le chef de quart enclenche le mode autonome, version améliorée du pilote automatique) ou distante (il n’y a plus personne en passerelle et le navire est contrôlé à distance pendant tout ou partie de sa mission). Pour des raisons évidentes de maintenance et de suivi (préventifs ou réactifs), le recours actuel à la maintenance à distance va se renforcer avec ce type de navire : les questions de disponibilité, d’intégrité, voire de confidentialité de ce lien vers la terre sont donc essentielles, d’autant plus que le lien support sera souvent partagé et reposera en grande partie sur Internet.

Les risques
En cas d’incident, les risques peuvent être multiples : armateurs, opérateurs portuaires (on peut même imaginer un cas complexe, en termes de responsabilité, d’un navire autonome accostant dans un smart port aidé par des remorqueurs autonomes : en cas d’accident, la preuve de responsabilité pourrait être complexe à obtenir). La particularité des systèmes autonomes est que, hormis pour des cas d’espionnage, par exemple, il y a de fortes chances pour qu’il ait un impact cyber-physique en cas de cyberattaque (sur l’environnement, le patrimoine, l’homme)…

Parmi les premiers risques liés aux véhicules autonomes, le fait qu’ils s’appuient sur des capteurs (GPS, AIS, éventuellement radar, voire carte numérique) qui peuvent être plus ou moins facilement trompés. Une attaque sur le positionnement (brouillage, mais surtout leurrage) pourrait avoir des conséquences directes et dramatiques pour un navire autonome dont la surveillance (distante) serait défaillante. Si, en plus, l’attaquant parvient à berner le navire et son contrôle à distance (un peu à la Stuxnet), la contre-mesure est bien difficile à mettre en oeuvre. En effet, ce type d’attaque a une conséquence directe : le navire évolue pour reprendre une position correcte : il corrige son cap, voire sa vitesse, de manière autonome à partir de l’information transmise par le capteur. Sans veille humaine, les conséquences pourraient donc être graves : collision avec un autre navire, échouage, collision avec une infrastructure portuaire… voire impossibilité de transit dans une zone critique (détroit…). On se rappelle des démonstrations réalisées par des chercheurs du Texas sur le sujet en… 2013 (déjà !).

Que faire ?

A titre personnel, je vois cinq axes d’effort :

  1. le rôle du régulateur (en l’occurrence l’OMI) qui doit impérativement fixer de hauts niveaux d’exigences pour les navires autonomes en matière de cybersécurité, notamment dans le partage / fusion des données issues de systèmes différents, la confiance dans les capteurs, l’intelligence artificielle (comment l’algorithme réagit en cas d’incohérence, de panne…), et le cloisonnement et la redondance des réseaux et capteurs.
  2. la sensibilisation des industriels et chantiers navals concernés qui auront un avantage concurrentiel à disposer d’une solution sécurisée par défaut sur ce type de navire du futur.
  3. les essais, tests et entraînements liés aux modes dégradés sur ces systèmes. L’objectif est d’en identifier les vulnérabilités en plateforme et dans le cadre d’un processus de certification, mais aussi tout au long du cycle de vie du navire.
  4. le renforcement des systèmes de la marétique et leur certification cyber avant déploiement sur ce type de navire autonome. Ce ne sera pas parfait, mais la surface d’attaque serait diminuée d’autant.
  5. la surveillance cyber de ces systèmes à distance.

A lire aussi :

Le guide du Cluster Maritime Français sur les drones maritimes.

Sources :

  • https://www.marinelink.com/news/autonomous-shipping-cyber-hazards-ahead-471587
  • Analyse personnelle

Les risques cyber liés aux moyens de positionnement par satellite

Actualités, Les risques

Contexte

Aujourd’hui, le coût modeste (quelques dizaines d’euros pour un récepteur de base), la miniaturisation et la grande disponibilité des récepteurs GPS nous permettent de penser que ce réseau nous est toujours acquis. Ces facilités ont aussi permis le développement du GPS dans de nombreux secteurs d’activités dont il était auparavant absent (on peut penser au secteur médical, au suivi des animaux de compagnie, le sport, l’agriculture, les… tondeuses domestiques, la photographie et les grues portuaires (sur ce sujet, lire aussi cet article…)). A tel point qu’il est difficile de donner un chiffre précis sur le nombre de récepteurs GPS de par le monde.

Ce qui est parfois oublié, c’est que le GPS n’est pas qu’une histoire de positionnement. Avec positionnement de précision, le GPS apporte aussi des informations horaire de grande précision. Ainsi, de nombreux pans de l’industrie reposent, parfois sans le savoir, sur la technologie GPS comme information de temps. Cette information de temps sera aussi de plus en plus importante avec l’arrivée de technologies comme la 5G qui nécessiteront une grande précision d’horloge.

Cependant, cette facilité d’acquisition de récepteurs GPS et le développement de la radio logicielle ont facilité le développement de solutions low cost de leurrage et de brouillage GPS : les techniques qui étaient auparavant uniquement accessibles au gouvernement se retrouvent aujourd’hui sur YouTube et le matériel sur Amazon pour quelques centaines d’euros. Résultat : le nombre de cas de leurrage ou de brouillage GPS augmente (voir ici pour quelques exemples) et les contre-mesures tardent à arriver.

GPS et monde maritime

Avec l’aviation, le secteur maritime est probablement un des secteurs le plus dépendant à la navigation par satellite (Global Navigation Satellite Systems, GNSS)). Le secteur est devenu d’autant plus dépendant que, face au caractère pratique des systèmes GNSS, il a abandonné progressivement les solutions historiques de positionnement hauturier, notamment celles liées à la radionavigation. Ce constat est notamment lié aux conventions SOLAS de l’IMO qui imposent le transport d’un récepteur GNSS par tout navire soumis à cette convention. Si 87% des navires marchands disposent d’un récepteur GNSS, c’est aussi l’industrie du nautisme et de la pêche qui assurent une croissance forte du secteur. Les systèmes GNSS se devenus le mécanisme par défaut d’élaboration de la position, de la vitesse et du cap du navire, remplaçant parfois d’autres équipements traditionnels (loch, compas), le tout étant fusionné dans des systèmes de cartographie type ECDIS (Electronical Chart Display Information System) et diffusé par AIS vers les autres navires (lire cet article récent sur un exemple dans le port de Shangaï).

En 2017, une étude mandatée par le gouvernement du Royaume-Uni évaluait l’impact financier sur l’économie maritime d’une perte globale de GNSS pendant 5 jours à 1,1 milliard de livres ! Ce chiffre s’explique notamment par l’impact sur le débarquement des containers dans les ports et la dépendance, déjà mentionnée supra, des grues de débarquement aux systèmes de positionnement par satellite et donc à l’incapacité durant cette période d’assurer l’embarquement et le débarquement de containers. L’impact lié au secteur maritime est cependant plus important, avec notamment des risques réels liés aux systèmes de télécommunication ou encore aux systèmes d’horodatage. La véritable difficulté étant effectivement la mesure de l’impact : on imagine mal réaliser un exercice – réaliste – de leurrage ou de brouillage GPS sur un port en activité.

Le monde maritime se veut cependant résilient : à bord, les équipages doivent pouvoir trouver une solution de contournement, comme le retour à des systèmes de navigation plus traditionnels, mais qui deviennent de moins en moins appris et pratiqués de manière régulière (quoique…). Face aux risques liés aux systèmes GNSS, l’US Navy est revenue en arrière (comme pour les écrans tactiles en passerelle) en réintégrant la navigation astrale qu’elle avait abandonné depuis les années 2000. Autre impact : si la position GNSS est indisponible, les impacts sur d’autres systèmes dépendant de la position (AIS, par exemple) et de l’heure (systèmes synchronisés par NTP) sont aussi importants : l’information de position des navires sur les ECDIS ne sont plus exactes, ce qui peut engendrer de véritables risques de collision ou d’échouage.

Contre-mesures

Comment prémunir toute tentative de leurrage ou de brouillage d’un système GNSS ?

  1. La dépendance des installations et de l’activité au GNSS (position ET système d’horloge) doit être clairement établie. La menace pouvant évoluer suivant la position du navire, certaines zones sont plus soumises à des risques que d’autres (par exemple les zones de conflit).
  2. Surveiller attentivement les sites d’alerte (les alertes de dysfonctionnement, de leurrage et de brouillage peuvent aussi être diffusées par Standard C, Avurnav ou NAVTEX, mais parfois trop tard).
  3. Envisager l’emport de systèmes de positionnement alternatifs (par exemple Glonass et GPS ou Galileo et GPS).
  4. Prendre en compte l’absence de positionnement dans les plans de continuité et de reprise d’activité (PCA/PRA).
  5. S’assurer que les équipages (et les armateurs et les ports) soient sensibilisés sur le sujet et sachent détecter, réagir et alerter en cas de dysfonctionnement d’un GNSS.
  6. Utiliser certaines antennes, comme les antennes CRPA, pour se prémunir des tentatives de brouillage. Elles commencent à être de plus en plus nombreuses sur le marché. Voir cet article de recherche et celui-ci sur leurs performances (le premier doc est marqué “propriétaire et confidentiel”, mais est indexé par les moteurs de recherche. Oups.)

Ah oui, j’ai parfois eu quelques questions sur “cyber/pas cyber” le risque lié au leurrage / brouillage GNSS. A partir du moment où cela peut avoir un impact sur un système d’information (en l’occurrence, l’ECDIS ou un système nécessitant une horloge précise), je m’y intéresse. Comme pour un incendie dans un datacenter 😉

Sources :

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

Actualités

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.

Hack.lu 2018 : comment pirater un yacht

Actualités

Cette vidéo  été tournée dans le cadre de la conférence bien connue hack.lu 2018 au Luxembourg. En première partie, Stephan Gerling y présente sa vision de la marétique et évoque rapidement les services type GPS et AIS. Il s’intéresse ensuite à la connectivité terre/navire, notamment satellitaire. Puis, il démontre les vulnérabilités de conception d’une interface de contrôle d’un routeur “naval”. L’interface de gestion se connecte en FTP au routeur naval, et les identifiants/mots de passe sont stockés en clair, révélant ainsi rapidement les identifiants WLAN du système.

Il évoque ensuite les vulnérabilités liées à la prise en main à distance de systèmes : les industriels/maintenanciers disposent fréquemment d’une capacité d’intervention à distance et, là encore, les identifiants sont stockés en clair dans le logiciel, qui est disponible librement sur Internet : pas très difficile de les trouver, surtout quand les outils utilisés (Winbox) sont vulnérables. Stephan a bien fait les choses, en informant le fabriquant des vulnérabilités constatées. Elles ont été corrigées (mais pas très bien, vous le verrez) par le constructeur. Par ailleurs, si la politique de maintenance n’est pas efficace, il est fort probable que les versions vulnérables demeurent un certain temps.

Il fait ensuite la preuve d’une autre vulnérabilité sur un système d’accès à distance à l’interface de gestion d’un modem satellite. Là encore, les mots de passe sont stockés en clair dans l’interface d’administration du modem… un simple tour sur Shodan permet d’identifier les navires vulnérables.

Rien de très très neuf, mais cette vidéo, qui fait suite à celle de Derbycon 2018, montre le regain d’intérêt du monde cyber pour la marétique.