Programmation sécurisée

Transcription

1 2.1 Programmation sécurisée Introduction à la programmation sécurisée «One of the best weapons you can have in your arsenal is clean code» -- Jim Allchin (MS - Resp. Windows Server) SDL book

2 Définitions Sûreté (reliability) d un logiciel : mesures permettant d éviter les défaillances du logiciel Sécurité (security) d un logiciel : mesures spécifiques permettant de garantir le fonctionnement prévu du logiciel contre des actes de malveillances Risque : probabilité qu un danger/menace se concrétise Bug/Bogue logiciel : erreur dans le logiciel causée par un défaut de conception, d implémentation ou de configuration Exploit : programme (souvent automatique) utilisant un bogue logiciel (une vulnérabilité) pour exécuter une action non prévue par ce dernier (déni de service, exécution de commandes, etc.)

3 Illustration Sûreté & Sécurité Exemple : protocole de transmission d information (température, pression, taux d humidité) entre deux stations de météorologie basée sur le protocole UDP Risque 1 : erreur de transmission sur la ligne (impact en intégrité) Risque 2 : malveillance sur la ligne (impact en intégrité) Quelle(s) solution(s)?

4 Motivation à la sécurité logicielle La protection de l information : Favorise l identification des données sensibles à protéger : Exemple : donnée métier, donnée personnelle, donnée du système d information, etc. Cas de la donnée à caractère personnel (privacy) : données permettant directement ou indirectement d avoir une information sur une personne physique Réglementation spécifique (cf. CNIL) Notion de «patrimoine informationnel» : ensemble des données, protégées ou non, valorisables ou historiques, d une personne physique ou morale.

5 Motivation à la sécurité logicielle La protection de l information : Précise la localisation des données : Cas de la duplication volontaire ou non des données. Exemple : poste de travail, serveur de fichiers, équipement portatif (type ordiphone), informatique en nuage (cloud) Identifie les canaux de transmission et d utilisation de l information Exemple : transport sécurisé de bout en bout / stockage sécurisé de la donnée

6 Motivation à la sécurité logicielle La protection de l information : Assure que le traitement ne réalise que les opérations demandées

7 Motivation à la sécurité logicielle La réduction des coûts (financier/humain) : moins couteux de prendre la sécurité amont sur le long terme mais la prise en compte de la sécurité a un coût initial important (phase de conception) retour sur investissement toujours difficile à justifier / à évaluer

8 Motivation à la sécurité logicielle Réduction des coûts (financier/humain) : Intègre l évolutivité de l application dès la phase de conception Exemple : changement de modèle d une application client à client/serveur. Les retours en arrière sont parfois impossibles ou nécessitent des rustines couteuses Conséquence du point précédent : maîtrise des correctifs de sécurité : moins de correctif de sécurité à appliquer

9 Motivation à la sécurité logicielle Facteur de qualité/valorisation pour une application : Prérequis à une application sécurisée : application dont le fonctionnement est toujours maîtrisé Exemple: OpenSSH Qualité et Sécurité vont généralement dans la même sens Mais la sécurité limite (bride?) la rapidité de mise en œuvre de nouvelles fonctionnalités Exemple : OpenBSD Maîtrise des évolutions : la sécurité nécessite d avoir une stratégie (même minimaliste) dans la conception d un logiciel Exemple : le socle système évolue plus rapidement que l application développée (Windows XP -> 10)

10 Motivation à la sécurité logicielle Améliore l image du logiciel : créé la confiance et l adhésion des utilisateurs argument commercial (positif ou négatif) Exemples : Microsoft : SDL Security Development Life Cycle (2006) Adobe : 2008 : 6 mois pour corriger une vulnérabilité critique découverte par 3 sociétés (indépendamment) Mars 2009: 20 jours pour corriger une vulnérabilité largement exploitée sur Internet 2012 : synchronisation des publications avec Microsoft et Google Projet «Sandboxing flash» (Safari, Chrome, ) Java : Java-0day.com OpenBSD Only two remote holes in the default install, in a heck of a long time!

11 Motivation à la sécurité logicielle Conforme à la réglementation : Reconnaissance d un certain niveau de sécurité au niveau national / international Pré requis à certaines applications : Exemple : PCI-DSS pour le paiement par carte bancaire sur Internet interdit le stockage en clair du numéro de carte bancaire Attention : exigences qui ne sont pas forcément techniques Exemple : exigence d un suivi de la sécurité (sans les spécifier) cas de la réglementation sur les jeux en ligne Exemple : exigence sur le niveau de documentation cas des premiers niveaux CC

12 Cycle de vie d une vulnérabilité Plusieurs acteurs : Chercheurs en sécurité : étudiant, groupe organisée, laboratoire de recherche, etc. Etat (Cyberdéfense) Editeur logiciel («victime» de la vulnérabilité) Exemple 1 : Microsoft, «linux», Apple, Adobe Exemple 2 : entreprise, module de société de service CERT public/privée Editeur d un produit de sécurité (exemple : éditeur d antivirus) ou éditeur concerné (Project Zero Google) Communauté : forum, mailing-list, blog, etc. Société spécialisée afin de revendre des vulnérabilités : Tiers de «confiance» Revendeur / Acheteur

13 Cycle de vie d une vulnérabilité Critère important : facilité de développement d un exploit Fenêtre d exposition : période entre la découverte de la vulnérabilité et le correctif de sécurité (exposition publique ou non) Fenêtre d exploitation active: période entre l exploitation active de la vulnérabilité et le correctif de sécurité Exploitation publique connue ou non «0 day» «Zero day time»

14 Cycle de vie d une vulnérabilité Plusieurs modes de divulgation possibles (détaillés plus loin) : secret complet d une vulnérabilité (bug secrecy) divulgation complète (full disclosure) informer les utilisateurs en même temps que l éditeur. Exemple : SMBv2 Process High exploit posté sur un blog negotiate-protocol.html divulgation responsable (responsible/vendor disclosure) informer l éditeur avant de sortir un avis public. Parfois via un intermédiaire (exemple: CERT, Zero Day Initiative) Cas des récompenses («bug bounties») : voir plus loin. approche hybride (cas Google) autre cas de plus en plus courant : exploitation active

15 Cycle de vie d une vulnérabilité Bug Secrecy La vulnérabilité est découverte, gardée secrète par l éditeur ou une communauté d intérêt : Vulnérabilité n est pas corrigée immédiatement (parfois jamais) Modèle souvent considéré comme dépassé : Difficulté à conserver un secret entre plusieurs acteurs Vulnérabilité redécouverte tôt ou tard Méthode qui n augmente pas le niveau de sécurité du produit sur le long terme

16 Cycle de vie d une vulnérabilité Bug Secrecy quelques cas où ce mode de fonctionnement est encore rencontré : Système «impossible» à mettre à jour et/ou très critique (processus industriel) Vulnérabilité critique impactant plusieurs éditeurs. Cas des failles protocolaires : Exemple 1: vulnérabilité TCP/IP Sockstress CVE Exemple 2 : vulnérabilité DNS (CVE ). Vulnérabilité retrouvée avant la divulgation

17 Cycle de vie d une vulnérabilité Responsible disclosure Découverte d une vulnérabilité Déploiement du correctif (durée indéterminée) Analyse (et utilisation?) de la vulnérabilité par l auteur Coordination de l éditeur pour une réponse à la vulnérabilité («correctif») Editeurs logiciels, CERT informés

18 Cycle de vie d une vulnérabilité Full disclosure Découverte d une vulnérabilité Déploiement du correctif (durée indéterminée) Analyse (et utilisation?) de la vulnérabilité par l auteur Coordination de l éditeur pour une réponse à la vulnérabilité («correctif») Communication publique de la vulnérabilité (détaillée ou non) Editeur logiciel informé (à ses dépens)

19 Cycle de vie d une vulnérabilité Responsible disclosure hybride Constat: certains éditeurs ont des délais de création des correctifs (exagérément) longs L auteur de la découverte de la vulnérabilité donne 60 jours à l éditeur avant de passer dans une politique de «full disclosure». Cas d une exploitation active : 7 jours Objectif : mettre la pression sur les éditeurs pour mettre à disposition un correctif de sécurité 07/rebooting-responsible-disclosure-focus.html

20 Cycle de vie de la vulnérabilité Autres cas Concours (cansecwest, ) Exploitation actives : cas des vulnérabilités découvertes «dans la nature» (très fréquent depuis 2010) Stuxnet, Affaire Aurora (Google), etc. Fuite de données : cas de Hacking Team (2015)

21 Cycle de vie de la vulnérabilité Autres cas Vente de vulnérabilités : marché des vulnérabilités Vendeur, acheteur, tiers de «confiance» Prix évolue en fonction de la demande et des technologies

22 Cycle de vie de la vulnérabilité Durée de réalisation d un correctif pour une vulnérabilité importante parfois très long : Hewlett Packard : 1132 jours IBM : 908 jours RealNetworks : 739 jours Microsoft : 587 jours Computer Associates : 541 jours Firefox : 438 jours Adobe : 396 jours Autres exemples sur ZDI :

23 Cycle de vie de la vulnérabilité Le logiciel ne contient pas toujours directement la vulnérabilité : dépendance à une bibliothèque vulnérable Exemple : liaison statique avec OpenSSL vuln. adhérence à un système d exploitation vulnérable abstraction d un périphérique vulnérable implémentation d un protocole vulnérable Exemple : WEP

24 Cycle de vie de la vulnérabilité Test et qualification du correctif par l éditeur Problème complexe surtout si l application est immergée dans un environnement hétérogène, voir modifier par un revendeur : Cas des téléphones Validation système / fonctionnelle : Tests de non-régression Incompatibilité du boggue Déploiement : manuel / automatique

25 Évolution des menaces Les techniques d exploitation des vulnérabilités se sont affinées : Windows MS08-001: Vulnérabilité du noyau Windows dans le protocole IGMPv3. Considéré comme inexploitable par Microsoft mais finalement exploité par les attaquants Vmware: CVE Élévation de privilèges sur la machine hôte Java : CVE Élévation de privilèges dans la machine virtuelle Java Stuxnet. Reprogrammation d un automate Siemens utilisé dans le domaine du nucléaire SMM. Blackhat 2015

26 Évolution des menaces Attaquants (très) créatifs L attaquant doit trouver un chemin d attaque Le défenseur doit couvrir l ensemble des chemins possibles vs

27 Évolution des menaces Périmètre de recherche des vulnérabilités des logiciels plus vaste : Plugin des navigateurs Internet : Exemple : Adobe Acrobat Reader - CVE Routine de décodage des fichiers : Exemple : Archive ZIP de l explorateur - MS Application Web: attaque directement l application (surtout si elles sont développées pour un besoin particulier) Emulation / Virtualisation Smartphone : jailbreaking Cloud Objet connecté Les attaquants recherchent les vulnérabilités là où les protections sont les plus faibles. Exemple : Windows Server 2012 / Applications tierces

28 Évolution des menaces Industrialisation de la recherche de vulnérabilités : Pratique lucrative Cyber crime / Cyber warfare Aspect stratégique ex: données d une application ministérielle Explosion des outils «automatiques» de recherche de vulnérabilités application accessible sur Internet et ayant une faille «béante» est rapidement piratée Ex: Framework PHP - Joomla

29 Évolution des menaces De nouvelles classes de bug sont régulièrement découvertes : communauté très active Développeur pas toujours au fait des dernières bonnes pratiques ex: Web 2.0, virtualisation, ordiphone Interopérabilité / Interconnexion croissante : Une application est généralement interconnectée indirectement à Internet Infection par clé USB

30 Évolution des (mauvaises) pratiques Démocratiser le développement : Revers de la médaille : développeur peu sensibilisé à la sécurité Besoins opérationnels prédominent sur le reste : Egalement le cas pour les aspects commerciaux Réduction des délais de réalisation : besoin de développer vite pour répondre à une décision (réfléchie/applicable?) Origine: Aspect réglementaire / politique / opérationnel Réduction des couts de développement : Pour le ministère : moins de ressources, temps de conception réduit Pour le prestataire : développeur moins expérimenté stagiaire

31 Évolution des (mauvaises) pratiques Raison «psychologique» : Appréhension des risques : un développeur/décideur ne prend en compte que les risques qu il comprend Développeur est créatif par nature : réticence à intégrer des mécanismes déjà existants dont il ne perçoit pas la complexe Préjugé et apriori

32 Évolution des (mauvaises) pratiques Complexité croissante des applications, des outils, des exigences. Comparaison entre : Visual Studio 6 et Visual Studio 2013 Méthodes du Web 2.0: nouveaux protocoles, nouvelles façons de penser Cryptographie, processus de mise-à-jour, sont aujourd hui des pré requis Idée erronée de la sécurité logicielle : Se limite à citer/utiliser une norme: SSL, XML signing, sans ce soucier des détails Réalité économique : la sécurité est un business comme un autre : «Un projet simple ou qui marche du premier coup est un projet peu rentable.»

33 Évolution des réponses «Proactivité» : Intégrer la sécurité dans les systèmes d exploitation Limiter l impact d une vulnérabilité Interconnexion permet la mise à jour des logiciels Réponse rapide: communication, diffusion du correctif Outils d audit automatique du code : Compenser/Mitiger la méconnaissance des développeurs Analyse statique du code source: PreFast, Fortify, Existence de méthodologie / retours d expérience sur les technologies/problématiques éprouvées :

34 Évolution des réponses Gestion du développement industrialisé : Multi-utilisation, traçabilité, respect des spécifications Existence de bonnes pratiques et de méthodologies : Retour d expérience sur certaines technologies : Authentification, chiffrement, redondance, filtrage des réseaux, etc. Expérience des acteurs très importante : parfois suffisante «Une vulnérabilité est toujours l occasion d apprendre.» M. Howards (SDL)

35 Avant : Évolution des réponses

36 Évolution des réponses Cycle de développement plus rapide : Plusieurs mois => une semaine / un jour Réduction du temps pour appliquer un correctif à l environnement de production Maitrise des tests : Par fonctionnalités Par les groupes d utilisateur

37 Cas des «bug bounties» Récompenser la découverte d une vulnérabilité : Financièrement Renommée / «Wall of fame» Difficultés : Incitation au piratage d un système d information mais un système accessible sur Internet est en permanence attaquée Nécessite un budget spécifique mais la recherche de la renommée prédomine souvent la récompense financière

38 Cas des «bug bounties» Bénéfices : Sensibiliser les attaquants/utilisateurs à prévenir l éditeur préalablement Augmenter indirectement le coût d une vulnérabilité Valider la sécurité d un logiciel en situation réelle Tableau de bord : Nombre de vulnérabilités trouvées Temps de publication d un correctif

39 Cas des logiciels «open source» Code source librement téléchargeable : En théorie : principe du «many eyes» Tout le monde peut auditer le code de l application, remonter les erreurs, documentation, etc. En pratique : l audit de code est un travail long et pénible => faible retour Les développeurs préfèrent augmenter le nombre de fonctionnalités que relire du code source et corriger des bogues Cas Nessus La sécurité est une contrainte pour le développeur Quelques exceptions : Linux, openssh, Apache, etc.

40 Cas des logiciels «open source» CVE Bug dans le serveur X 20 ans CVE Bug Sendmail- 15 ans CVE Samba file & print 7 ans CVE Vulnérabilité du logiciel OpenSSL dans Debian : La vulnérabilité a été introduite par le «packager» du logiciel OpenSSL Générateur de nombre aléatoire prédictible depuis 2 ans : clé SSH, certificat à refaire

41 Référence Mar/0056.html html - timeline

42 Référence _2D00_-The-case-of-the-missing-Windows-Server-2003-attack-vector.aspx