13/05/2020, par J.M. Porup, CSO (adaptation Jean Elyan), Scurit, 1128 mots
Passer quelques heures en due diligence pour évaluer un logiciel avant son achat coûte moins cher que de le nettoyer après un incident.
Paint Mudge Zatko, l’ancien directeur général et chercheur principal de L0pht Heavy Industries, un célèbre groupe de hackers spécialisés dans la sécurité informatique, qui ont également travaillé dans l’industrie et pour le gouvernement américain au cours des vingt dernières années, le compare à l’achat de logiciels appartenant à une voiture. Selon lui, tout comme on n’achète pas de voiture sans ceinture de sécurité, sans pédale de frein, basée uniquement sur la puissance du moteur, il est essentiel pour tout achat de logiciel d’avoir 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 ou de main-d’œuvre. Trouver des indicateurs de sécurité de base dans les binaires logiciels est aussi simple que d’exécuter des 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 vous permettra de savoir si l’éditeur du logiciel a pris la peine de faire le strict minimum. Et sinon, c’est un drapeau rouge standard, a déclaré Mudge.
Il est essentiel que ces contrôles soient effectués par les deux parties, a déclaré Peiter Zatko. Cela signifie qu’avant d’acheter un logiciel, une entreprise doit effectuer les mêmes contrôles de sécurité que l’éditeur avant de lancer son produit. C’est comme s’assurer qu’une voiture est équipée de ceintures de sécurité et d’une pédale de frein. Bien entendu, ces vérifications doivent être effectuées par l’éditeur avant de mettre son produit sur le marché, a-t-il ajouté. Mais le consommateur est également responsable s’il n’a pas pris la peine de se vérifier, car il n’y a pas de règles de sécurité des logiciels. La réserve Emptor – la règle selon laquelle seul l’acheteur est responsable de son achat – s’applique notamment aux entreprises qui disposent des ressources nécessaires pour effectuer un minimum de due diligence.
Qu’est-ce qu’un indicateur de sécurité 頻?
La plupart des programmes que vous téléchargez et installez sur un ordinateur portable sont écrits en C ou C ++ et convertis en instructions lisibles par la machine par un compilateur. Les compilateurs C / C ++ ont des indicateurs de sécurité facultatifs – des arguments en ligne de commande que les ingénieurs de développement logiciel transmettent au compilateur, ce qui rend les logiciels de piratage beaucoup plus difficiles. Un exemple bien connu est celui de la randomisation de la disposition de l’espace d’adressage (ASLR). Il a été mis en œuvre il y a plus de dix ans et aide à prévenir les attaques dues à une mémoire tampon surchargée. DEP (Data Execution Prevention) – également appelé No-Execute (NX) – et Guard Stack (GS), communément appelé piles de canaris, empêchent également les débordements de tampon. Même si des techniques avancées ont été développées pour contourner les protections ASLR, le DEP et piles de canarisleur désactivation est rarement justifiée. L’absence de ces protections est un avertissement clair pour l’acheteur potentiel. Il doit comprendre que l’éditeur ne se soucie pas de la sécurité et n’a même pas pris la peine de l’essayer.
Voici un exemple d’exécution de script checksec sur le client Zoom Linux pour vérifier la présence d’indicateurs de sécurité:
Exécution de checksec sur le client Zoom Linux (Crdit: Peiter Zatko)
à son crédit, Zoom a rapidement ajouté ces indicateurs de sécurité au binaire Linux en réponse au tweet de Mudge. Une semaine plus tard, le 19 avril, nous avons vu ce qui suit:
Résultats Checksec après l’ajout de drapeaux de sécurité par Zoom. (Crédit: J.M Porup)
Ainsi, le client Zoom Linux est désormais 100% sécurisé … non? Nous devrions être heureux que Zoom prenne la sécurité au sérieux. Mais la sécurité ne doit pas s’arrêter là. a, c’est le strict minimum, a répété Peiter Zatko. Ce dernier a noté que Cyber ITL (Cyber Independent Testing Laboratories) avait découvert de graves failles de sécurité indétectables par les services de contrôle, notamment une utilisation intensive des appels de fonction connus et non sécurisés. Faut-il comprendre qu’un éditeur de logiciels pourrait théoriquement faire le strict minimum et ne pas avoir à se soucier du reste? Oui, mais même si c’était le cas, ce serait toujours un pas en avant et une première étape dans le renforcement de la sécurité et l’évolution de la culture d’ingénierie logicielle de l’entreprise.
Vérifier l’existence de drapeaux de sécurité
Des outils open-source tels que checksec, winchecksec et otool vous permettent de vérifier rapidement la présence de ces indicateurs 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 vérifications de sécurité sur les binaires Windows. L’utilisation de winchecksec avec le binaire Windows Zoom a donné les mêmes résultats et répété la même absence d’indicateurs de sécurité de base. Contrairement à Linux, Zoom sur Windows fonctionne à partir d’un dossier de fichiers exécutables (.exe) et de bibliothèques de codes compilés (.dll). Winchecksec a révélé un manque équivalent d’indicateurs de protection de compilation pour tous les fichiers de test.
Winchecksec s’exécute sur le client Zoom Windows. (Crédit: J.M Porup)
Mudge dit que des outils open source sont en cours de développement qui examinent de plus près la sécurité des fichiers binaires dans les logiciels compilés. Ce dernier développe depuis plusieurs années des outils avancés chez Cyber ITL pour vérifier la sécurité des logiciels binaires à l’échelle. Il espère livrer bientôt ces outils en open source, mais il se souvient que les outils existants comme checksec et winchecksec sont plus que suffisants pour vérifier les bases de données.
Due diligence commerciale à l’achat
Le niveau d’engagement utilisé par les entreprises pour vérifier la sécurité des logiciels à l’achat varie considérablement. Les banques sont connues pour être particulièrement exigeantes en matière de sécurité et y consacrent le temps et l’argent nécessaires. D’autres secteurs verticaux échouent complètement à effectuer des vérifications de sécurité des logiciels avant l’achat. C’est souvent le résultat d’un manque d’engagement de la part des dirigeants. Dans une grande entreprise, les équipes achats et sécurité sont tellement éloignées qu’il devient difficile pour les deux départements de travailler ensemble. Mais si une entreprise ne désigne pas de stagiaire en sécurité pour effectuer ces vérifications de sécurité de base pendant quelques heures, elle pourrait craindre des conséquences catastrophiques. Chaque entreprise doit inclure des mesures de sécurité simples dans son processus d’évaluation et d’achat de produits, conseille vivement Peiter Zatco.