Le chercheur en sécurité Alex Birsan a pu « pirater » les chaînes d’approvisionnement de 35 grandes sociétés mondiales, soulevant de nombreuses questions sur les conséquences potentiellement ravageuses de cette action. En revenant sur l’affaire avec trois experts en cybersécurité, Jérôme Thémée, David Bizeul et Fred Raynal, nous allons voir que la situation, bien que problématique, ne doit pas être source de panique pour le grand public.
2 « J'aime »
Le développement « rapide » (pour ne pas dire low-cost) a ses inconvénients.
Ce qui est étonnant ici, c’est que de grands groupes y ont recours… aucune dépendance ne devrait être mise à jour sans vérifier son code.
J’irai même jusqu’à dire qu’il ne devrait y avoir aucune connexion extérieure et que les dépendances vérifiées, soient rapatriées complètement en interne (et modifiées si besoin).
Evidemment, on en revient toujours au même, il faut plus de moyens consacrés au dév…
-
Développement rapide =/= de développement low cost
-
Tout le monde y a recours, les TPE, les PME, les gros groupes, les banques, même dans certains milieux sensibles comme le spatial et la défense.
-
Les codes sont vérifiés, parfois même les librairies et toutes les dépendances, mais pas systématiquement. Sur des « gros projet », c’est juste impossible.
Quand vous passer votre voiture au contrôle technique, vous ne vérifiez pas l’usure de toutes les vis de votre véhicule. Si c’est bien conçu et qu’une vis pète, une partie est compromise mais l’intégrité de l’ensemble n’est pas atteinte. C’est pareil dans l’IT moderne, on isole au maximum. -
Juste impossible aujourd’hui. Il a même des flux qui gèrent de l’information classé comme confidentiel défense qui sont ouvert sur le net (avec chiffrage de bout en bout, pare feu, vlan, vpn, ipsec, ids/ips etc). Il faut arrêter de rêver, on ne peut pas créer un internet à l’échelle planétaire physiquement séparé pour chaque entreprise.
-
Vous pouvez rapatrier toutes les dépendances comme ça se fait régulièrement en zone classé SD ou CD, mais dans ce cas-là, vous devez vous taper le maintien de ces dépendances, au strict minimum tous les correctifs de sécu …
Alors dans le monde réel des entreprises privées, c’est très rarement le cas.
Seules quelques grosses boites privées en ont les moyens, ne le font pas systématiquement pour des raisons pratiques et économiques.
On n’a ni le temps, ni l’argent de réinventé la roue à chaque projet, c’est d’ailleurs le but même de ce système, et du devops de manière générale.
Le risque de piratage d’un des ces gestionnaires est suffisamment rare et peu impactant pour être négligeable face à l’immense gain de temps et d’argent qu’ils offrent.
C’est souvent beaucoup plus facile (et c’est le cas dans le monde réel), de contrôler les entrées/sorties plutôt que de contrôler tout ce qui passe à l’intérieur.
J’aimerai vivre dans votre monde utopique tout rose mais ce n’est malheureusement pas la réalité.
2 « J'aime »
L’ère du low/no code va t’elle encourager la cybermalveillance en utilisant justement des portes d’entrée dérobées « communes » ou au contraire va t-elle permettre une surveillance accrue de failles qui seront « en théorie » moins nombreuses ? Ca laisse songeur…
1 « J'aime »
Très éclairant, merci !
D’accord pour ne pas réinventer la roue, mais avouons aussi que parfois des sites et applications impotent des bibliothèques pour une seule fonctionnalité… Il faudra peut-être y repenser alors…
Cette expérience a le mérite de rappeler (même si d’aucuns pensent que c’est une évidence) qu’on est sur un principe de confiance et donc pas de risque zéro. Il y a donc de facto une responsabilité à utiliser une bibliothèque et à la mettre ou non à jour.
1 « J'aime »
Depuis les révélations de Snowden, la question que je me pose après avoir lu cet article (très clair et bien écrit au demeurant) est quel est le niveau actuel d’installation de backdoors dans les codes publics en provenance d’agences étatiques …
3 « J'aime »
Il serait intéressant d’avoir aussi un dossier sur le dll spoofing, c’est dans le principe un peu similaire, une attaque par une entrée non validée (et encore plus difficilement validable).
Ca me fait super flipper quand je vois les IT de mes clients nous refuser nos dll pour les remplacer par les leurs « plus sûres » mais après analyse avec des provenances pour le moins douteuses (non signées ou signatures non valides par exemple)…
1 « J'aime »
Donc si je comprends bien, moi le néophyte profane dans le développement et sécurité, pour boucher les failles il faut mettre a jour mais pour éviter d’être potentiellement infecté, il faut que j’évite de mettre à jour.
?
Pour ma part, je pense qu’il y a des solutions relativement simples à ces problèmes.
D’abord un constat, c’est que ce genre de problème est rarement susceptible de venir des auteurs des logiciels eux même. Car ceux ci jouent très gros sur leur réputation et ont investi des années de travail. Et le code qu’ils acceptent de la part de contributeurs est dans la plupart des cas très bien vérifié.
Le problème viens plutôt de dépôts de code tiers. Encore plus, quand n’importe qui peut téléverser du code et/ou modifier un peu le nom d’un projet pour tenter de se faire passer pour l’original, voir utiliser le nom d’un projet avant les vrais auteurs d’un soft.
Par contre ce que dit le gars n’est pas totalement vrai. Parce que oui, il existe des dépots qui sont garantis sûr. Par exemple, les grandes distributions Linux utilisent des signatures électroniques pour les paquets.
Tenter de corrompre ce genre de dépôt ne fonctionne pas car le gestionnaire de paquet détectera le problème immédiatement.
Reste les personnes qui les alimentent, qui sont des volontaires qui ont montré qu’ils sont digne de confiance. Mais on peut imaginer qu’infiltrer une organisation n’est pas totalement impossible pour qui voudrait s’en donner les moyens.
A mon sens, la solution est d’impliquer beaucoup plus les auteurs des logiciels dans la distribution des logiciels, d’éviter tout tiers et d’utiliser une signature électronique de bout en bout qui garantirait qu’un logiciel est à 100% issu de son auteur sans modification possible par un tiers en cours de route.
Tu n’as pas bien compris non.
Il faut mettre à jour, mais il faut absolument que tu sois sûr de la « propreté » de la source…
La plupart des projets open-source te donnent un hash pour vérifier que ce que tu télécharges, est bien ce que tu devrais télécharger, car ils partent du principe que n’importe-quel serveur (repo) peut être compromis, et la base doit être la méfiance, pas la confiance.
1 « J'aime »
Oui mais alors comment être sûr que la source est sûre ?
C’était en ce sens que je disais faire et ne pas faire en même temps pour mon iPhone, mon Windows 10, pour les androids etc… où il n’y a pas d’open sources 
En tout cas merci pour tes précisions