Intégrer des contrôles de sécurité des logiciels dans le processus d'achat
Consacrer quelques heures à la diligence raisonnable pour évaluer un logiciel en vue de son achat sera moins coûteux que de faire le ménage après un incident.
Peiter « Mudge » Zatko, l'ancien directeur général et chercheur en chef de L0pht Heavy Industries, un fameux groupe de hackers spécialiste en sécurité informatique, qui a également travaillé dans l'industrie et pour le gouvernement américain au cours des vingt dernières années, compare l'achat d'un logiciel à celui d'une voiture. Selon lui, de la même manière que l'on n'achète pas une voiture sans ceinture de sécurité, sans pédale de frein, en se basant uniquement sur la puissance du moteur, il est indispensable avant tout achat de logiciel de vérifier certains éléments de sécurité de base. Et ce principe doit faire partie du cycle d'achat de l'entreprise. Cette vérification ne nécessite pas non plus beaucoup de temps ni de main-d'oeuvre. La recherche des indicateurs de sécurité de base dans les binaires de logiciels est aussi simple que l'exécution de scripts open-source existants sur les binaires en question. Même si l'opération ne permet pas une analyse complète du logiciel, elle permettra de savoir si l'éditeur du logiciel s'est donné la peine de faire le strict minimum. « Et si ce n'est pas le cas, c'est un énorme signal d'alerte », a déclaré M. « Mudge ».
« Il est fondamental que ces contrôles soient réalisés par les deux parties », a encore déclaré Peiter Zatko. Ce qui signifie qu'avant l'achat d'un logiciel, une entreprise devrait effectuer les mêmes contrôles de sécurité que ceux que l'éditeur devrait réaliser avant de lancer son produit. « C'est exactement comme si l'on s'assurait qu'une voiture était bien équipée de ceintures de sécurité et d'une pédale de frein. Bien sûr, ces vérifications doivent être faites par l'éditeur avant la commercialisation de son produit », a-t-il ajouté. « Mais le consommateur est également responsable s'il n'a pas pris la peine de vérifier par lui-même, puisqu'il n'existe pas de réglementation en matière de sécurité des logiciels ». Caveat emptor - la règle selon laquelle seul l'acheteur est responsable de son achat - s'applique en particulier aux entreprises qui ont les ressources nécessaires pour effectuer un minimum de diligence raisonnable.
Qu'est-ce qu'un « drapeau de sécurité » ?
La plupart des programmes que l'on télécharge et que l'on installe sur un ordinateur portable sont écrits en C ou C++ et transformés par un compilateur en instructions lisibles par la machine. Les compilateurs C/C++ comportent des « drapeaux » de sécurité optionnels - des arguments de ligne de commande que les ingénieurs en développement de logiciels transmettent au compilateur - qui rendent le piratage de logiciels beaucoup plus difficile. Un exemple courant est celui de l'ASLR (Address Space Layout Randomization). Mis en oeuvre il y a plus de dix ans, il permet de prévenir les attaques par débordement de mémoire tampon. Le DEP (Data Execution Prevention) - également connu sous le nom de No-Execute (NX) - et le Guard Stack (GS), mieux connu sous le nom de stacks canaries, empêchent également les débordements de mémoire tampon. Même si des techniques avancées ont été développées pour contourner les protections ASLR, le DEP et les stacks canaries, leur désactivation est rarement justifiée. L'absence de ces protections est une alerte claire pour l'acheteur potentiel. Il doit comprendre que l'éditeur « ne se soucie pas de la sécurité et qu'il n'a même pas pris la peine d'essayer ».
Voici un exemple d'exécution du script checksec sur le client Zoom Linux pour vérifier la présence de drapeaux de sécurité :
Exécution de checksec sur le client Zoom Linux (Crédit : Peiter Zatko)
À son crédit, Zoom a rapidement ajouté ces drapeaux de sécurité à son binaire Linux en réponse au tweet de « Mudge ». Une semaine plus tard, le 19 avril, voilà ce l'on pouvait voir :
Résultats du Checksec après l'ajout de drapeaux de sécurité par Zoom. (Crédit : J.M Porup)
Donc, le client Zoom Linux est désormais sécurisé à 100%... N'est-ce pas ? Il faut se réjouir du fait que Zoom prenne la sécurité au sérieux. Mais il ne faut pas que la protection de la sécurité s'arrête là. « Ça, c'est le strict minimum », a encore déclaré Peiter Zatko. Ce dernier fait remarquer que le Cyber Independent Testing Laboratories (Cyber ITL) avait découvert de sérieux problèmes de sécurité indétectables par les checksecs, y compris un usage intensif d'appels de fonctions connues et non sécurisées. Doit-on comprendre qu'en théorie, un éditeur de logiciels pourrait faire le strict minimum et ne pas se soucier du reste ? Oui, mais même si cela se produisait, ce serait quand même un pas en avant et pourrait être une première étape vers un renforcement de la sécurité et une évolution dans la culture d'ingénierie logicielle de l'entreprise.
Comment vérifier l'existence de drapeaux de sécurité
Des outils open-source comme checksec, winchecksec et otool permettent de vérifier rapidement la présence de ces drapeaux de sécurité. Checksec, l'outil utilisé dans les captures d'écran ci-dessus, vérifie les binaires Linux. Un outil similaire appelé winchecksec, effectue les mêmes contrôles de sécurité sur les binaires Windows. L'usage de winchecksec avec le binaire Windows Zoom a donné les mêmes résultats et a repéré les mêmes absences de drapeaux de sécurité de base. Contrairement à Linux, Zoom sur Windows fonctionne à partir d'un répertoire de fichiers exécutables (.exe) et de bibliothèques de code (.dll) compilés. Winchecksec a révélé un manque équivalent d'indicateurs de sécurité à la compilation pour tous les fichiers testés.
Exécution de winchecksec sur le client Zoom Windows. (Crédit : J.M Porup)
« Des outils open-source qui examinent de plus près la sécurité des binaires des logiciels compilés sont en cours de développement », a expliqué « Mudge ». Depuis plusieurs années, ce dernier développe chez Cyber ITL des outils avancés pour vérifier la sécurité des logiciels binaires à l'échelle. Il espère livrer bientôt ces outils en open source, mais il rappelle que des outils existants comme checksec et winchecksec sont plus que suffisants pour vérifier les bases.
Diligence des entreprises lors de l'achat
Le degré de diligence dont font preuve les entreprises pour vérifier la sécurité des logiciels lors de l'achat varie considérablement. Les banques ont la réputation d'être particulièrement exigeantes sur la sécurité et elles consacrent le temps et l'argent nécessaires pour cela. D'autres secteurs verticaux négligent totalement d'effectuer des contrôles de sécurité des logiciels avant l'achat. C'est souvent le fait d'un défaut d'engagement de la part des dirigeants. Dans une grande entreprise, les équipes chargées des achats et de la sécurité ont tendance à être si éloignées les unes des autres qu'il devient difficile pour les deux départements de travailler ensemble. Mais, si une entreprise n'arrive pas à assigner un stagiaire chargé de la sécurité pour effectuer ces contrôles de sécurité de base pendant quelques heures, elle peut craindre des conséquences catastrophiques. « Toute entreprise devrait inclure des mesures de sécurité simples dans son processus d'évaluation et d'achat de produits », a fortement conseillé Peiter Zatco.
