Dans un récent billet de blog de la Fondation Linux intitulé « Preventing Supply Chain Attacks like SolarWinds », le directeur de la sécurité de la chaîne d’approvisionnement open source de la fondation, David A. Wheeler, a insisté catégoriquement sur la nécessité pour les développeurs de logiciels d’adopter les recommandations de sécurité du LF pour prévenir des attaques encore pires contre la sécurité des données du gouvernement et de l’entreprise à la suite de la violation rampante des données.
Le poste de Wheeler est opportun et rempli d’informations pour rendre plus difficile pour les pirates d’exploiter les futurs systèmes dont nous dépendons tous. Il comprend 11 recommandations de la Fondation Linux, y compris la façon dont les organisations peuvent durcir leurs environnements de construction contre les attaquants, la nécessité de commencer à se déplacer vers la mise en œuvre, puis nécessitant des builds reproductibles vérifiés, et la pratique de changer les outils et les interfaces afin que les vulnérabilités involontaires soient moins probables.
Selon Wheeler, SolarWinds a rencontré certaines des mesures défensives de la fondation. Aucun d’entre eux n’a empêché l’attaque réussie solarwinds, at-il dit. Plus de durcissement logiciel est nécessaire.
Le logiciel SolarWinds Orion est propriétaire. Alors, comment les méthodes de codage open source peuvent-elles contribuer à créer une meilleure sécurité ?
SolarWinds a suivi quelques mauvaises pratiques, telles que l’utilisation du protocole FTP non sécurisé et la divulgation publique des mots de passe, ce qui peut avoir rendu ces attaques particulièrement faciles, Wheeler a offert dans son blog Linux Foundation.
« La violation SolarWinds n’a pas fourni aux professionnels de l’informatique avec de nouvelles idées techniques, mais il a fourni une nouvelle urgence pour contrer ce genre d’attaque, at-il dit LinuxInsider.
Les cyberattaques exploitent généralement les vulnérabilités involontaires dans le code. La plupart des autres attaques, du moins dans les logiciels open-source, impliquent une tactique appelée typosquatting. Cette approche crée du code malveillant avec un nom volontairement similaire à un vrai programme, at-il expliqué.
La violation SolarWinds a fait quelque chose de différent. Il a subverti un environnement de construction, qui jusqu’à présent a été un type moins commun d’attaque, at-il noté.
« Moins de professionnels de la sécurité se sont concentrés sur la lutte contre ce genre d’attaque. Cela pourrait changer à l’avenir, d’autant plus que presque toutes les mesures de sécurité typiques ne contredront pas ce genre d’attaque », a-t-il déclaré.
Le coup dans l’assaut de SolarWinds
De nombreux organismes gouvernementaux américains et de nombreuses organisations privées qui utilisent le logiciel SolarWinds Orion ont été gravement compromis. Il s’agissait d’un ensemble très dangereux de compromis de la chaîne d’approvisionnement que la communauté des technologies de l’information et la communauté open-source doivent apprendre et prendre des mesures, selon la Fondation Linux.
La Federal Cybersecurity and Infrastructure Security Agency (CISA) a publié une directive d’urgence 21-01 déclarant qu’Orion était exploitée, qu’elle avait un fort potentiel de compromis et qu’elle avait de graves répercussions sur des organisations entières lorsqu’elle était compromise. Plus les gens regardent, plus ils trouvent de choses pires. Wheeler croit qu’un compromis de deuxième et troisième malware a été identifié à Orion.
La plate-forme Orion est une plate-forme évolutive de surveillance et de gestion de l’infrastructure. Il aide les services informatiques à simplifier l’administration des environnements sur place, hybrides et logiciels en tant que service (SaaS).
Les enquêteurs ont trouvé des logiciels malveillants appelés Sunspot qui ont regardé le serveur de construction pour construire des commandes. Quand il a trouvé de telles commandes, le malware silencieusement remplacé les fichiers de code source à l’intérieur de l’application Orion avec des fichiers qui ont chargé le malware Sunburst.
Le compromis de SolarWinds Orion par Sunspot n’est pas le premier exemple de ce genre d’attaques. Pourtant, il a démontré à quel point ils peuvent être dangereux quand ils compromettent les logiciels largement utilisés, a noté Wheeler.
Analyse approfondie
Compte tenu de l’ampleur du piratage de SolarWinds, LinuxInsider a demandé à Wheeler de plonger plus profondément dans la façon dont les normes de sécurité de la chaîne d’approvisionnement pourraient bénéficier des dernières recommandations de la Fondation Linux.
LinuxInsider: La violation SolarWinds aurait-elle été moins possible si le logiciel était open source ?
David A. Wheeler: La nature source fermée a probablement rendu la violation plus difficile à détecter, mais tous les logiciels sont vulnérables à ce genre d’attaque. Les développeurs de logiciels modifient le code source pour maintenir le logiciel. Les utilisateurs de logiciels installent généralement des logiciels générés à partir du code source. La conversion du code source en un paquet exécutable est appelée « bâtiment » et le bâtiment fonctionne sur un « environnement de construction ».
Dans ce cas, un attaquant a subverti l’environnement de construction, de sorte que le code source vu par les développeurs était très bien, mais le logiciel installé final a été modifié sans le savoir.
OSS est beaucoup plus facile à rééder une build qui peut détecter des subversions. Le code source proche a ajouté des défis techniques et juridiques à leur détection. OSS a un avantage potentiel, mais les développeurs doivent agir pour tirer parti de ce potentiel.
Qu’est-ce qui aurait pu empêcher l’intrusion?
Wheeler: La meilleure façon est ce qu’on appelle une construction reproductible vérifiée ou une construction déterministe. Il s’agit d’un processus qui produit exactement les mêmes résultats à partir d’entrées identiques, même lorsqu’il est géré par différentes organisations. Il a été vérifié par des organisations indépendantes. Il rend la subversion de code beaucoup plus difficile parce qu’un attaquant doit alors subvertir plusieurs organisations indépendantes, et même si cela se produit plus tard la détection est beaucoup plus facile. D’autres techniques sont beaucoup plus faibles.
Ces attaquants semblent avoir été bien nants. Il est dangereux de dépendre d’un attaquant qui ne réussit jamais. L’examen des paquets construits peut en théorie trouver des problèmes, mais l’ampleur des programmes du monde réel rend cette analyse coûteuse, et les problèmes seront souvent manqués. Le problème a finalement été trouvé par la surveillance, mais dans ce cas, il a causé des dommages importants avant la détection.
Une construction reproductible vérifiée est semblable à une vérification financière où un vérificateur financier détermine si un résultat est correct. Le problème essentiel avec SolarWinds était qu’aucun processus indépendant vérifié le résultat de construction était correct.
Dans quelle mesure est-il pratique pour l’industrie du logiciel d’adopter cette recommandation LF?
Wheeler: Certains projets ont déjà des builds reproductibles, il est donc possible de le faire. Le projet builds reproductible a créé une version modifiée de Debian GNU/Linux (spécifiquement de bullseye) où plus de 90 pour cent des paquets sont reproductibles. Toutefois, dans la pratique, il faudra du temps pour de nombreux projets d’OSS et même plus longtemps pour de nombreux projets à source fermée.
Historiquement, personne n’a vérifié si les builds étaient reproductibles, de sorte que les projets ont accumulé de nombreuses constructions qui rendent les constructions irréproductibles. Il n’existe pas d’obstacles techniques fondamentaux; juste un grand nombre de petites choses doivent être trouvées et changées. La combinaison de tous ces petits changements demande beaucoup d’efforts dans les grands projets.
Les logiciels sources fermées ont des défis supplémentaires, tant techniques que juridiques. Contrairement à OSS, le logiciel source fermé n’est normalement pas conçu pour être reconstruit par d’autres. Les développeurs de logiciels à source fermée devront investir des efforts importants juste pour que d’autres puissent le reconstruire. De plus, leurs modèles d’affaires dépendent généralement de restrictions légales quant à savoir qui a accès au code source.
Ce qu’il faut, ce sont des accords contractuels spéciaux pour partager le code qui n’ont pas été faits auparavant. Mais bien qu’il soit plus difficile de le faire avec des logiciels à source fermée, ces défis sont surmontables.
Que prendra son adoption?
Wheeler: Demande des clients! Tant que les clients acceptent fadement les boîtes noires et les produits sans builds reproductibles vérifiées, les développeurs n’ont aucune raison de changer.
Un lent éloignement des vraies boîtes noires est en cours. Les clients disent souvent qu’ils n’ont pas besoin de savoir comment quelque chose fonctionne, mais les vraies boîtes noires signifient que les clients prennent un montant inconnu de risque. De nombreux fournisseurs de logiciels à source fermée (comme Microsoft) ont maintenant des mécanismes pour fournir au moins une certaine visibilité au code source pour aider les clients à mieux gérer leurs risques. Les logiciels open source, bien sûr, permettent à n’importe qui de voir le code.
Nous sommes à un point intéressant pour les builds reproductibles. Jusqu’à présent, certains projets y ont travaillé, même sans la demande évidente des clients. Ajoutez à cela la demande et une augmentation rapide de sa disponibilité se produira.
Quel a été l’impact de la pratique open-source de réutilisation du code ?
Wheeler: Le public ne sait pas exactement comment l’environnement de construction de SolarWinds a été violé. Nous savons que c’était un système Windows. Dans un grand sens, cela n’a pas d’importance. Les défenses peuvent être très bonnes, mais il n’est pas sage de supposer qu’un système ne peut jamais être violé. Une bonne sécurité implique non seulement une bonne prévention, mais aussi la détection et la récupération.
Les environnements de construction futurs seront également violés. Nous devrions essayer de durcir les environnements de construction contre les attaques, mais nous devrions également développer des mécanismes de détection et de récupération afin que toute violation ne conduise pas aux dommages causés par cette violation.
Dans quelle mesure l’instauration d’une facture logicielle de matériaux (SBOM) est-elle viable pour prévenir la typosquattage, comme l’a suggéré le LF?
Wheeler: Les SBOM peuvent aider à contrer le typosquatting. Il est facile pour les développeurs de regarder un nom et de lire ce qu’ils s’attendent à ce qu’il dise, pas ce qu’il dit réellement. Les SBOM donnent une visibilité aux autres, y compris aux clients, de ce qui est contenu dans un composant, tout comme les listes d’ingrédients alimentaires expliquent ce qu’il y a dans nos aliments. Avec une liste, d’autres peuvent rechercher des composants suspects, y compris des noms qui sont similaires à des noms attendus, mais pas identiques.
Comme l’a dit louis Brandeis, juge associé à la Cour suprême, « la publicité est à juste titre saluée comme un remède aux maladies sociales et industrielles. On dit que la lumière du soleil est le meilleur des désinfectants... » 
