Support technique
Documentation
Connexion
Nous contacter
TuxCare Blog
Dans une émission de télévision fictive diffusée depuis l'année dernière, un espion est tombé en disgrâce en oubliant des documents secrets dans un train public. Ces documents contenaient une liste d'espions travaillant sous couverture à l'étranger et étaient très importants.
La semaine dernière, dans un moment de "réalité imitée de la télévision", un serveur mal sécurisé appartenant à CommuteAir, une compagnie aérienne américaine, a laissé un document contenant la "No Fly List" accessible à des pirates motivés.
La liste des interdictions de vol
Parfois, les histoires sont tout simplement incroyables. La "No Fly List" est une liste de personnes auxquelles il a été interdit de prendre des vols commerciaux aux États-Unis, et elle a de sérieuses implications en matière de sécurité nationale. Je n'entrerai pas dans le détail des champs contenus dans les données, ni même ne débattrai de la justification ou non d'une telle liste, ni même de son utilité. Si ces aspects de l'histoire vous intéressent, l'article original du Daily Dot en parle en détail et constitue une lecture très intéressante.
Il est, pour le moins, croustillant de constater qu'une liste de plus de 1,5 million d'entrées a été laissée dans un endroit accessible (et, je suppose, involontairement).
La cybersécurité, mais juste un peu
Selon le rapport original du Daily Dot, la compagnie aérienne a indiqué que le serveur où le fichier était exposé était "un serveur de développement, utilisé à des fins de test" (citation de l'article du Daily Dot). Ce commentaire montre implicitement à quel point ce serveur était considéré comme moins important par rapport aux autres systèmes.
La société a également confirmé que les données étaient réelles, mais qu'elles provenaient d'une version 2019 de ladite liste des interdictions de vol.
Conformément à la réglementation en vigueur, et compte tenu de la gravité de l'événement et des ramifications potentielles en matière de sécurité, les autorités de niveau fédéral telles que la TSA, le FBI et la CISA ont été impliquées.
Si l'on regarde comment la découverte a été faite, c'est-à-dire par un pirate, il s'avère qu'elle a été identifiée lors d'une recherche Shodan sur les serveurs Jenkins - un progiciel qui automatise les processus de construction et de test dans le développement de logiciels et qui est, malheureusement, un nom familier dans les histoires courantes d'incidents de cybersécurité. Pour ceux qui ne sont pas familiers avec ce nom, Shodan est un service public qui propose des recherches de type Google pour les services Internet. Par exemple, on peut lui demander de trouver tous les serveurs de messagerie accessibles sur Internet ou tous les systèmes de bureau à distance non protégés ayant une adresse IP publique. Pour les acteurs de la menace comme pour les script kiddies, apprendre à utiliser Shodan est un cours de "hacking 101".
Il est difficile de classer correctement certains services informatiques en deux catégories clairement définies : les services "publics" et les services "privés", c'est-à-dire les services qui doivent être accessibles de l'extérieur de l'organisation, par exemple via Internet, et les services qui ne doivent être accessibles que de l'intérieur du réseau périphérique et n'ont aucun contact direct avec l'extérieur.
Cependant, Jenkins est l'un de ceux qui n'offre aucun argument. Il s'agit clairement et exclusivement d'un service d'infrastructure, utile uniquement aux développeurs, et en tant que tel, il n'aurait jamais dû être accessible par une requête Shodan. Bien que très complet, Shodan n'est pas magique - il ne peut pas trouver un serveur si ledit serveur n'est pas exposé.
Mais localiser le serveur Jenkins n'était que la première étape. Il devait y avoir une forme de partage non protégé ou non authentifié dans Jenkins où le fichier était situé. Le projet Jenkins fournit des conseils pour protéger un déploiement. Il semble que certains des conseils fournis n'aient même pas été suivis.
Alors, qu'est-ce qui aurait dû être fait différemment ?
Pour commencer, les données du monde réel ne devraient jamais être utilisées, et abusées, de cette façon. Vous n'avez pas vraiment besoin de la liste réelle sur votre système de test, juste pour vous assurer que votre logiciel peut la traiter correctement. C'est pourquoi il existe des pratiques comme le "data mocking", pour créer de "fausses" données d'apparence réelle dans ce but précis.
Ensuite, les meilleures pratiques de Jenkins auraient dû être suivies - aucun point d'accès non protégé, aucun partage, rien d'exposé.
Ensuite, les serveurs d'infrastructure n'auraient jamais dû avoir d'accès extérieur en premier lieu. Ils n'en ont pas besoin pour leur bon fonctionnement, et si des connexions extérieures réelles sont nécessaires pour tester un certain type d'intégration externe, c'est à cela que servent les tunnels ipsec.
Mais le véritable nœud du problème est que les équipes informatiques ont toujours une vision différente des systèmes "secondaires" comme ceux-ci lorsqu'il s'agit de cybersécurité. Les systèmes de première ligne, les systèmes centraux et les systèmes critiques font l'objet de toutes les attentions, mais les systèmes d'infrastructure comme celui qui fait l'objet de cette histoire et d'autres comme les serveurs d'impression, les serveurs de partage de fichiers internes et autres ne reçoivent qu'un coup d'œil de temps en temps, probablement lorsque quelqu'un se plaint d'un problème.
(Tous les serveurs sont sécurisés - sauf la boîte de Jenkins.
https://knowyourmeme.com/memes/medieval-knight-with-arrow-in-eye-slot)
Ce type d'attention différente donne lieu à des brèches dans l'armure proverbiale - et il suffit d'une petite brèche pour que tout le château s'écroule.
Tout, partout, version informatique
Sécurisez, surveillez et corrigez tous les serveurs, tout le temps, comme si des données commerciales critiques se trouvaient dans chacun d'entre eux. Cela devrait être le mantra - le seul mantra - d'une posture de sécurité moderne. Automatisez autant que possible, mais sans négliger aucun système. Ils sont tous aussi importants les uns que les autres en matière de sécurité.
Un acteur de la menace ne s'inquiétera pas vraiment s'il ne peut pas pénétrer directement dans le serveur de base de données. Tant qu'il peut d'abord pénétrer dans l'hôte de virtualisation, il n'y a qu'un pas rapide vers les données importantes.
Le chemin vers le prix n'a pas d'importance. Seule la récompense compte. C'est à l'équipe bleue de s'assurer que tous ces chemins sont bloqués et protégés correctement.
source de l'image : https://i.kym-cdn.com/entries/icons/original/000/035/146/knight.jpg
https://knowyourmeme.com/memes/medieval-knight-with-arrow-in-eye-slot
